Migrar do System Center Operations Manager (SCOM) para o Azure Monitor

  • Artigo

Este artigo fornece orientações para clientes que atualmente usam o System Center Operations Manager (SCOM) e estão planejando uma transição para o monitoramento baseado em nuvem com o Azure Monitor à medida que migram aplicativos de negócios e outros recursos para o Azure.

Não há um processo padrão para migrar do SCOM, e você pode confiar nos pacotes de gerenciamento do SCOM por um tempo prolongado, em vez de executar uma migração rápida. Este artigo descreve as diferentes opções disponíveis e os critérios de decisão que você pode usar para determinar a melhor estratégia para seu ambiente específico.

Monitoramento de nuvem híbrida

A maioria dos clientes usa uma estratégia de monitoramento de nuvem híbrida que permite fazer uma transição gradual para a nuvem. Essa abordagem permite que você mantenha seus processos de negócios existentes à medida que se familiariza com a nova plataforma. Afaste-se apenas da funcionalidade SCOM, pois você pode substituí-la pelo Azure Monitor. Várias ferramentas de monitoramento adicionam complexidade, mas permitem que você aproveite a capacidade do Azure Monitor de monitorar cargas de trabalho de nuvem de próxima geração, mantendo a capacidade da SCOM de monitorar software de servidor e cargas de trabalho.

Seu ambiente antes de mover qualquer componente para o Azure é baseado em máquinas virtuais e físicas localizadas no local ou com um provedor de serviços gerenciados. Ele depende do SCOM para monitorar aplicativos de negócios, software de servidor e outros componentes de infraestrutura em seu ambiente, como servidores físicos e redes. Você usa pacotes de gerenciamento padrão para software de servidor, como IIS, SQL Server e vários softwares de fornecedores, e ajusta esses pacotes de gerenciamento para suas necessidades específicas. Você cria pacotes de gerenciamento personalizados para seus aplicativos de negócios e componentes que não podem ser monitorados com pacotes de gerenciamento existentes e também configura o SCOM para dar suporte aos seus processos de negócios.

À medida que você move serviços para a nuvem, o Azure Monitor começa a coletar métricas da plataforma e o log de atividades para cada um dos seus recursos. Você cria configurações de diagnóstico para coletar logs de recursos para que possa analisar interativamente toda a telemetria disponível usando consultas de log e insights.

Durante esse período de transição, você tem duas ferramentas de monitoramento independentes. Você usa insights e pastas de trabalho para analisar sua telemetria de nuvem no portal do Azure enquanto ainda usa o console de Operações para analisar seus dados coletados pelo SCOM. Como cada sistema tem seu próprio alerta, você precisa criar grupos de ação no Azure Monitor equivalentes aos seus grupos de notificação no SCOM.

A tabela a seguir descreve os diferentes recursos e estratégias disponíveis para um ambiente de monitoramento híbrido usando o SCOM e o Azure Monitor.

Método Description
Agentes de hospedagem dupla O SCOM usa o Microsoft Management Agent (MMA), que é o mesmo que o agente do Log Analytics usado pelo Azure Monitor. Você pode configurar esse agente para que uma única máquina se conecte ao SCOM e ao Azure Monitor simultaneamente. Essa configuração exige que suas VMs do Azure tenham uma conexão com seus servidores de gerenciamento locais.

O agente do Log Analytics foi substituído pelo agente do Azure Monitor, que oferece vantagens significativas, incluindo gerenciamento mais simples e melhor controle sobre a coleta de dados. Os dois agentes podem coexistir na mesma máquina, permitindo que você se conecte ao Azure Monitor e ao SCOM. Essa configuração é uma opção melhor do que o dual-homing do agente herdado devido às vantagens significativas do agente do Azure Monitor.
Grupo de gerenciamento conectado Conecte seu grupo de gerenciamento SCOM ao Azure Monitor para encaminhar dados coletados de seus agentes SCOM para o Azure Monitor . Isso é semelhante ao uso de agentes de hospedagem dupla, mas não exige que cada agente seja configurado para se conectar ao Azure Monitor. Essa estratégia requer o agente herdado, portanto, não é possível especificar o monitoramento com regras de coleta de dados. Você também não pode usar insights de VM, a menos que conecte cada VM diretamente ao Azure Monitor.
Instância gerenciada SCOM (visualização) A instância gerenciada SCOM (visualização) é uma implementação completa do SCOM no Azure, permitindo que você continue executando os mesmos pacotes de gerenciamento que você executa em seu ambiente SCOM local. Não há integração atual entre os dados e alertas do SCOM e do Azure Monitor, e você continua a usar o mesmo console de Operações para analisar sua integridade e alertas.

