Recomendações para conceber e criar um sistema de monitorização

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 monitorização para validar escolhas de conceção e informar futuras decisões empresariais e de design. Este sistema captura e expõe telemetria operacional, métricas e registos que emitem a partir da infraestrutura e do código da carga de trabalho.

Guia relacionado: Recomendações para instrumentar uma aplicação

Este guia descreve as recomendações para conceber e criar um sistema de monitorização. Para monitorizar eficazmente a carga de trabalho em termos de segurança, desempenho e fiabilidade, precisa de um sistema abrangente com a sua própria pilha que forneça a base para todas as funções de monitorização, deteção e alerta.

Definições

Termo	Definição
Registos	Eventos de sistema registados. Os registos podem conter diferentes tipos de dados num formato de texto estruturado ou livre. Contêm um carimbo de data/hora.
Métricas	Valores numéricos que são recolhidos em intervalos regulares. As métricas descrevem alguns aspetos de um sistema num determinado momento.

Principais estratégias de conceção

Para implementar um design de sistema de monitorização abrangente para a sua carga de trabalho, siga estes princípios principais:

Sempre que for prático, tire partido das ferramentas de monitorização fornecidas pela plataforma, que normalmente requerem pouca configuração e podem fornecer informações aprofundadas sobre a sua carga de trabalho que, de outra forma, poderiam ser difíceis de realizar.
Recolha registos e métricas de toda a pilha de cargas de trabalho. Todos os recursos de infraestrutura e funções de aplicação devem ser configurados para produzir dados padronizados e significativos e esses dados têm de ser recolhidos.
Armazene os dados recolhidos numa solução de armazenamento padronizada, fiável e segura.
Processe os dados armazenados para que possam ser processados 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 equipas de carga de trabalho e outros intervenientes.
Configure alertas acionáveis e outras respostas automáticas para limiares definidos de forma inteligente para notificar as equipas de cargas de trabalho quando surgem problemas.
Inclua sistemas de monitorização e alerta nas suas práticas gerais de teste de cargas de trabalho.
Certifique-se de que os sistemas de monitorização e alerta estão no âmbito da melhoria contínua. O comportamento da aplicação e da infraestrutura na produção proporciona oportunidades de aprendizagem contínua. Incorpore essas lições em designs de monitorização e alertas.
Ligue os dados de monitorização que recolhe e analise de volta ao sistema e aos fluxos de utilizador para correlacionar o estado de funcionamento dos fluxos com os dados, além do estado de funcionamento geral da carga de trabalho. Analisar esses dados em termos de fluxos ajudará a alinhar a sua estratégia de observabilidade com o seu modelo de estado de funcionamento.

Deve automatizar todas as funções do sistema de monitorização o máximo possível e todas elas devem ser executadas continuamente, durante todo o dia, todos os dias.

Este pipeline de fluxo de trabalho ilustra o sistema de monitorização:

Coleção

Nota

Tem de instrumentar a sua aplicação para ativar o registo. Para obter mais informações, veja o guia de instrumentação.

Deve configurar todos os componentes da carga de trabalho, quer sejam recursos de infraestrutura ou funções de aplicação, para capturar telemetria e/ou eventos como registos e métricas.

Os registos são sobretudo úteis para detetar e investigar anomalias. Normalmente, os registos são produzidos pelo componente de carga de trabalho e, em seguida, enviados para a plataforma de monitorização ou solicitados pela plataforma de monitorização através da automatização.

As métricas são sobretudo úteis para criar um modelo de estado de funcionamento e identificar tendências no desempenho e fiabilidade da carga de trabalho. As métricas também são úteis para identificar tendências no comportamento de utilização dos seus clientes. Estas tendências podem ajudar a orientar as decisões sobre as melhorias do ponto de vista do cliente. Normalmente, as métricas são definidas na plataforma de monitorização e a plataforma de monitorização e outras ferramentas consultam a carga de trabalho para capturar métricas.

Dados da aplicação

Para aplicações, o serviço de recolha pode ser uma ferramenta de gestão de desempenho de aplicações (APM) que pode ser executada de forma autónoma a partir da aplicação que gera os dados de instrumentação. Após a ativação do APM, tem visibilidade clara sobre métricas importantes, em tempo real e historicamente. Utilize um nível de registo adequado. O registo verboso pode incorrer em custos significativos. Defina os níveis de registo de acordo com o ambiente. Os ambientes mais baixos não precisam do mesmo nível de verbosidade que a produção, por exemplo.

