Migrar para o Agente do Azure Monitor a partir do agente do Log Analytics

Artigo
11/14/2024

O Azure Monitor Agent (AMA) substitui o agente do Log Analytics, também conhecido como Microsoft Monitor Agent (MMA) e OMS, para máquinas Windows e Linux, em ambientes Azure e não Azure, no local e em outras nuvens. O agente introduz um método simplificado e flexível de configurar a coleta de dados usando Regras de Coleta de Dados (DCRs). Este artigo fornece orientação sobre como implementar uma migração bem-sucedida do agente do Log Analytics para o Azure Monitor Agent.

A migração é uma tarefa complexa. Comece a planejar sua migração para o Azure Monitor Agent usando as informações deste artigo como um guia.

Importante

O agente do Log Analytics foi desativado em 31 de agosto de 2024. Essa substituição não se aplica ao agente MMA conectado exclusivamente a uma instalação SCOM local.

Você pode esperar o seguinte quando usar o agente MMA ou OMS após 31 de agosto de 2024.

Upload de dados: A ingestão para MMA permanecerá inalterada até 1º de fevereiro de 2025. Após essa data, os serviços de ingestão na nuvem reduzirão gradualmente o suporte para agentes MMA, o que pode resultar em menor suporte e possíveis problemas de compatibilidade para agentes MMA ao longo do tempo.
Instalação: A capacidade de instalar os agentes herdados será removida do Portal do Azure e as políticas de instalação para agentes herdados serão removidas. Você ainda pode instalar a extensão de agentes MMA, bem como executar instalações offline.
Suporte ao cliente: Você não poderá obter suporte para problemas de agentes legados.
Suporte a SO: O suporte para novas distribuições Linux ou Windows, incluindo service packs, não será adicionado após a descontinuação dos agentes legados.
O Log Analytics Agent pode coexistir com o Azure Monitor Agent. Espere ver dados duplicados se ambos os agentes estiverem coletando os mesmos dados.

Benefícios

Usando o agente do Azure Monitor, você obtém benefícios imediatos, conforme mostrado abaixo:

Economia de custos usando regras de coleta de dados:
- Permite a coleta de dados direcionada e granular para uma máquina ou subconjunto de máquinas, em comparação com a abordagem "tudo ou nada" de agentes legados.
- Permite regras de filtragem e transformações de dados para reduzir o volume geral de dados que estão sendo carregados, reduzindo significativamente os custos de ingestão e armazenamento.
Segurança e Desempenho
- Segurança melhorada através de tokens Managed Identity e Microsoft Entra (para clientes).
- Maior taxa de transferência de eventos que é 25% melhor do que os agentes legados do Log Analytics (MMA/OMS).
Gerenciamento mais simples, incluindo solução de problemas eficiente:
- Suporta carregamentos de dados para vários destinos (vários espaços de trabalho do Log Analytics, ou seja , multihoming no Windows e Linux), incluindo recolha de dados entre regiões e entre inquilinos (utilizando o Azure LightHouse).
- Configuração centralizada do agente "na nuvem" para escala empresarial em todo o ciclo de vida da coleta de dados, desde a integração até a implantação e atualizações e alterações ao longo do tempo.
- Qualquer alteração na configuração é implementada para todos os agentes automaticamente, sem exigir uma implantação do lado do cliente.
- Maior transparência e controle de mais recursos e serviços, como Microsoft Sentinel, Defender for Cloud e VM Insights.
Um único agente que atende a todas as necessidades de coleta de dados em servidores e dispositivos cliente suportados . Um único agente é o objetivo, embora o Azure Monitor Agent esteja atualmente convergindo com os agentes do Log Analytics.

Antes de começar

Analise os pré-requisitos para instalar o Azure Monitor Agent. Para monitorar servidores não Azure e locais, você deve instalar o agente do Azure Arc. O agente Arc torna seus servidores locais visíveis para o Azure como um recurso que ele pode segmentar. Você não incorre em nenhum custo adicional para instalar o agente do Azure Arc.
Verifique se o Azure Monitor Agent pode atender a todas as suas necessidades. O Azure Monitor Agent é a Disponibilidade Geral (GA) para coleta de dados e é usado para coleta de dados por vários recursos do Azure Monitor e outros serviços do Azure.
Verifique se você tem as permissões necessárias para instalar o Azure Monitor Agent. Você deve ter as permissões necessárias para instalar o agente nas máquinas que deseja monitorar. Para obter mais informações, consulte Permissões necessárias para instalar o Azure Monitor Agent.

Orientações de alto nível

Use as seguintes orientações para planejar e executar sua migração:

Entenda seus agentes e quantos você tem que migrar.
Entenda como você está usando seus espaços de trabalho.
Entenda quais soluções, insights e coleções de dados estão configurados.
Configure suas coleções de dados e valide as coleções.
Compreender dependências e serviços adicionais.
Remova os agentes herdados.