O SCOM MI é semelhante à manutenção de seu ambiente SCOM existente e agentes de homing duplo, embora você possa consolidar sua configuração de monitoramento no Azure e desativar seus componentes locais, como banco de dados e servidores de gerenciamento. Os agentes das VMs do Azure podem se conectar à instância gerenciada SCOM no Azure em vez de se conectar aos servidores de gerenciamento em seu próprio data center.
Pacote de gerenciamento do Azure O pacote de gerenciamento do Azure permite que o Operations Manager descubra recursos do Azure e monitore sua integridade com base em um conjunto específico de cenários de monitoramento. Este pacote de gerenciamento exige que você execute uma configuração extra para cada recurso no Azure. No entanto, pode ser útil fornecer alguma visibilidade dos seus recursos do Azure no Operations Console até que você evolua seus processos de negócios para se concentrar no Azure Monitor.

Monitore aplicativos de negócios

Normalmente, você precisa de pacotes de gerenciamento personalizados para monitorar seus aplicativos de negócios com SCOM, usando agentes instalados em cada máquina virtual. O Application Insights no Azure Monitor monitoriza aplicações baseadas na Web, quer estejam no Azure, noutras nuvens ou no local. Ele pode ser usado para todos os seus aplicativos, independentemente de terem sido migrados ou não para o Azure.

Se o monitoramento de um aplicativo de negócios estiver limitado à funcionalidade fornecida pelo modelo de desempenho do aplicativo .NET no SCOM, você provavelmente poderá migrar para o Application Insights sem perda de funcionalidade. Na verdade, o Application Insights inclui um número significativo de outros recursos, incluindo o seguinte:

  • Descubra e monitore automaticamente os componentes do aplicativo.
  • Colete dados detalhados de uso e desempenho do aplicativo, como tempo de resposta, taxas de falha e taxas de solicitação.
  • Colete dados do navegador, como visualizações de página e desempenho de carregamento.
  • Detete exceções e analise detalhadamente o rastreamento de pilha e solicitações relacionadas.
  • Execute análises avançadas usando recursos como rastreamento distribuído e deteção inteligente.
  • Use o explorador de métricas para analisar dados de desempenho de forma interativa.
  • Use consultas de log para analisar interativamente a telemetria coletada juntamente com os dados coletados para serviços do Azure e insights de VM.

No entanto, há certos cenários em que você pode precisar continuar usando o SCOM além do Application Insights até conseguir a funcionalidade necessária. Exemplos em que você pode precisar continuar com o SCOM incluem o seguinte:

  • Os testes de disponibilidade, que permitem monitorar e alertar sobre a disponibilidade e a capacidade de resposta de seus aplicativos, exigem solicitações de entrada dos endereços IP dos agentes de teste da Web. Se sua política não permitir esse acesso, talvez seja necessário continuar usando os Monitores de Disponibilidade de Aplicativos Web no SCOM.
  • No SCOM você pode definir qualquer intervalo de sondagem para testes de disponibilidade, com muitos clientes verificando a cada 60-120 segundos. O Application Insights tem um intervalo mínimo de sondagem de cinco minutos, que pode ser muito longo para alguns clientes.
  • Uma quantidade significativa de monitoramento no SCOM é realizada coletando eventos gerados por aplicativos e executando scripts no agente local. Essas não são opções padrão no Application Insights, portanto, você pode precisar de trabalho personalizado para atingir seus requisitos de negócios. Isso pode incluir regras de alerta personalizadas usando dados de eventos armazenados em um espaço de trabalho do Log Analytics e scripts iniciados em um convidado de máquinas virtuais usando o runbook worker híbrido.
  • Dependendo do idioma em que seu aplicativo está escrito, você pode estar limitado na instrumentação que pode usar com o Application Insights.

Seguindo a estratégia básica nas outras seções deste guia, continue a usar o SCOM para seus aplicativos de negócios, mas aproveite os recursos adicionais fornecidos pelo Application Insights. À medida que você pode substituir a funcionalidade crítica pelo Azure Monitor, pode começar a desativar seus pacotes de gerenciamento personalizados.

Monitorizar máquinas virtuais

O monitoramento do software em suas máquinas virtuais em um ambiente híbrido geralmente usará uma combinação do Azure Monitor e do SCOM, dependendo dos requisitos das cargas de trabalho em execução em suas VMs. Assim que uma máquina virtual é criada no Azure, as métricas da plataforma e os logs de atividade para o host da VM começam a ser coletados automaticamente. Habilite alertas recomendados para notificá-lo de erros comuns para o host da VM, como servidor inativo e alta utilização da CPU.

Habilite as informações da VM para instalar o agente do Azure Monitor e comece a coletar dados de desempenho comuns do sistema operacional cliente. Isso pode se sobrepor a alguns dados que você já está coletando no SCOM, mas permitirá que você comece a exibir tendências ao longo do tempo e monitore suas VMs do Azure com outros recursos de nuvem. Você também pode optar por ativar o recurso de mapa que lhe dará informações sobre os processos em execução em suas máquinas virtuais e suas dependências de outros serviços.

