Recomendações para projetar e criar um sistema de monitoramento

Artigo
11/15/2023

Aplica-se a esta recomendação de lista de verificação de Excelência Operacional do Azure Well-Architected Framework:

OE:07	Crie e implemente um sistema de monitoramento para validar as opções de design e informar decisões futuras de design e negócios. Esse sistema captura e expõe telemetria operacional, métricas e logs que emitem da infraestrutura e do código da carga de trabalho.

Guia relacionado: Recomendações para instrumentar um aplicativo

Este guia descreve as recomendações para criar e criar um sistema de monitoramento. Para monitorar efetivamente sua carga de trabalho para segurança, desempenho e confiabilidade, você precisa de um sistema abrangente com sua própria pilha que forneça a base para todas as funções de monitoramento, detecção e alerta.

Definições

Termo	Definição
Logs	Eventos registrados do sistema. Os logs podem conter diferentes tipos de dados em um formato de texto estruturado ou de forma livre. Eles contêm um carimbo de data/hora.
Métricas	Valores numéricos coletados em intervalos regulares. As métricas descrevem alguns aspectos de um sistema em um determinado momento.

Principais estratégias de design

Para implementar um design abrangente do sistema de monitoramento para sua carga de trabalho, siga estes princípios principais:

Sempre que for prático, aproveite as ferramentas de monitoramento fornecidas pela plataforma, que normalmente exigem muito pouca configuração e podem fornecer insights profundos sobre sua carga de trabalho que, de outra forma, podem ser difíceis de realizar.
Colete logs e métricas de toda a pilha de carga de trabalho. Todos os recursos de infraestrutura e funções de aplicativo devem ser configurados para produzir dados padronizados e significativos e que os dados precisam ser coletados.
Armazene os dados coletados em uma solução de armazenamento padronizada, confiável e segura.
Processe dados armazenados para que possam ser tratados por soluções de análise e visualização.
Analise os dados processados para determinar com precisão o estado da carga de trabalho.
Visualize o estado da carga de trabalho em dashboards ou relatórios significativos para equipes de carga de trabalho e outros stakeholders.
Configure alertas acionáveis e outras respostas automáticas para limites definidos de forma inteligente para notificar as equipes de carga de trabalho quando surgirem problemas.
Inclua sistemas de monitoramento e alertas em suas práticas gerais de teste de carga de trabalho.
Verifique se os sistemas de monitoramento e alerta estão no escopo para melhoria contínua. O comportamento de aplicativo e infraestrutura em produção oferece oportunidades de aprendizado contínuo. Incorpore essas lições em designs de monitoramento e alertas.
Vincule os dados de monitoramento que você coleta e analisa de volta aos fluxos do sistema e do usuário para correlacionar a integridade dos fluxos com os dados, além da integridade geral da carga de trabalho. Analisar esses dados em termos de fluxos ajudará a alinhar sua estratégia de observabilidade com seu modelo de integridade.

Você deve automatizar todas as funções do sistema de monitoramento o máximo possível, e todas elas devem ser executadas continuamente, todos os dias, todos os dias.

Este pipeline de fluxo de trabalho ilustra o sistema de monitoramento:

Coleção

Observação

Você precisa instrumentar seu aplicativo para habilitar o registro em log. Para obter mais informações, consulte o guia de instrumentação.

Você deve configurar todos os componentes de carga de trabalho, sejam eles recursos de infraestrutura ou funções de aplicativo, para capturar telemetria e/ou eventos como logs e métricas.

Os logs são úteis principalmente para detectar e investigar anomalias. Normalmente, os logs são produzidos pelo componente de carga de trabalho e enviados para a plataforma de monitoramento ou extraídos pela plataforma de monitoramento por meio da automação.

As métricas são úteis principalmente para criar um modelo de integridade e identificar tendências no desempenho e confiabilidade da carga de trabalho. As métricas também são úteis para identificar tendências no comportamento de uso de seus clientes. Essas tendências podem ajudar a orientar as decisões sobre melhorias da perspectiva do cliente. Normalmente, as métricas são definidas na plataforma de monitoramento e a plataforma de monitoramento e outras ferramentas sondam a carga de trabalho para capturar métricas.

Dados do aplicativo