Os registos de aplicações suportam o ciclo de vida da aplicação ponto a ponto. O registo é essencial para compreender como a aplicação funciona em vários ambientes, quais os eventos que ocorrem e as condições em que ocorrem.

Recomendamos que recolha registos de aplicações e eventos em todos os ambientes principais. Se o fizer, se for prático, se for prático, se os separar entre ambientes, utilize diferentes arquivos de dados para cada ambiente. Utilize filtros para garantir que os ambientes não críticos não complicam a interpretação dos registos de produção. Por fim, as entradas de registo correspondentes na aplicação devem capturar um ID de correlação para as respetivas transações.

Deve capturar eventos de aplicações em tipos de dados estruturados com pontos de dados legíveis por computador em vez de tipos de cadeias não estruturados. Um formato estruturado que utiliza um esquema bem conhecido pode facilitar a análise e a análise de registos. Além disso, os dados estruturados podem ser facilmente indexados e pesquisados e os relatórios podem ser muito simplificados.

Os dados devem estar num formato agnóstico independente do computador, sistema operativo ou protocolo de rede. Por exemplo, emita informações num formato autodescrito como JSON, MessagePack ou Protobuf em vez de ETL/ETW. Um formato padrão permite ao sistema construir pipelines de processamento. Os componentes que leem, transformam e enviam dados no formato padrão podem ser facilmente integrados.

Dados da infraestrutura

Para recursos de infraestrutura na carga de trabalho, certifique-se de que recolhe registos e métricas. Para sistemas iaaS (infraestrutura como serviço), capture o SO, a camada da aplicação e os registos de diagnóstico, além de métricas relacionadas com o estado de funcionamento da carga de trabalho. Para recursos de plataforma como serviço (PaaS), pode estar limitado na sua capacidade de capturar registos relacionados com a infraestrutura subjacente, mas certifique-se de que consegue capturar registos de diagnósticos, além de métricas relacionadas com o estado de funcionamento da carga de trabalho.

Tanto quanto possível, recolha registos da sua plataforma na cloud. Poderá recolher registos de atividades para a sua subscrição e registos de diagnóstico para o plano de gestão.

Estratégias de coleção

Evite obter dados telemétricos manualmente a partir de cada componente. Mova os dados para uma localização central e consolide-os aí. Para uma solução de várias regiões, recomendamos que recolha, consolide e armazene dados numa base região a região e, em seguida, agregue os dados regionais num único sistema central.

Desvantagem: tenha em atenção que existem implicações de custos em ter arquivos de dados regionais e centralizados.

Para otimizar a utilização da largura de banda, priorize com base na importância dos dados. Pode transferir dados menos urgentes em lotes. No entanto, estes dados não podem ser atrasados indefinidamente, especialmente se contiverem informações sensíveis ao tempo.

Existem dois modelos principais que o serviço de recolha pode utilizar para recolher dados de instrumentação:

Modelo pull: obtém ativamente dados dos vários registos e de outras origens para cada instância da aplicação.
Modelo push: aguarda passivamente que os dados sejam enviados a partir dos componentes que constituem cada instância da aplicação.

Agentes de monitorização

Pode utilizar agentes de monitorização no modelo de solicitação. Os agentes são executados localmente num processo separado com cada instância da aplicação, solicitando periodicamente dados e escrevendo as informações diretamente no armazenamento comum que é partilhado por todas as instâncias da aplicação.

Nota

A utilização de um agente de monitorização é o processo mais adequado para capturar dados de instrumentação extraídos naturalmente de uma origem de dados. É adequado para uma aplicação de pequena escala que é executada num número limitado de nós numa única localização. Os exemplos incluem informações de SQL Server vistas de gestão dinâmica ou o comprimento de uma fila de Azure Service Bus.

Considerações de desempenho

Uma aplicação complexa e altamente dimensionável pode gerar grandes volumes de dados. A quantidade de dados pode facilmente sobrecarregar a largura de banda de E/S disponível para uma única localização central. A solução de telemetria não pode funcionar como estrangulamento e tem de ser dimensionável à medida que o sistema se expande. Idealmente, a solução deve incorporar um grau de redundância para reduzir os riscos de perda de informações de monitorização importantes (como dados de auditoria ou faturação) se parte do sistema falhar.

