Compartilhar via

Migrar para o Agente do Azure Monitor por meio do agente do Log Analytics

  • Artigo

O AMA (agente do Azure Monitor) substitui o agente do Log Analytics, também conhecido como MMA e OMS, em computadores Windows e Linux, em ambientes do Azure e fora do Azure, no local e em outras nuvens. O agente apresenta um método simplificado e flexível de configuração da coleta de dados usando Regras de coleta de dados (DCRs). Este artigo fornece diretrizes sobre como implementar uma migração bem-sucedida do agente do Log Analytics para o Agente do Azure Monitor.

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

Importante

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

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

  • Carregamento de dados: a ingestão para MMA ficará inalterada até o1º de fevereiro de 2025. Após essa data, os serviços de ingestão de nuvem reduzirão gradualmente o suporte para os agentes MMA, o que pode resultar na redução do suporte e possíveis problemas de compatibilidade para os agentes de 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 dos agentes herdados serão removidas. Você ainda pode instalar a extensão de agentes do MMA, bem como realizar instalações offline.
  • Suporte ao cliente: Você não poderá obter suporte para problemas de agentes herdados.
  • Suporte ao SO: O suporte para novas distribuições Linux ou Windows, incluindo pacotes de serviço, não será adicionado após a substituição dos agentes herdados.
  • O Agente do Log Analytics pode coexistir com o Agente do Azure Monitor. 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:

Diagrama dos benefícios do Agente do Azure Monitor em um relance. Isso será descrito em mais detalhes abaixo.

  • Redução de custos usando regras de coleta de dados:
    • Habilita a coleta de dados de destino e granular para um computador ou subconjunto(s) de computadores, em comparação com a abordagem "tudo ou nada" de agentes herdados.
    • Permite filtrar regras e transformações de dados para reduzir o volume geral de dados que está sendo carregado, o que diminui significativamente os custos de ingestão e armazenamento.
  • Segurança e Desempenho
    • Segurança aprimorada por meio de tokens de Identidade Gerenciada e do Microsoft Entra (para clientes).
    • Maior taxa de transferência de eventos que é 25% melhor do que os agentes herdados do Log Analytics (MMA/OMS).
  • Gerenciamento mais simples, incluindo solução de problemas eficiente:
    • Permite uploads de dados para vários destinos (diversos workspaces do Log Analytics, ou seja, multihoming no Windows e no Linux), incluindo coleta de dados entre regiões e entre locatários (com o Azure LightHouse).
    • Configuração de agente centralizada "na nuvem" para escala corporativa em todo o ciclo de vida da coleta de dados, desde a integração até a implantação, atualizações e alterações ao longo do tempo.
    • Todas as alterações na configuração são distribuídas para todos os agentes automaticamente, sem a necessidade de uma implantação do lado do cliente.
    • Maior transparência e controle de mais recursos e serviços, como Microsoft Sentinel, Defender para Nuvem e VM Insights.
  • Um único agente que atende a todas as necessidades de coleta de dados em servidores e dispositivos clientes compatíveis. Um só agente é a meta, embora, no momento, o Agente do Azure Monitor faça convergência com os agentes do Log Analytics.

Antes de começar

  • Examinar os pré-requisitos para instalar o agente do Azure Monitor. Para monitorar servidores não Azure e locais, você deve instalar o agente do Azure Arc. O agente do Arc torna seus servidores locais visíveis para o Azure como um recurso que ele pode ter como destino. Não haverá nenhum custo adicional ao instalar o agente do Azure Arc.

  • Verifique se o Agente do Azure Monitor pode atender a todas as suas necessidades. O agente do Azure Monitor está em GA (disponibilidade geral) 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 agente do Azure Monitor. É preciso ter as permissões necessárias para instalar o agente nos computadores que deseja monitorar. Para obter mais informações, consulte Permissões necessárias para instalar o agente do Azure Monitor.

Diretrizes de alto nível

Use as seguintes diretrizes para planejar e executar sua migração:

  • Entenda os agentes e quantos você precisa migrar.
  • Entenda como você está usando os espaços de trabalho.
  • Entenda quais soluções, insights e coletas de dados estão configuradas.
  • Configure as coleções de dados e valide as coleções.
  • Entenda dependências e serviços adicionais.
  • Remover 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 ajudar 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 a Pasta de trabalho auxiliar de migração do agente do Azure Monitor.

Entender seus agentes

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

Pergunta Ações
É preciso migrar quantos agentes? Entenda o número de agentes que você precisa migrar.
Há algum agente implantado fora do Azure?

Esses agentes estão implantados no próprio data center ou em outro ambiente de nuvem?

 Em servidores que estão fora do Azure, primeiro você deve implantar o agente do Connected Machine do Azure ARC. Para obter mais informações, consulte Visão geral do agente do Azure Connected Machine.
Você está usando o SCOM (System Center Operations Manager)?