Para aplicativos, o serviço de coleta pode ser uma ferramenta de gerenciamento de desempenho de aplicativo (APM) que pode ser executada de forma autônoma a partir do aplicativo que gera os dados de instrumentação. Depois que o APM estiver habilitado, você terá visibilidade clara das métricas importantes, em tempo real e historicamente. Use um nível apropriado de registro em log. O registro em log muito detalhado poderá gerar custos significativos. Defina os níveis de log de acordo com o ambiente. Ambientes inferiores não precisam do mesmo nível de detalhamento que a produção, por exemplo.

Os logs do aplicativo dão suporte ao ciclo de vida do aplicativo de ponta a ponta. O registro em log é essencial para entender como o aplicativo opera em vários ambientes, quais eventos ocorrem e as condições sob as quais eles ocorrem.

Recomendamos que você colete logs de aplicativos e eventos em todos os ambientes principais. Separe os dados entre ambientes o máximo possível usando armazenamentos de dados diferentes para cada ambiente, se isso for prático. Use filtros para garantir que ambientes não críticos não compliquem a interpretação dos logs de produção. Por fim, as entradas de log correspondentes no aplicativo devem capturar uma ID de correlação para suas respectivas transações.

Você deve capturar eventos de aplicativo em tipos de dados estruturados com pontos de dados legíveis por computador em vez de tipos de cadeia de caracteres não estruturadas. Um formato estruturado que usa um esquema conhecido pode facilitar a análise e a análise de logs. Além disso, os dados estruturados podem ser facilmente indexados e pesquisados e os relatórios podem ser bastante simplificados.

Os dados devem estar em um formato independente do computador, do sistema operacional ou do protocolo de rede. Por exemplo, emita informações em um formato autodescrevendo como JSON, MessagePack ou Protobuf em vez de ETL/ETW. Um formato padrão permite que o sistema construa pipelines de processamento. Componentes que leem, transformam e enviam dados no formato padrão podem ser facilmente integrados.

Dados de infraestrutura

Para recursos de infraestrutura em sua carga de trabalho, certifique-se de coletar logs e métricas. Para sistemas iaaS (infraestrutura como serviço), capture logs de sistema operacional, camada de aplicativo e diagnóstico, além de métricas relacionadas à integridade da carga de trabalho. Para recursos de PaaS (plataforma como serviço), você pode estar limitado em sua capacidade de capturar logs relacionados à infraestrutura subjacente, mas certifique-se de que você pode capturar logs de diagnóstico além de métricas relacionadas à integridade da carga de trabalho.

Tanto quanto possível, colete logs de sua plataforma de nuvem. Talvez você possa coletar logs de atividades para sua assinatura e logs de diagnóstico para o plano de gerenciamento.

Estratégias de coleta

Evite recuperar dados de telemetria manualmente de cada componente. Mova os dados para um local central e consolide-os lá. Para uma solução de várias regiões, recomendamos que você primeiro colete, consolide e armazene dados em uma base região por região e, em seguida, agrege os dados regionais em um único sistema central.

Compensação: esteja ciente de que há implicações de custo para ter armazenamentos de dados regionais e centralizados.

Para otimizar o uso da largura de banda, priorize com base na importância dos dados. Você pode transferir dados menos urgentes em lotes. No entanto, esses dados não devem ser atrasados indefinidamente, especialmente se contiver informações confidenciais de tempo.

Há dois modelos primários que o serviço de coleta pode usar para coletar dados de instrumentação:

Modelo de pull: recupera ativamente os dados dos vários logs e de outras fontes para cada instância do aplicativo.
Modelo de push: espera passivamente que os dados sejam enviados dos componentes que constituem cada instância do aplicativo.

Agentes de monitoramento

Você pode usar agentes de monitoramento no modelo de pull. Os agentes são executados localmente em um processo separado com cada instância do aplicativo, extraindo periodicamente os dados e gravando as informações diretamente no armazenamento comum compartilhado por todas as instâncias do aplicativo.

Observação

O uso de um agente de monitoramento é ideal para capturar dados de instrumentação obtidos naturalmente de uma fonte de dados. É apropriado para um aplicativo de pequena escala que é executado em um número limitado de nós em um único local. Os exemplos incluem informações de SQL Server exibições de gerenciamento dinâmico ou o comprimento de uma fila de Barramento de Serviço do Azure.

Considerações sobre desempenho

Um aplicativo complexo e altamente escalonável pode gerar grandes volumes de dados. A quantidade de dados pode sobrecarregar facilmente a largura de banda de E/S disponível para um único local central. A solução de telemetria não deve agir como gargalo e deve ser escalonável à medida que o sistema se expande. O ideal é que a solução incorpore um grau de redundância para reduzir os riscos de perda de informações importantes de monitoramento (como dados de auditoria ou cobrança) se parte do sistema falhar.