Uma forma de colocar os dados de instrumentação na memória intermédia é utilizar a colocação em fila:

Nesta arquitetura, o serviço de recolha de dados publica dados numa fila. Uma fila de mensagens é adequada porque fornece semântica "pelo menos uma vez" que ajuda a garantir que os dados em fila não serão perdidos depois de serem publicados. Pode implementar o serviço de escrita de armazenamento com uma função de trabalho separada. Pode utilizar o padrão Fila de Prioridade para implementar esta arquitetura.

Para escalabilidade, pode executar várias instâncias do serviço de escrita de armazenamento. Se estiver a ser monitorizado um elevado volume de eventos ou um elevado número de pontos de dados, pode utilizar Hubs de Eventos do Azure para distribuir os dados para uma instância de computação diferente para processamento e armazenamento.

Estratégias de consolidação

Os dados recolhidos de uma única instância de uma aplicação fornecem uma vista localizada do estado de funcionamento e do desempenho dessa instância. Para avaliar o estado de funcionamento geral do sistema, tem de consolidar alguns aspetos dos dados a partir das vistas locais. Pode fazê-lo depois de os dados serem armazenados, mas, em alguns casos, pode fazê-lo à medida que os dados são recolhidos.

Os dados de instrumentação podem passar por um serviço de consolidação de dados separado que combina dados e age como um processo de filtragem e limpeza. Por exemplo, pode juntar dados de instrumentação que incluem as mesmas informações de correlação, como um ID de atividade. (Um utilizador pode iniciar uma operação empresarial num nó e, em seguida, ser transferido para outro nó se o primeiro nó falhar ou devido à forma como o balanceamento de carga está configurado.) Este processo também pode detetar e remover quaisquer dados duplicados. (Pode ocorrer duplicação se o serviço de telemetria utilizar filas de mensagens para enviar dados de instrumentação para o armazenamento.)

Armazenamento

Quando escolher uma solução de armazenamento, considere o tipo de dados, a forma como são utilizados e a urgência com que são necessários.

Nota

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

Tecnologias de armazenamento

Considere uma abordagem de persistência poliglota, em que diferentes tipos de informações são armazenados em tecnologias mais adequadas à forma como cada tipo é susceptível de ser utilizado.

Por exemplo, Armazenamento de Blobs do Azure e o Armazenamento de Tabelas do Azure são acedidos de formas semelhantes. Contudo, as operações que pode efetuar nas mesmas diferem, assim como a granularidade dos dados que contêm. Se tiver de efetuar operações mais analíticas ou precisar de capacidades de pesquisa em texto completo nos dados, pode ser mais adequado utilizar um armazenamento de dados que forneça capacidades otimizadas para tipos específicos de consultas e acesso a dados. Por exemplo:

Os dados de contadores de desempenho podem ser armazenados numa base de dados SQL para permitir análises ad hoc.
Poderá ser melhor armazenar registos de rastreio nos Registos do Azure Monitor ou no Azure Data Explorer.
Pode armazenar informações de segurança numa solução HDFS.

Podem ser necessários os mesmos dados de instrumentação para mais do que um objetivo. Por exemplo, pode utilizar contadores de desempenho para fornecer uma vista histórica do desempenho do sistema ao longo do tempo. Estas informações podem ser combinadas com outros dados de utilização para gerar informações de faturação do cliente. Nestas situações, os mesmos dados podem ser enviados para mais do que um destino, como para uma base de dados de documentos que pode ser um arquivo de longo prazo para armazenar informações de faturação e para um arquivo multidimensional para processar análises de desempenho complexas.

Certifique-se de que ativa a funcionalidade para proteger os dados contra eliminações acidentais, como bloqueios de recursos e eliminação recuperável.

Além disso, certifique-se de que protege o acesso ao armazenamento através do controlo de acesso baseado em funções para ajudar a garantir que apenas as pessoas que precisam de aceder aos dados podem fazê-lo.

Serviço de consolidação

Pode implementar outro serviço que obtém periodicamente os dados de armazenamento partilhado, partições e filtra-os de acordo com o seu objetivo e, em seguida, escreve-os num conjunto adequado de arquivos de dados.

