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

  • Artigo

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

Não há nenhum processo padrão para migrar do SCOM, e você pode contar com pacotes de gerenciamento do SCOM por um longo período, 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 familiarizar mais com a nova plataforma. Deixe de usar a funcionalidade SCOM apenas conforme você puder substituí-la pelo Azure Monitor. Várias ferramentas de monitoramento adicionam complexidade, mas permite que você tire proveito da capacidade do Azure Monitor de monitorar as cargas de trabalho de nuvem de próxima geração e, ao mesmo tempo, manter a capacidade do SCOM de monitorar o software para servidores e cargas de trabalho.

Antes de mover componentes para o Azure, seu ambiente é baseado em máquinas virtuais e computadores físicos localizados localmente ou com um provedor de serviços gerenciados. Ele se baseia no SCOM para monitorar aplicativos de negócios, software para servidores e outros componentes de infraestrutura em seu ambiente, como servidores físicos e redes. Você usa pacotes de gerenciamento padrão para software para servidores, como IIS, SQL Server e vários softwares de fornecedores, e ajusta esses pacotes de gerenciamento para seus requisitos específicos. Você cria pacotes de gerenciamento personalizados para seus aplicativos de negócios e componentes que não podem ser monitorados com os pacotes de gerenciamento existentes e também configura o SCOM para dar suporte aos seus processos de negócios.

À medida que você move os serviços para a nuvem, o Azure Monitor começa a coletar métricas de 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 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 seus próprios alertas, você precisa criar grupos de ações 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 Descrição
Agentes de casa dupla O SCOM usa o MMA (Microsoft Management Agent), que é o mesmo que o agente do Log Analytics usado pelo Azure Monitor. Você pode configurar esse agente para que um único computador 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 fornece vantagens significativas, incluindo gerenciamento mais simples e melhor controle sobre a coleta de dados. Os dois agentes podem coexistir no mesmo computador, permitindo que você se conecte ao Azure Monitor e ao SCOM. Essa configuração é uma opção melhor do que a hospedagem dupla do agente herdado devido às vantagens significativas do agente do Azure Monitor.
Grupo de gerenciamento conectado Conecte seu grupo de gerenciamento do SCOM ao Azure Monitor para encaminhar dados coletados de seus agentes SCOM para o Azure Monitor. Isso é semelhante ao uso de agentes de casa dupla, mas não exige que cada agente seja configurado para se conectar ao Azure Monitor. Essa estratégia requer o agente herdado, portanto, você não pode 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 do SCOM (versão prévia) A instância gerenciada do SCOM (versão prévia) é uma implementação completa do SCOM no Azure, permitindo que você continue executando os mesmos pacotes de gerenciamento executados em seu ambiente SCOM local. Não há nenhuma 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.

A MI do SCOM é semelhante para manter seu ambiente SCOM existente e agentes de hospedagem dupla, embora você possa consolidar sua configuração de monitoramento no Azure e desativar seus componentes locais, como servidores de banco de dados e gerenciamento. Agentes de VMs do Azure podem se conectar à instância gerenciada do SCOM no Azure em vez de se conectar a 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 a integridade deles com base em um determinado conjunto de cenários de monitoramento. Esse pacote de gerenciamento exige que você execute uma configuração extra para cada recurso no Azure. Pode ser útil fornecer alguma visibilidade de seus recursos do Azure no Console de Operações até que você evolua seus processos de negócios para se concentrar no Azure Monitor.

Monitorar aplicativos de negócios