Uma maneira de armazenar em buffer os dados de instrumentação é usar a fila:

Nessa arquitetura, o serviço de coleta de dados posta dados em uma fila. Uma fila de mensagens é adequada porque fornece semântica "pelo menos uma vez" que ajuda a garantir que os dados enfileirados não sejam perdidos depois de postados. Você pode implementar o serviço de gravação de armazenamento usando uma função de trabalho separada. Você pode usar o padrão de Fila de Prioridades para implementar essa arquitetura.

Para escalabilidade, você pode executar várias instâncias do serviço de gravação de armazenamento. Se um grande volume de eventos ou um alto número de pontos de dados estiver sendo monitorado, você poderá usar Hubs de Eventos do Azure para expedir os dados para uma instância de computação diferente para processamento e armazenamento.

Estratégias de consolidação

Os dados coletados de uma única instância de um aplicativo fornecem uma exibição localizada da integridade e do desempenho dessa instância. Para avaliar a integridade geral do sistema, você precisa consolidar alguns aspectos dos dados das exibições locais. Você pode fazer isso depois que os dados são armazenados, mas, em alguns casos, você pode fazê-lo à medida que os dados são coletados.

Os dados de instrumentação podem passar por um serviço de consolidação de dados separado que combine os dados e atue como um processo de filtro e limpeza. Por exemplo, você pode amálgamar dados de instrumentação que incluem as mesmas informações de correlação, como uma ID de atividade. (Um usuário pode iniciar uma operação de negócios em um nó e, em seguida, ser transferido para outro nó se o primeiro nó falhar ou devido à forma como o balanceamento de carga está configurado.) Esse processo também pode detectar e remover quaisquer dados duplicados. (A duplicação poderá ocorrer se o serviço de telemetria usar filas de mensagens para enviar dados de instrumentação por push para o armazenamento.)

Armazenamento

Ao escolher uma solução de armazenamento, considere o tipo de dados, como eles são usados e o quão urgentemente eles são necessários.

Observação

Use soluções de armazenamento separadas para ambientes de não produção e produção para garantir que os dados de cada ambiente sejam fáceis de identificar e gerenciar.

Tecnologias de armazenamento

Considere uma abordagem de persistência poliglota, em que diferentes tipos de informações são armazenados em tecnologias mais apropriadas à maneira como cada tipo provavelmente será usado.

Por exemplo, Armazenamento de Blobs do Azure e o Armazenamento de Tabelas do Azure são acessados de maneiras semelhantes. Mas as operações que você pode executar nelas diferem, assim como a granularidade dos dados que eles contêm. Se você precisar executar operações mais analíticas ou precisar de recursos de pesquisa de texto completo dos dados, pode ser mais adequado usar o armazenamento de dados que fornece recursos otimizados para tipos específicos de consultas e acesso de dados. Por exemplo:

Os dados do contador de desempenho podem ser armazenados em um banco de dados SQL para habilitar uma análise ad hoc.
Talvez seja melhor armazenar logs de rastreamento nos Logs do Azure Monitor ou no Azure Data Explorer.
Você pode armazenar informações de segurança em uma solução HDFS.

Os mesmos dados de instrumentação podem ser necessários para mais de um propósito. Por exemplo, você pode usar contadores de desempenho para fornecer uma exibição histórica do desempenho do sistema ao longo do tempo. Essas informações podem ser combinadas com outros dados de uso para gerar informações de cobrança do cliente. Nessas situações, os mesmos dados podem ser enviados para mais de um destino, como para um banco de dados de documentos que pode ser um repositório de longo prazo para armazenar informações de cobrança e para um repositório multidimensional para lidar com análises de desempenho complexas.

Certifique-se de habilitar a funcionalidade para proteger os dados contra exclusão acidental, como bloqueios de recursos e exclusão temporária.

Além disso, certifique-se de proteger o acesso ao armazenamento usando o controle de acesso baseado em função para ajudar a garantir que apenas indivíduos que precisam acessar os dados possam fazê-lo.

Serviço de consolidação

Você pode implementar outro serviço que recupera periodicamente os dados do armazenamento compartilhado, partições e filtra-os de acordo com sua finalidade e, em seguida, os grava em um conjunto apropriado de armazenamentos de dados.