Uma abordagem alternativa é incluir esta funcionalidade no processo de consolidação e limpeza, e escrever os dados diretamente nestes arquivos à medida que são obtidos em vez de guardá-los numa área de armazenamento partilhada intermédia.

Cada abordagem tem vantagens e desvantagens. A implementação de um serviço de criação de partições 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 partilhado). No entanto, esta abordagem consome recursos adicionais. Além disso, pode haver um atraso entre a receção dos dados de instrumentação de cada instância da aplicação e a conversão dos dados em informações acionáveis.

Considerações de consulta

Considere a urgência com que os dados são necessários. Os dados que geram alertas têm de ser acedidos rapidamente, pelo que devem ser mantidos num armazenamento de dados rápido e indexados ou estruturados para otimizar as consultas executadas pelo sistema de alertas. Em alguns casos, poderá ser necessário que o serviço de recolha formate e guarde dados localmente para que uma instância local do sistema de alerta possa enviar notificações rapidamente. Os mesmos dados podem ser distribuídos pelo serviço de escrita de armazenamento mostrado nos diagramas anteriores e armazenados centralmente, caso sejam também necessários para outros fins.

Considerações sobre a retenção de dados

Em alguns casos, depois de os dados serem processados e transferidos, pode remover os dados originais da origem não processada que foram armazenados localmente. Noutros casos, pode ser necessário ou útil guardar as informações não processadas. Por exemplo, poderá querer manter os dados gerados para depuração disponíveis na sua forma não processada, mas depois eliminá-lo rapidamente depois de quaisquer erros serem resolvidos.

Os dados de desempenho têm, muitas vezes, uma vida útil mais longa para que possa utilizá-lo para detetar tendências de desempenho e planeamento de capacidade. A vista consolidada destes dados é normalmente mantida online durante um período finito para permitir um acesso rápido. Depois disso, pode ser arquivada ou eliminada.

É útil armazenar dados históricos para detetar tendências a longo prazo. Em vez de guardar dados antigos na sua totalidade, poderá conseguir reduzir a amostra dos dados para reduzir a resolução e poupar nos custos de armazenamento. Por exemplo, em vez de guardar indicadores de desempenho minuto a minuto, pode consolidar dados com mais de um mês para formar uma vista hora a hora.

Os dados recolhidos para clientes de medição e faturação podem ter de ser guardados indefinidamente. Além disso, os requisitos regulamentares podem ditar que as informações recolhidas para auditoria e segurança têm de ser arquivadas e guardadas. Estes dados também são confidenciais e podem ter de ser encriptados ou protegidos para evitar adulteração. Nunca deve registar palavras-passe de utilizador ou outras informações que possam ser utilizadas para cometer fraude de identidade. Deve limpar estes detalhes dos dados antes de serem armazenados.

Para garantir que cumpre as leis e regulamentos, minimize o armazenamento de quaisquer informações identificáveis. Se precisar de armazenar informações identificáveis, certifique-se de que, ao conceber a sua solução, tem de ter em conta os requisitos que permitem aos indivíduos pedir que as respetivas informações sejam eliminadas.

Análise

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

Como estruturar dados com base em KPIs e métricas de desempenho que definiu.
Como correlacionar os dados capturados em diferentes métricas e ficheiros de registo. Esta correlação é importante quando está a monitorizar 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, em seguida, combinados com precisão com dados gerados por outros componentes.

Por exemplo, uma aplicação de três camadas pode ter:

Uma camada de apresentação que permite que um utilizador se ligue a um site.
Uma camada média que aloja um conjunto de microsserviços que processa a lógica de negócio.
Uma camada de base de dados que armazena dados associados à operação.

Os dados de utilização de uma única operação empresarial podem abranger os três escalões. Estas informações têm de estar correlacionadas para fornecer uma vista geral do recurso e da utilização de processamento da operação. A correlação pode envolver algum pré-processamento e filtragem de dados na camada da base de dados. Na camada média, a agregação e formatação são tarefas comuns.

Recomendações