Normalmente, você precisa de pacotes de gerenciamento personalizados para monitorar seus aplicativos de negócios com o SCOM, aproveitando os agentes instalados em cada máquina virtual. O Application Insights no Azure Monitor monitora aplicativos baseados na Web, estejam eles no Azure, em outras nuvens ou localmente. Ele pode ser usado para todos os seus aplicativos, tenham sido eles migrados ou não do 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 recursos adicionais, incluindo os seguintes:

  • Descobrir e monitorar automaticamente os componentes do aplicativo.
  • Coletar dados detalhados de desempenho e uso do aplicativo, como tempo de resposta, taxas de falha e taxas de solicitação.
  • Coletar dados do navegador, como exibições de página e desempenho de carga.
  • Detectar exceções e detalhar o rastreamento de pilha e as solicitações relacionadas.
  • Executar a análise avançada usando recursos como rastreamento distribuído e detecção inteligente.
  • Use o Metrics Explorer para analisar interativamente os dados de desempenho.
  • Use consultas de log para analisar interativamente a telemetria coletada junto com os dados coletados para os serviços do Azure e os insights de VM.

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

  • Os testes de disponibilidade, que permitem monitorar a disponibilidade e a capacidade de resposta de seus aplicativos e alertar sobre elas, 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 Aplicativo Web no SCOM.
  • No SCOM é possível definir qualquer intervalo de sondagem para testes de disponibilidade, e muitos clientes verificam com um intervalo de 60 a 120 segundos. O Application Insights tem um intervalo mínimo de sondagem de cinco minutos, o que pode ser longo demais para alguns clientes.
  • Uma quantidade significativa de monitoramento no SCOM é executada coletando eventos gerados por aplicativos e executando scripts no agente local. Essas não são opções padrão no Application Insights, portanto, talvez seja necessário algum trabalho personalizado para que você atinja seus requisitos de negócios. Isso pode incluir regras de alerta personalizadas usando dados de evento armazenados em um workspace do Log Analytics e scripts lançados em um convidado de máquinas virtuais usando o Hybrid Runbook Worker.
  • Dependendo da linguagem de programação em que seu aplicativo está escrito, pode haver limitações quanto à instrumentação que você 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. Conforme você conseguir substituir a funcionalidade crítica pelo Azure Monitor, poderá começar a desativar seus pacotes de gerenciamento personalizados.

Monitorar máquinas virtuais

O monitoramento de 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 nas suas VMs. Assim que uma máquina virtual é criada no Azure, as métricas da plataforma e os logs de atividades para o host da VM começam a ser coletados automaticamente. Habilite alertas recomendados para ser notificado sobre erros comuns no host da VM, como servidor inativo e alta utilização da CPU.

Habilite os insights de VM para instalar o agente do Azure Monitor e começar a coletar dados comuns de desempenho 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 a monitorar suas VMs do Azure com outros recursos de nuvem. Você também pode optar por habilitar o recurso de mapa que fornecerá insights sobre os processos em execução em suas máquinas virtuais e suas dependências em outros serviços.

Continue usando pacotes de gerenciamento para funcionalidades que não podem ser fornecidas por outros recursos no Azure Monitor. Isso inclui pacotes de gerenciamento para software para servidores 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 alcançados 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, em que o uso do Azure Monitor e de outros serviços do Azure pode aumentar ou até substituí-lo.

Observação

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 a 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 criar pacotes de gerenciamento.

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

Não há ferramentas de migração para converter pacotes de gerenciamento do SCOM no 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á em analisar os dados coletados pelo SCOM e identificar os cenários de monitoramento que podem ser replicados pelo Azure Monitor. Conforme 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 legados 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 que já foram coletados pelo SCOM raramente são usados para alertas. O Azure Monitor separa a coleta de dados e os 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, regras e monitores normalmente se concentram estreitamente em dados específicos, como um determinado evento ou contador de desempenho. As regras de coleta de dados no Azure Monitor normalmente são mais amplas coletando vários conjuntos de eventos e contadores de desempenho em um único DCR.

Consulte o conteúdo a seguir para obter diretrizes 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 oferece. Decida se você pode replicar esses requisitos de monitoramento usando os métodos alternativos. Em muitos casos, você pode configurar regras de alerta e coleta de dados no Azure Monitor que repliquem funcionalidade suficiente para que você possa desativar um pacote de gerenciamento específico. Geralmente, os pacotes de gerenciamento podem incluir centenas, e até milhares, de regras e monitores.

Uma estratégia é se concentrar nesses monitores e regras que dispararam alertas em seu ambiente. Consulte os relatórios existentes disponíveis no Operations Manager, como os Alertas e os Alertas Mais Comuns, que podem ajudá-lo a identificar alertas ao longo do tempo. Você também pode executar a consulta a seguir no Banco de Dados do Operations 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 os alertas que foram desligados ou que sejam conhecidos como problemáticos. Revise seus pacotes de gerenciamento para identificar alertas críticos de interesse que nunca foram 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 um computador para simular uma conexão de usuário ou tráfego de usuário real. Se o aplicativo estiver disponível, você poderá pressupor que o computador está sendo executado corretamente. Os testes de disponibilidade do Application insights no Azure Monitor fornecem essa funcionalidade. Ele funciona apenas para aplicativos que podem ser acessados pela 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óximas etapas