Uma abordagem alternativa é incluir essa funcionalidade no processo de consolidação e a limpeza e gravar os dados diretamente nesses armazenamentos conforme eles são recuperados, em vez de salvá-los em uma área de armazenamento compartilhado intermediária.

Cada abordagem tem suas vantagens e desvantagens. A implementação de um serviço de particionamento separado reduz a carga no serviço de consolidação e limpeza e permite que pelo menos alguns dos dados particionados sejam regenerados se necessário (dependendo da quantidade de dados retidos no armazenamento compartilhado). No entanto, essa abordagem consome recursos adicionais. Além disso, pode haver um atraso entre o recebimento de dados de instrumentação de cada instância do aplicativo e a conversão de dados em informações acionáveis.

Considerações de consulta

Considere a urgência com que os dados serão requisitados. Dados que geram alertas têm que ser acessados rapidamente e, por isso, devem ser mantidos em um armazenamento de dados rápido e devem ser indexados ou estruturados de modo a otimizar as consultas que sistema de alertas executa. Em alguns casos, pode ser necessário que o serviço de coleta formate e salve dados localmente para que uma instância local do sistema de alerta envie notificações rapidamente. Os mesmos dados podem ser enviados para o serviço de gravação em armazenamento mostrado nos diagramas anteriores e armazenados centralmente se também forem necessários para outras finalidades.

Considerações sobre retenção de dados

Em alguns casos, depois que os dados são processados e transferidos, você pode remover os dados de origem bruta originais que foram armazenados localmente. Em outros casos, pode ser necessário ou útil salvar as informações brutas. Por exemplo, talvez você queira manter os dados gerados para depuração disponíveis em sua forma bruta, mas, em seguida, descartá-los rapidamente depois que quaisquer bugs forem resolvidos.

Os dados de desempenho geralmente têm uma vida útil mais longa para que você possa usá-los para detectar tendências de desempenho e para planejamento de capacidade. A exibição consolidada dos dados geralmente é mantida online por um período limitado para habilitar o acesso rápido. Depois disso, ela pode ser arquivada ou descartada.

É útil armazenar dados históricos para que você possa identificar tendências de longo prazo. Em vez de salvar dados antigos em sua totalidade, você pode ser capaz de reduzir os dados para reduzir sua resolução e economizar custos de armazenamento. Por exemplo, em vez de salvar indicadores de desempenho minuto a minuto, você pode consolidar dados com mais de um mês de idade para formar uma exibição hora a hora.

Dados coletados para medição e de cobrança clientes talvez precisem ser salvos indefinidamente. Além disso, os requisitos regulatórios podem determinar que as informações coletadas para auditoria e segurança precisam ser arquivadas e salvas. Esses dados também são confidenciais e talvez precisem ser criptografados ou protegidos para evitar violações. Você nunca deve registrar senhas de usuário ou outras informações que possam ser usadas para cometer fraude de identidade. Você deve limpar esses detalhes dos dados antes que eles sejam armazenados.

Para garantir que você esteja em conformidade com as leis e regulamentos, minimize o armazenamento de qualquer informação identificável. Se você precisar armazenar informações identificáveis, certifique-se de, ao criar sua solução, levar em conta os requisitos que permitem que as pessoas solicitem que suas informações sejam excluídas.

Análise

Depois de coletar dados de várias fontes de dados, analise-os para avaliar o bem-estar geral do sistema. Para essa análise, tenha uma compreensão clara de:

Como estruturar dados com base em KPIs e métricas de desempenho que você definiu.
Como correlacionar os dados capturados em diferentes métricas e arquivos de log. Essa correlação é importante quando você está acompanhando uma sequência de eventos e pode ajudá-lo a diagnosticar problemas.

Na maioria dos casos, os dados de cada componente da arquitetura são capturados localmente e combinados com precisão com os dados gerados por outros componentes.

Por exemplo, um aplicativo de três camadas pode ter:

Uma camada de apresentação que permite que um usuário se conecte a um site.
Uma camada intermediária que hospeda um conjunto de microsserviços que processa a lógica de negócios.
Uma camada de banco de dados que armazena dados associados à operação.

Os dados de uso de uma única operação de negócios podem abranger todas as três camadas. Essas informações precisam ser correlacionadas para fornecer uma visão geral do uso de recursos e do processamento da operação. A correlação pode envolver pré-processamento e filtragem de dados na camada de banco de dados. Na camada intermediária, agregação e formatação são tarefas comuns.

Recomendações