A pasta de trabalho Auxiliar de Migração do Agente do Azure Monitor é uma solução do Azure Monitor baseada em pasta de trabalho que pode ajudá-lo em cada uma das etapas descritas acima. Este guia faz referência à pasta de trabalho e a outras ferramentas em cada estágio do processo de migração. Para obter mais informações, consulte Pasta de trabalho auxiliar de migração do Azure Monitor Agent.

Compreenda os seus agentes

Use o gerador DCR para converter automaticamente a configuração do agente herdado em regras de coleta de dados. 1 Para ajudar a entender seus agentes, analise as seguintes perguntas:

Pergunta	Ações
Quantos agentes você tem que migrar?	Entenda o número de agentes que você precisa migrar.
Você tem agentes implantados fora do Azure? Esses agentes são implantados em seu próprio data center ou em outro ambiente de nuvem?	Para servidores que estão fora do Azure, você deve primeiro implantar o Azure ARC Connected Machine Agent. Para obter mais informações, consulte Visão geral do agente do Azure Connected Machine.
Você está usando o System Center Operations Manager (SCOM)? Qual o seu plano para o SCOM daqui para frente?	Se você estiver planejando continuar a usar o SCOM, comece a avaliar a Instância Gerenciada do SCOM. Para obter mais informações, consulte Instância gerenciada SCOM.
Como você está implantando seus agentes hoje?	Se você estiver usando métodos automatizados para implantar o agente herdado, considere quando interromper essas implantações automatizadas para novos servidores e comece a se concentrar na implantação do novo agente. Interromper a implantação automatizada para novos servidores ajuda a garantir que você não continue aumentando seu esforço de migração e permite que você se concentre no inventário existente de agentes a serem migrados.

A Pasta de Trabalho Auxiliar de Migração do Azure Monitor Agent pode ajudá-lo a entender quantos agentes você precisa migrar. Para obter mais informações, consulte Pasta de trabalho auxiliar de migração do Agente do Azure Monitor - Agentes.|

Entenda seus espaços de trabalho, soluções, insights e coleções de dados

Antes da migração, entenda como seus espaços de trabalho do Log Analytics estão sendo usados. Verifique se todos eles estão em uso e quais agentes estão enviando sua telemetria para quais espaços de trabalho. Muitos espaços de trabalho são criados ao longo do tempo, e pode ficar pouco claro quais espaços de trabalho estão realmente em uso, quais espaços de trabalho estão sendo usados para coletar telemetria e de quais servidores. A migração é uma boa oportunidade para limpar e consolidar seus espaços de trabalho.

Ao examinar seus espaços de trabalho, observe quais soluções estão configuradas. Essas informações são importantes para entender quais dados você está coletando e como você os está usando.

A Pasta de Trabalho Auxiliar de Migração do Azure Monitor Agent pode ajudá-lo a entender quais espaços de trabalho você tem, as soluções implementadas em cada espaço de trabalho e quando você usou a solução pela última vez. Cada solução tem uma recomendação de migração. Para obter mais informações, consulte Pasta de trabalho auxiliar de migração do Azure Monitor Agent - Espaços de trabalho

Você também pode usar a pasta de trabalho de Auditoria de Espaço de Trabalho do Azure Monitor para ajudá-lo a entender seus espaços de trabalho. Para usar a pasta de trabalho de Auditoria de Espaço de Trabalho do Azure Monitor, copie a pasta de trabalho do repositório GitHub e importe-a para seu espaço de trabalho do Log Analytics.

Esta pasta de trabalho coleta todos os espaços de trabalho do Log Analytics e mostra o seguinte para cada espaço de trabalho:

Todas as fontes de dados que estão enviando dados para o espaço de trabalho.
Os agentes que estão enviando pulsações para o espaço de trabalho.
Os recursos que estão enviando dados para o espaço de trabalho.
Todos os recursos do Application Insights que estão enviando dados para o espaço de trabalho.

Para obter mais informações, consulte Pasta de trabalho de auditoria do espaço de trabalho do Azure Monitor.

Configure suas coleções de dados e valide as coleções

Ao configurar suas coleções de dados, considere as seguintes etapas:

Identifique um grupo piloto de servidores que você pode usar para esse processo. Use os servidores piloto para validar os dados antes de implantar em escala.
Use o DCR Config Generator para transformar as coleções de dados configuradas no espaço de trabalho e implantá-las como regras de coleta de dados em seu ambiente. Para obter mais informações sobre o DCR Config Generator, consulte DCR Config Generator.
Migre o VM Insights ou o Azure Monitor for Virtual Machines para o Agente do Azure Monitor. Valide as coleções de dados migradas para o grupo piloto de servidores em comparação com o que foi coletado antes da migração. Para evitar a ingestão dupla, você pode desabilitar a coleta de dados de agentes herdados durante a fase de teste sem desinstalar os agentes ainda, removendo as configurações de espaço de trabalho para agentes herdados. Para obter mais informações, consulte Fontes de dados do agente do Log Analytics no Azure Monitor
Valide os novos dados para garantir que não haja lacunas. Compare os dados ingeridos pelos dados do agente herdado com o Azure Monitor Agent. Use o KQL para comparar dados equivalentes de cada agente com base no tipo de agente.
Planeje a implantação em escala usando a política do Azure. Use políticas internas para implantar extensões e associações DCR em escala. O uso da política também garante a implantação automática de extensões e associações DCR para novas máquinas. Para obter mais informações sobre a implantação em escala, consulte Manage Azure Monitor Agent - Use Azure policies.