Continue a usar pacotes de gerenciamento para funcionalidades que não podem ser fornecidas por outros recursos no Azure Monitor. Isso inclui pacotes de gerenciamento para software de servidor crítico, como IIS, SQL Server ou Exchange. Você também pode ter pacotes de gerenciamento personalizados desenvolvidos para infraestrutura local que não podem ser acessados com o Azure Monitor. Além disso, continue a usar o SCOM se ele estiver totalmente integrado aos seus processos operacionais até que você possa fazer a transição para modernizar suas operações de serviço, onde o Azure Monitor e outros serviços do Azure podem aumentar ou substituir.

Nota

Se você habilitar o VM Insights com o agente do Log Analytics em vez do agente do Azure Monitor, nenhum agente adicional precisará ser instalado na VM. No entanto, o agente do Azure Monitor é recomendado devido às suas melhorias significativas no monitoramento da VM na nuvem. A complexidade da manutenção de vários agentes é compensada pela capacidade de definir o monitoramento em regras de coleta de dados que permitem configurar diferentes coletas de dados para diferentes conjuntos de VMs, semelhante à sua estratégia para projetar pacotes de gerenciamento.

Migrar lógica de pacote de gerenciamento para cargas de trabalho de VM

Não há ferramentas de migração para converter pacotes de gerenciamento SCOM para o Azure Monitor porque sua lógica é fundamentalmente diferente da coleta de dados do Azure Monitor. A migração da lógica do pacote de gerenciamento normalmente se concentrará na análise dos dados coletados pelo SCOM e na identificação dos cenários de monitoramento que podem ser replicados pelo Azure Monitor. À medida que você personaliza o Azure Monitor para atender aos seus requisitos para diferentes aplicativos e componentes, você pode começar a desativar diferentes pacotes de gerenciamento e agentes herdados no SCOM.

Os pacotes de gerenciamento no SCOM contêm regras e monitores que combinam a coleta de dados e o alerta resultante em um único fluxo de trabalho de ponta a ponta. Os dados já recolhidos pela SCOM raramente são utilizados para alertas. O Azure Monitor separa a coleta de dados e alertas em processos separados. As regras de alerta acessam dados dos Logs do Azure Monitor e das Métricas do Azure Monitor que já foram coletados dos agentes. Além disso, as regras e os monitores geralmente são estritamente focados em dados específicos, como um evento específico ou contador de desempenho. As regras de coleta de dados no Azure Monitor geralmente são mais amplas, coletando vários conjuntos de eventos e contadores de desempenho em um único DCR.

Consulte o seguinte conteúdo para obter orientações sobre como criar coleta de dados e alertas para cenários comuns de monitoramento:

Em vez de tentar replicar toda a funcionalidade de um pacote de gerenciamento, analise o monitoramento crítico que cada um fornece. Decida se você pode replicar esses requisitos de monitoramento usando métodos alternativos. Em muitos casos, você pode configurar regras de alerta e coleta de dados no Azure Monitor que replicam funcionalidade suficiente para que você possa desativar um pacote de gerenciamento específico. Os pacotes de gerenciamento geralmente podem incluir centenas e até milhares de regras e monitores.

Uma estratégia é se concentrar nos monitores e regras que dispararam alertas em seu ambiente. Consulte os relatórios existentes disponíveis no Operations Manager, como Alertas e Alertas Mais Comuns, que podem ajudá-lo a identificar alertas ao longo do tempo. Você também pode executar a seguinte consulta no Operations Database para avaliar os alertas recentes mais comuns.

select AlertName, COUNT(AlertName) as 'Total Alerts' from
Alert.vAlertResolutionState ars
inner join Alert.vAlertDetail adt on ars.AlertGuid = adt.AlertGuid
inner join Alert.vAlert alt on ars.AlertGuid = alt.AlertGuid
group by AlertName
order by 'Total Alerts' DESC

Avalie a saída para identificar alertas específicos para migração. Ignore todos os alertas que foram apagados ou que são conhecidos por serem problemáticos. Reveja os seus pacotes de gestão para identificar quaisquer alertas críticos de interesse que nunca tenham sido acionados.

Transações sintéticas

Os pacotes de gerenciamento geralmente usam transações sintéticas que se conectam a um aplicativo ou serviço em execução em uma máquina para simular uma conexão de usuário ou tráfego de usuário real. Se o aplicativo estiver disponível, você pode assumir que a máquina está funcionando corretamente. Os testes de disponibilidade do Application Insights no Azure Monitor fornecem essa funcionalidade. Só funciona para aplicações acessíveis a partir da Internet. Para aplicativos internos, você deve abrir um firewall para permitir o acesso de URLs específicas da Microsoft que executam o teste. Ou você pode continuar a usar seu pacote de gerenciamento existente.

Próximos passos