Correlacionar logs no nível do aplicativo e no nível do recurso. Avalie os dados em ambos os níveis para otimizar a detecção de problemas e a solução de problemas desses problemas. Você pode agregar os dados em um único coletor de dados ou aproveitar os métodos que consultam eventos em ambos os níveis. Recomendamos uma solução unificada, como o Azure Log Analytics, para agregar e consultar logs no nível do aplicativo e no nível do recurso.
Defina tempos de retenção claros no armazenamento para análise a frio. Recomendamos essa prática para habilitar a análise histórica durante um período específico. Ele também pode ajudá-lo a controlar os custos de armazenamento. Implemente processos que garantem que os dados sejam arquivados em dados de armazenamento e agregação mais baratos para análise de tendência de longo prazo.
Analise tendências de longo prazo para prever problemas operacionais. Avalie os dados de longo prazo para formar estratégias operacionais e também para prever quais problemas operacionais provavelmente ocorrerão e quando. Por exemplo, você pode observar que os tempos médios de resposta estão aumentando lentamente ao longo do tempo e se aproximando do destino máximo.

Para obter diretrizes detalhadas sobre essas recomendações, consulte Analisar dados de monitoramento para aplicativos de nuvem.

Visualização

Painéis

A maneira mais comum de visualizar dados é usar painéis que podem exibir informações como uma série de gráficos ou gráficos ou em alguma outra forma visual. Esses itens podem ser parametrizados e um analista pode selecionar os parâmetros importantes, como o período de tempo, para qualquer situação específica.

Alinhe seus painéis com seu modelo de integridade para que eles indiquem quando a carga de trabalho ou os componentes da carga de trabalho estão íntegros, degradados ou não íntegros.

Para que um sistema de dashboard funcione com eficiência, ele deve ser significativo para a equipe de carga de trabalho. Visualize informações relacionadas à integridade da carga de trabalho e que também podem ser acionáveis. Quando a carga de trabalho ou um componente é degradado ou não íntegro, os membros da equipe de carga de trabalho devem ser capazes de identificar facilmente onde na carga de trabalho o problema se origina e iniciar suas ações corretivas ou investigações. Por outro lado, incluir informações que não são acionáveis ou que não estão relacionadas à integridade da carga de trabalho pode tornar o dashboard desnecessariamente complexo e frustrante para os membros da equipe que estão tentando discernir o ruído de fundo de dados acionáveis.

Você pode ter painéis para stakeholders ou desenvolvedores que são personalizados para mostrar apenas dados sobre a carga de trabalho que eles acham relevantes. Verifique se a equipe de carga de trabalho entende os tipos de pontos de dados que outras equipes estão interessadas em ver e visualiza os painéis antes de compartilhá-los para marcar para maior clareza. Fornecer painéis sobre sua carga de trabalho para os stakeholders é uma boa maneira de mantê-los informados sobre a integridade da carga de trabalho, mas traz o risco de serem contraproducentes se os stakeholders não entenderem claramente os dados que veem.

Uma boa dashboard não apenas exibe informações. Também permite que um analista faça perguntas improvisadas sobre essas informações. Alguns sistemas oferecem ferramentas de gerenciamento que o operador pode usar para concluir essas tarefas e explorar os dados subjacentes. Em vez disso, dependendo do repositório usado para armazenar as informações, talvez seja possível consultar os dados diretamente ou importá-los para ferramentas como o Excel para análise e relatórios adicionais.

Observação

Restringir o acesso dashboard ao pessoal autorizado. As informações sobre painéis podem ser comercialmente confidenciais. Você também deve proteger os dados subjacentes para impedir que os usuários os alterem.

Relatórios

A emissão de relatórios é usada para gerar uma visão geral do sistema. Ele pode incorporar dados históricos e informações atuais. Os requisitos para a geração de relatórios se enquadram em duas categorias amplas: relatórios operacionais e relatórios de segurança.

Normalmente, os relatórios operacionais incluem o seguinte:

Agregar estatísticas que você pode usar para compreender a utilização de recursos do sistema geral ou de subsistemas especificados durante um período especificado.
Identificar tendências na utilização de recursos do sistema geral ou de subsistemas específicos durante um período especificado.
Monitorar as exceções que ocorreram em todo o sistema ou em subsistemas especificados durante um período especificado.
Determinar a eficiência do aplicativo para os recursos implantados e entender se o volume de recursos e seus custos associados podem ser reduzidos sem afetar o desempenho desnecessariamente.