Correlacione os registos ao nível da aplicação e ao nível dos recursos. Avalie os dados em ambos os níveis para otimizar a deteção de problemas e a resolução de problemas desses problemas. Pode agregar os dados num único sink de dados ou tirar partido dos métodos que consultam eventos em ambos os níveis. Recomendamos uma solução unificada, como o Log Analytics do Azure, para agregar e consultar registos ao nível da aplicação e ao nível dos recursos.
Defina tempos de retenção claros no armazenamento para análise a frio. Recomendamos esta prática para permitir a análise histórica durante um período específico. Também pode ajudá-lo a controlar os custos de armazenamento. Implemente processos que garantem que os dados são arquivados num armazenamento mais barato e agregam dados para análise de tendências a longo prazo.
Analise as 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 que problemas operacionais poderão ocorrer e quando. Por exemplo, pode notar que os tempos médios de resposta estão a aumentar lentamente ao longo do tempo e a aproximar-se do destino máximo.

Para obter orientações detalhadas sobre estas recomendações, veja Analisar dados de monitorização de aplicações na cloud.

Visualização

Dashboards

A forma mais comum de visualizar dados é utilizar dashboards que podem apresentar informações como uma série de gráficos ou gráficos, ou noutro formato visual. Estes 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 os dashboards com o modelo de estado de funcionamento para que indiquem quando a carga de trabalho ou os componentes da carga de trabalho estão em bom estado de funcionamento, degradados ou em mau estado de funcionamento.

Para que um sistema de dashboards funcione eficazmente, tem de ter significado para a equipa de cargas de trabalho. Visualize informações relacionadas com o estado de funcionamento da carga de trabalho e que também podem ser acionáveis. Quando a carga de trabalho ou um componente está degradado ou em mau estado de funcionamento, os membros da equipa de carga de trabalho devem conseguir identificar facilmente a origem do problema na carga de trabalho e iniciar as respetivas ações ou investigações corretivas. Por outro lado, incluir informações que não sejam acionáveis ou que não estejam relacionadas com o estado de funcionamento da carga de trabalho pode tornar o dashboard desnecessariamente complexo e frustrante para os membros da equipa que estão a tentar discernir o ruído de fundo a partir de dados acionáveis.

Pode ter dashboards para intervenientes ou programadores que são personalizados para mostrar apenas dados sobre a carga de trabalho que consideram relevantes. Certifique-se de que a equipa de carga de trabalho compreende os tipos de pontos de dados que as outras equipas estão interessadas em ver e pré-visualiza os dashboards antes de os partilhar para verificar a clareza. Fornecer dashboards sobre a sua carga de trabalho para os intervenientes é uma boa forma de os manter informados sobre o estado de funcionamento da carga de trabalho, mas corre o risco de ser contraproducente se os intervenientes não entenderem claramente os dados que veem.

Um bom dashboard não apresenta apenas informações. Também permite que um analista coloque questões improvisadas sobre essa informação. Alguns sistemas fornecem ferramentas de gestão que um operador pode utilizar para concluir estas tarefas e explorar os dados subjacentes. Em vez disso, dependendo do repositório utilizado para armazenar as informações, poderá ser possível consultar os dados diretamente ou importá-los para ferramentas como o Excel para análise e relatórios adicionais.

Nota

Restringir o acesso ao dashboard a pessoal autorizado. As informações sobre dashboards podem ser sensíveis comercialmente. Também deve proteger os dados subjacentes para impedir que os utilizadores os alterem.

Relatórios

Os relatórios são utilizados para gerar uma vista geral do sistema. Pode incorporar dados históricos e informações atuais. Os requisitos de relatórios enquadram-se em duas categorias abrangentes: relatórios operacionais e relatórios de segurança.

Normalmente, os relatórios operacionais incluem o seguinte:

Agregar estatísticas que pode utilizar para compreender a utilização de recursos do sistema geral ou subsistemas especificados durante um período de tempo especificado.
Identificar tendências na utilização de recursos para o sistema geral ou subsistemas especificados durante um período especificado.
Exceções de monitorização que ocorreram em todo o sistema ou em subsistemas especificados durante um período especificado.
Determinar a eficiência da aplicação para os recursos implementados e compreender se o volume de recursos e os custos associados podem ser reduzidos sem afetar desnecessariamente o desempenho.

Os relatórios de segurança monitorizam a utilização do sistema por parte do cliente. Podem incluir:

Auditoria das operações do utilizador. Esta tarefa requer a gravação dos pedidos individuais que cada utilizador 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 utilizador conclui durante um período especificado.
Controlo da utilização de recursos pelo utilizador. Esta tarefa requer a gravação de como cada pedido de um utilizador acede aos vários recursos que compõem o sistema e durante quanto tempo. Um administrador pode utilizar estes dados para gerar um relatório de utilização, por utilizador, durante um período especificado, possivelmente para faturação.

Em muitos casos, os processos em lote podem gerar relatórios de acordo com uma agenda definida. A latência não é normalmente um problema. Também deve ter processos em lote que possam gerar relatórios de forma espontânea, conforme necessário. Por exemplo, se armazenar dados numa base de dados relacional, como SQL do Azure Base de Dados, pode utilizar uma ferramenta como SQL Server Reporting Services para extrair e formatar dados e apresentá-lo como um conjunto de relatórios.

Alertas

Para ajudar a garantir que o sistema permanece em bom estado de funcionamento, reativo e seguro, defina alertas para que os operadores possam responder aos mesmos em tempo útil. Um alerta pode conter informações contextuais suficientes para ajudá-los a começar rapidamente as atividades de diagnóstico. Os alertas podem ser utilizados para invocar funções de remediação, como o dimensionamento automático ou outros mecanismos de auto-recuperação. Os alertas também podem permitir a deteção de custos ao fornecer visibilidade sobre orçamentos e limites.

Recomendações

Defina um processo de resposta de alerta que identifique os proprietários e ações responsáveis.
Configure alertas para um âmbito bem definido (tipos de recursos e grupos de recursos) e ajuste a verbosidade para minimizar o ruído.
Utilize uma solução de alerta automatizada, como o Splunk ou o Azure Monitor, em vez de exigir que as pessoas procurem ativamente problemas.
Utilize alertas para operacionalizar processos de remediação. Por exemplo, crie automaticamente pedidos de suporte para controlar problemas e resoluções.
Controle o estado de funcionamento dos serviços da plataforma cloud em regiões, comunicação sobre interrupções, atividades de manutenção planeada e outros avisos de estado de funcionamento.

Limiares

Os alertas são gerados quando os limiares são ultrapassados, conforme detetado pelo sistema de monitorização. Certifique-se de que os limiares que definiu geralmente lhe dão tempo suficiente para implementar as alterações necessárias à carga de trabalho para evitar degradaçãos ou interrupções. Por exemplo, defina o limiar de dimensionamento automático para iniciar o dimensionamento antes que qualquer um dos sistemas em execução fique sobrecarregado até ao ponto de uma experiência de utilizador degradada. Baseie os valores de limiar que atribui à sua experiência anterior na gestão da infraestrutura e valide-os através dos testes que efetua como parte das suas práticas de teste.

Para obter orientações detalhadas sobre casos de utilização de alertas e outras considerações, veja Estruturar uma estratégia de monitorização e alerta fiável.

Facilitação do Azure

O Azure Monitor é uma solução de monitorização abrangente para recolher, analisar e responder à monitorização de dados a partir dos seus ambientes na cloud e no local.
O Log Analytics é uma ferramenta no portal do Azure que pode utilizar para editar e executar consultas de registo em dados na área de trabalho do Log Analytics.

Se estiver a utilizar várias áreas de trabalho, consulte o guia de arquitetura da área de trabalho do Log Analytics para obter as melhores práticas.
O Application Insights é uma extensão do Azure Monitor. Fornece funcionalidades do APM.
As Informações do Azure Monitor são ferramentas de análise avançadas para tecnologias específicas do Azure (como VMs, serviços de aplicações e contentores). Estas ferramentas fazem parte do Azure Monitor e do Log Analytics.
O Azure Monitor para soluções SAP é uma ferramenta de monitorização do Azure para paisagens SAP que são executadas no Azure.
Azure Policy pode ajudá-lo a impor normas organizacionais e a avaliar a conformidade em escala.

Ligações da comunidade

O Azure Monitor Baseline Alerts (AMBA) é um repositório central de definições de alerta que os clientes e parceiros podem utilizar para melhorar a experiência de observabilidade através da adoção do Azure Monitor.

Lista de verificação de Excelência Operacional

Veja o conjunto completo de recomendações.

Lista de verificação de Excelência Operacional

Recomendações para conceber e criar um sistema de monitorização