O que você planeja 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 do SCOM.
Como você está implantando seus agentes no momento? 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 adicionando ao esforço de migração e permite se concentrar no inventário existente de agentes a serem migrados.

A pasta de trabalho auxiliar de migração do agente do Azure Monitor pode ajudar a entender quantos agentes é precisa ter para migrar. Para obter mais informações, consulte Pasta de trabalho auxiliar de migração do agente do Azure Monitor – agentes.

Entender espaços de trabalho, soluções, insights e coletas de dados

Antes da migração, entenda como os espaços de trabalho do Log Analytics estão sendo usados. Verifique se todos estão em uso e quais agentes estão enviando a telemetria deles para quais espaços de trabalho. Muitos espaços de trabalho são criados ao longo do tempo e não está claro quais espaços de trabalho estão de fato 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 os espaços de trabalho.

Ao examinar os 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 agente do Azure Monitor pode ajudar a entender quais espaços de trabalho você tem, as soluções implementadas em cada um 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 agente do Azure Monitor – espaços de trabalho

Você também pode usar a pasta de trabalho de auditoria do espaço de trabalho do Azure Monitor para ajudar a entender seus espaços de trabalho. Para usar a pasta de trabalho de auditoria do espaço de trabalho do Azure Monitor, copie a pasta de trabalho do repositório GitHub e importe para o espaço de trabalho do Log Analytics.

Essa pasta de trabalho recolhe todos os espaços de trabalho do Log Analytics e exibe 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.
  • Quaisquer recursos do Application Insights que estejam 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 as coleções de dados e valide as coleções

Ao configurar as 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 Gerador de Configuração do DCR para transformar as coleções de dados configuradas no espaço de trabalho e implantá-las como regras de coleta de dados de volta ao seu ambiente. Para obter mais informações sobre o Gerador de Configuração DCR, consulte Gerador de Configuração DCR.

  • Migrar o Insights de VM ou o Azure Monitor para máquinas virtuais 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 do workspace para agentes herdados. Para obter mais informações, consulte Fontes de dados do agente do Log Analytics no Azure Monitor

  • Validar os novos dados para garantir que não haja lacunas. Comparar os dados ingeridos pelos dados do agente herdado com o agente do Azure Monitor. Usar a KQL para comparar dados equivalentes de cada agente com base no tipo de agente.

  • Planejar a implantação em escala usando a política do Azure. Use as políticas internas para implantar extensões e associações de DCR em escala. O uso da política também garante a implantação automática de extensões e associações DCR para novos computadores. Para obter mais informações sobre como implantar em escala, consulte Gerenciar agente do Azure Monitor – usar políticas do Azure.

Entender dependências e serviços adicionais

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

Serviço Impacto
Gerenciamento de atualizações Se você estiver usando o Gerenciamento de Atualizações na Automação do Azure, deverá migrar para o Gerenciador de Atualizações do Azure.

O Gerenciador de Atualizações do Azure 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. É recomendável migrar para o Gerenciador de Atualizações do Azure.

Para obter mais informações, consulte as diretrizes para migrar do gerenciamento de Atualizações de Automação para o Gerenciador de Atualizações do Azure.

A pasta de trabalho auxiliar de migração AMA mostra quais dos seus computadores estão usando a solução de gerenciamento de atualizações no momento e como migrá-los. Para obter mais informações, consulte Pasta de trabalho auxiliar de migração do agente do Azure Monitor – gerenciamento de atualizações.
Controle de Alterações e Inventário Se você estiver usando o Controle de Alterações e Inventário, deverá migrar para a Automação do Azure.

O Controle de Alterações e Inventário também fazem parte da Automação do Azure. Embora o agente do Azure Monitor tenha uma solução de controle de alterações e inventário, é necessário criar uma regra de coleta de dados. Para obter mais informações, confira Gerenciar o Controle de Alterações e Inventário usando o agente de Monitoramento do Azure.
Defender para Nuvem Se você estiver usando o Defender para Nuvem no seu serviço ou Defender para servidores e tiver P2 habilitado ou planeja habilitar P2 em seus servidores, altere a implantação do agente no Defender para Nuvem da implantação do agente herdado para a verificação sem agente.

Se você estiver usando o Defender para Nuvem 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 agente do Azure Monitor e podem ser atualizadas.

Remover os agentes herdados

Como parte do planejamento de 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 manter o MMA em nenhum dos computadores, use a ferramenta de Descoberta e Remoção do MMA para remover o agente em escala. Para obter mais informações sobre a ferramenta de Descoberta e Remoção do MMA, consulte a ferramenta de Descoberta e Remoção do MMA.

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

Existe um pacote de gerenciamento de administrador do SCOM e pode ajudar a remover as configurações do espaço de trabalho em escala, mantendo a configuração do grupo de gerenciamento do SCOM. Para obter mais informações sobre o pacote de gerenciamento de administradores do SCOM, consulte o Pacote de gerenciamento de administradores do SCOM.

Problemas de migração conhecidos

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

Próximas etapas