Os relatórios de segurança rastreiam o uso do sistema pelo cliente. Eles podem incluir:

Auditoria de operações do usuário. Essa tarefa requer a gravação das solicitações individuais que cada usuário conclui, juntamente com datas e horas. Os dados devem ser estruturados para permitir que um administrador reconstrua rapidamente a sequência de operações que um usuário conclui durante um período especificado.
Controle do uso do recurso pelo usuário. Essa tarefa requer a gravação de como cada solicitação de um usuário acessa os vários recursos que compõem o sistema e por quanto tempo. Um administrador pode usar esses dados para gerar um relatório de utilização, por usuário, por um período especificado, possivelmente para cobrança.

Em muitos casos, os processos em lotes podem gerar relatórios de acordo com um agendamento definido. A latência normalmente não é um problema. Você também deve ter processos em lotes que possam gerar relatórios de forma espontânea, conforme necessário. Por exemplo, se você armazenar dados em um banco de dados relacional como SQL do Azure Banco de Dados, poderá usar uma ferramenta como SQL Server Reporting Services para extrair e formatar dados e apresentá-los como um conjunto de relatórios.

Alertas

Para ajudar a garantir que o sistema permaneça íntegro, responsivo e seguro, defina alertas para que os operadores possam responder a eles em tempo hábil. Um alerta pode conter informações contextuais suficientes para ajudá-los a começar rapidamente as atividades de diagnóstico. Os alertas podem ser usados para invocar funções de correção, como dimensionamento automático ou outros mecanismos de autorrecuperação. Os alertas também podem habilitar a conscientização de custo fornecendo visibilidade sobre orçamentos e limites.

Recomendações

Defina um processo para resposta de alerta que identifique as ações e os proprietários responsáveis.
Configure alertas para um escopo bem definido (tipos de recursos e grupos de recursos) e ajuste o detalhamento para minimizar o ruído.
Use uma solução de alerta automatizado, como Splunk ou Azure Monitor, em vez de exigir que as pessoas procurem ativamente problemas.
Use alertas para operacionalizar processos de correção. Por exemplo, crie automaticamente tíquetes para acompanhar problemas e resoluções.
Acompanhe a integridade dos serviços da plataforma de nuvem em regiões, comunicação sobre interrupções, atividades de manutenção planejada e outros avisos de integridade.

Limites

Os alertas são gerados quando os limites são cruzados, conforme detectado pelo sistema de monitoramento. Verifique se os limites definidos geralmente dão tempo suficiente para implementar as alterações necessárias em sua carga de trabalho para evitar degradação ou interrupções. Por exemplo, defina o limite de dimensionamento automático para iniciar o dimensionamento antes que qualquer um dos sistemas em execução fique sobrecarregado ao ponto de uma experiência de usuário degradada. Baseie os valores de limite que você atribui em sua experiência passada no gerenciamento de infraestrutura e valide-os por meio dos testes que você executa como parte de suas práticas de teste.

Para obter diretrizes detalhadas sobre casos de uso de alertas e outras considerações, consulte Criando uma estratégia confiável de monitoramento e alertas.

Facilitação do Azure

O Azure Monitor é uma solução de monitoramento abrangente para coletar, analisar e responder a dados de monitoramento de seus ambientes locais e de nuvem.
O Log Analytics é uma ferramenta no portal do Azure que você pode usar para editar e executar consultas de log em relação aos dados no workspace do Log Analytics.

Se você estiver usando vários workspaces, consulte o guia de arquitetura do workspace do Log Analytics para obter as melhores práticas.
O Application Insights é uma extensão do Azure Monitor. Ele fornece recursos do APM.
Os Insights do Azure Monitor são ferramentas de análise avançada para tecnologias específicas do Azure (como VMs, serviços de aplicativos e contêineres). Essas ferramentas fazem parte do Azure Monitor e do Log Analytics.
O Azure Monitor para soluções SAP é uma ferramenta de monitoramento do Azure para cenários SAP executados no Azure.
Azure Policy pode ajudá-lo a impor padrões organizacionais e avaliar a conformidade em escala.

Links da comunidade

O AMBA (Alertas de Linha de Base) do Azure Monitor é um repositório central de definições de alerta que os clientes e parceiros podem usar para melhorar sua experiência de observabilidade por meio da adoção do Azure Monitor.

Lista de verificação de Excelência Operacional

Consulte o conjunto completo de recomendações.

Lista de verificação de Excelência Operacional

Recomendações para projetar e criar um sistema de monitoramento