Compreender dependências e serviços adicionais

Antes da migração, é importante entender como seus outros serviços são afetados.

Serviço	Impacto
Gestão de Atualizações	Se estiver a utilizar a Gestão de Atualizações na Automação do Azure, tem de migrar para o Azure Update Manager. O Azure Update Manager tem seu próprio agente e é dissociado do agente do Azure Monitor. O Gerenciamento de Atualizações será preterido no final de agosto de 2024. Recomendamos migrar para o Azure Update Manager. Para obter mais informações, consulte Mover do Automation Update Management para o Azure Update Manager. A pasta de trabalho AMA migration Helper mostra quais de suas máquinas estão usando a solução de gerenciamento de atualizações hoje e como migrá-las. Para obter mais informações, consulte Pasta de trabalho auxiliar de migração do Agente do Azure Monitor - Gerenciamento de atualizações.
Controlo de Alterações e Inventário	Se estiver a utilizar o Controlo de Alterações e o Inventário, tem de migrar para a Automação do Azure. O Controle de Alterações e o Inventário também fazem parte da Automação do Azure. Embora o Azure Monitor Agent tenha uma solução de controle de alterações e inventário, você deve criar uma regra de coleta de dados. Para obter mais informações, consulte Gerenciar o controle de alterações e o inventário usando o Azure Monitoring Agent.
Defender para nuvem	Se você estiver usando o Defender for Cloud para seu serviço ou o Defender para servidores e tiver o P2 habilitado ou planeja habilitar o P2 para seus servidores, altere a implantação do agente no Defender for Cloud da implantação do agente herdado para a verificação sem agente. Se você estiver usando o Defender for Cloud para coletar eventos de segurança, crie uma regra de coleta de dados personalizada para coletar esses eventos.
Microsoft Sentinel	Se você estiver usando o Microsoft Sentinel, as soluções que estavam usando o agente herdado foram convertidas em soluções baseadas no Azure Monitor Agent e podem ser atualizadas.

Remover os agentes herdados

Como parte do planejamento da migração, planeje remover o agente herdado assim que a migração for concluída para evitar a duplicação da coleta de dados.

Se você não precisar reter o MMA em nenhuma de suas máquinas, use a ferramenta MMA Discovery and Removal para remover o agente em escala. Para obter mais informações sobre a ferramenta de descoberta e remoção de MMA, consulte Ferramenta de descoberta e remoção de MMA.

Se, no entanto, você estiver usando o System Center Operations Manager (SCOM), mantenha o agente MMA implantado nas máquinas que você continuará gerenciando com o System Center Operations Manager.

Existe um Pacote de Gerenciamento de Administração SCOM que pode ajudá-lo a remover as configurações do espaço de trabalho em escala, mantendo a configuração do Grupo de Gerenciamento SCOM. Para obter mais informações sobre o SCOM Admin Management Pack, consulte SCOM Admin Management Pack.

Problemas conhecidos de migração

Logs do IIS: Quando a coleta de logs do IIS está habilitada, o AMA pode não preencher a sSiteName W3CIISLog coluna da tabela. Esse campo é coletado por padrão quando a coleta de logs do IIS está habilitada para o agente herdado. Se você precisar coletar o campo usando AMA sSiteName , habilite o Service Name (s-sitename) campo no log W3C do IIS. Para conhecer as etapas para habilitar esse campo, consulte Selecionar campos W3C para registro.
Solução de avaliação SQL: agora faz parte da avaliação de práticas recomendadas de SQL. As políticas de implantação exigem um espaço de trabalho do Log Analytics por assinatura, o que não é a prática recomendada pela equipe da AMA.
Microsoft Defender para nuvem: está mudando para uma solução sem agente. Alguns recursos não estarão prontos até a data de descontinuação. Os clientes devem permanecer no MMA para máquinas que usam o Monitoramento de Integridade de Arquivos (FIM), recomendações de descoberta de proteção de ponto de extremidade, configurações incorretas do sistema operacional (recomendações ASB (Azure Security Benchmark)) e controles de aplicativos adaptáveis.
O gerenciamento de atualizações está mudando para uma solução sem agente, mas não estará pronto até a data de depreciação do MMA. Os clientes que usam o Gerenciamento de Atualizações devem permanecer no MMA até que o novo serviço Automated Update Manager esteja pronto.

Partilhar via