Recomendações para a conceção e criação de um sistema de monitorização

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

Guia relacionado: Recomendações para instrumentar um aplicativo

Este guia descreve as recomendações para projetar e criar um sistema de monitoramento. Para monitorar efetivamente sua carga de trabalho quanto à 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, deteção e alerta.

Definições

Principais estratégias de design

Para implementar um projeto de sistema de monitoramento abrangente para sua carga de trabalho, siga estes princípios básicos:

• Sempre que possível, aproveite as ferramentas de monitoramento fornecidas pela plataforma, que normalmente exigem muito pouca configuração e podem fornecer informações detalhadas sobre sua carga de trabalho que, de outra forma, poderiam 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 aplicativos devem ser configurados para produzir dados padronizados e significativos, e esses 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 painéis ou relatórios significativos para equipes de carga de trabalho e outras partes interessadas.

• 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 alerta em suas práticas gerais de teste de carga de trabalho.

• Garantir que os sistemas de monitorização e alerta estão em condições de 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 projetos de monitoramento e alerta.

• Vincule os dados de monitoramento que você coleta e analisa 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 saúde.

Você deve automatizar todas as funções do sistema de monitoramento tanto quanto possível, e todos eles devem funcionar continuamente, durante todo o dia, todos os dias.

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

Coletar dados de instrumentação

Você deve configurar todos os componentes da 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 detetar e investigar anomalias. Normalmente, os logs são produzidos pelo componente de carga de trabalho e, em seguida, enviados para a plataforma de monitoramento ou puxados 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 na 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 perspetiva do cliente. Normalmente, as métricas são definidas na plataforma de monitoramento, e a plataforma de monitoramento e outras ferramentas pesquisam a carga de trabalho para capturar métricas.

Dados de aplicação

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 é ativado, você tem visibilidade clara de métricas importantes, em tempo real e historicamente. Use um nível apropriado de registro. O registro detalhado pode incorrer em custos significativos. Defina os níveis de log de acordo com o ambiente. Ambientes mais baixos não precisam do mesmo nível de detalhamento que a produção, por exemplo.

Os logs de aplicativos suportam o ciclo de vida completo do aplicativo. O registro em log é essencial para entender como o aplicativo opera em vários ambientes, quais eventos ocorrem e as condições em que eles ocorrem.

Recomendamos que você colete logs e eventos de aplicativos em todos os principais ambientes. Separe os dados entre ambientes tanto quanto 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. Finalmente, as entradas de log correspondentes no aplicativo devem capturar um ID de correlação para suas respetivas transações.

Você deve capturar eventos de aplicativo em tipos de dados estruturados com pontos de dados legíveis por máquina em vez de tipos de cadeia de caracteres não estruturados. Um formato estruturado que usa um esquema bem 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 muito simplificados.

Os dados devem estar em um formato agnóstico que seja independente da máquina, do sistema operacional ou do protocolo de rede. Por exemplo, emita informações em um formato autodescritivo como JSON, MessagePack ou Protobuf em vez de ETL/ETW. Um formato padrão permite que o sistema construa pipelines de processamento. Os 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 o sistema operacional, a camada de aplicativos e os logs de diagnóstico, além das métricas relacionadas à integridade da carga de trabalho. Para recursos de plataforma como serviço (PaaS), você pode estar limitado em sua capacidade de capturar logs relacionados à infraestrutura subjacente, mas certifique-se de que pode capturar logs de diagnóstico, além de métricas relacionadas à integridade da carga de trabalho.

Na medida do possível, colete logs de sua plataforma de nuvem. Talvez você consiga coletar logs de atividades para sua assinatura e logs de diagnóstico para o plano de gerenciamento.

Estratégias de recolha

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

Compensação: esteja ciente de que há implicações de custo em 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, estes dados não devem ser adiados indefinidamente, especialmente se contiverem informações sensíveis em termos de tempo.

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

• Modelo de extração: recupera ativamente dados de vários logs e outras fontes para cada instância do aplicativo.

• Modelo push: aguarda passivamente que os dados sejam enviados dos componentes que constituem cada instância do aplicativo.

Agentes de monitorização

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

Considerações sobre desempenho

Um aplicativo complexo e altamente escalável pode gerar grandes volumes de dados. A quantidade de dados pode facilmente sobrecarregar a largura de banda de E/S disponível para um único local central. A solução de telemetria não deve atuar como gargalo e deve ser escalá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 importantes de monitoramento (como dados de auditoria ou faturamento) se parte do sistema falhar.

Uma maneira de armazenar dados de instrumentação em buffer é usar o enfileiramento:

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 publicados. Você pode implementar o serviço de gravação de armazenamento usando uma função de trabalho separada. Você pode usar o padrão Priority Queue 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 os Hubs de Eventos do Azure para despachar 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 aspetos 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 combina dados e atua como um processo de filtro e limpeza. Por exemplo, você pode amalgamar dados de instrumentação que incluam as mesmas informações de correlação, como um 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.) Este processo também pode detetar e remover quaisquer dados duplicados. (A duplicação pode ocorrer se o serviço de telemetria usar filas de mensagens para enviar dados de instrumentação para o armazenamento.)

Armazenar dados para consulta e análise

Ao escolher uma solução de armazenamento, considere o tipo de dados, como eles são usados e com que urgência são necessários.

Tecnologias de armazenamento

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

Por exemplo, o Armazenamento de Blobs do Azure e o Armazenamento de Tabela do Azure são acessados de maneiras semelhantes. Mas as operações que você pode executar neles diferem, assim como a granularidade dos dados que eles 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.

• 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.

Podem ser necessários os mesmos dados de instrumentação para mais do que um objetivo. Por exemplo, você pode usar contadores de desempenho para fornecer uma visão 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. 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 armazenamento de longo prazo para armazenar informações de faturamento e para um armazenamento multidimensional para lidar com análises de desempenho complexas.

Certifique-se de ativar a funcionalidade para proteger os dados contra exclusão acidental, como bloqueios de recursos e exclusão suave.

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 os 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, particiona e filtra-os de acordo com sua finalidade e, em seguida, grava-os em um conjunto apropriado de armazenamentos 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 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 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.

Consultando considerações

Considere a urgência com que os dados são necessários. Os dados que geram alertas devem ser acessados rapidamente, por isso devem ser mantidos em armazenamento rápido de dados e indexados ou estruturados para otimizar as consultas que o sistema de alertas realiza. 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 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 retenção de dados

Em alguns casos, depois que os dados são processados e transferidos, você pode remover os dados de origem brutos originais que foram armazenados localmente. Em outros casos, pode ser necessário ou útil salvar as informações brutas. Por exemplo, você pode querer manter os dados gerados para depuração disponíveis em sua forma bruta, mas 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 detetar tendências de desempenho e para o planejamento 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 salvar dados antigos em sua totalidade, você poderá reduzir a amostra dos 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 para formar uma exibição 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 normativos podem ditar que as informações coletadas para auditoria e segurança precisam ser arquivadas e salvas. 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. Você deve limpar esses detalhes dos dados antes que eles sejam armazenados.

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

Analise dados para entender a integridade de uma carga de trabalho

Depois de coletar dados de várias fontes 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 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, em seguida, combinados com precisão com 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 as três camadas. Essas informações precisam ser correlacionadas para fornecer uma visão geral do uso de recursos e processamento para a operação. A correlação pode envolver algum 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

• Correlacione logs no nível do aplicativo e no nível do recurso. Avalie os dados em ambos os níveis para otimizar a deteção de problemas e a solução 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 esta prática para permitir a análise histórica ao longo de um período específico. Também pode ajudá-lo a controlar os custos de armazenamento. Implemente processos que garantam que os dados sejam arquivados em armazenamento mais barato e agregar dados para análise de tendências de longo prazo.

• Analise tendências de longo prazo para prever problemas operacionais. Avalie 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 notar que os tempos médios de resposta estão aumentando lentamente ao longo do tempo e se aproximando da meta máxima.

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

Visualizar relatórios de integridade da carga de trabalho

Dashboards

A maneira mais comum de visualizar dados é usar painéis que podem exibir informações como uma série de gráficos ou tabelas, 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 painel funcione de forma eficaz, ele deve ser significativo para a equipe de carga de trabalho. Visualize informações relacionadas à integridade da carga de trabalho e que também sejam acionáveis. Quando a carga de trabalho ou um componente está degradado ou não íntegro, os membros da equipe de carga de trabalho devem ser capazes de identificar facilmente onde o problema se origina na carga de trabalho 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 painel desnecessariamente complexo e frustrante para os membros da equipe que estão tentando discernir o ruído de fundo dos dados acionáveis.

Você pode ter painéis para partes interessadas ou desenvolvedores que são personalizados para mostrar apenas dados sobre a carga de trabalho que eles consideram relevantes. Certifique-se de que a equipe de carga de trabalho entenda os tipos de pontos de dados que outras equipes estão interessados em ver e visualize os painéis antes de compartilhá-los para verificar a clareza. Fornecer painéis sobre sua carga de trabalho para as partes interessadas é uma boa maneira de mantê-las informadas sobre a integridade da carga de trabalho, mas corre o risco de ser contraproducente se as partes interessadas não entenderem claramente os dados que veem.

Um bom painel não exibe apenas informações. Também permite que um analista faça perguntas improvisadas sobre essas informações. Alguns sistemas fornecem ferramentas de gerenciamento que um 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, pode ser possível consultar os dados diretamente ou importá-los para ferramentas como o Excel para análise e relatórios adicionais.

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 comunicação de informações dividem-se em duas grandes categorias: relatórios operacionais e relatórios de segurança.

Os relatórios operacionais geralmente incluem o seguinte:

• Agregando estatísticas que você pode usar para entender a utilização de recursos do sistema geral ou subsistemas especificados durante uma janela de tempo especificada.

• Identificação de tendências no uso de recursos para o sistema geral ou subsistemas especificados durante um período especificado.

• Monitoramento de 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. Podem incluir:

• Auditoria das operações do utilizador. Esta tarefa requer o registo 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 usuário conclui durante um período especificado.

• Controlo da utilização de recursos pelo utilizador. Esta tarefa requer o registro 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 faturamento.

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

Definir alertas para eventos-chave

Para ajudar a garantir que o sistema permaneça saudável, responsivo e seguro, defina alertas para que os operadores possam respondê-los em tempo hábil. Um alerta pode conter informações contextuais suficientes para ajudá-los a iniciar rapidamente as atividades de diagnóstico. O alerta pode ser usado para invocar funções de correção, como dimensionamento automático ou outros mecanismos de autorrecuperação. Os alertas também podem permitir o reconhecimento de custos, fornecendo visibilidade sobre orçamentos e limites.

Recomendações

• Defina um processo de resposta de alerta que identifique os proprietários responsáveis e as ações.

• Configure alertas para um escopo bem definido (tipos de recursos e grupos de recursos) e ajuste a verbosidade para minimizar o ruído.

• Use uma solução de alerta automatizada, como o Splunk ou o Azure Monitor, em vez de exigir que as pessoas procurem ativamente os problemas.

• Use alertas para operacionalizar processos de correção. Por exemplo, crie tíquetes automaticamente para rastrear problemas e resoluções.

• Acompanhe a integridade dos serviços da sua plataforma de nuvem em regiões, comunicação sobre interrupções, atividades de manutenção planejadas e outros avisos de saúde.

Limiares

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

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

Facilitação do Azure

• O Azure Monitor é uma solução de monitorização abrangente para recolher, analisar e responder a dados de monitorização a partir da sua nuvem e ambientes locais.

• 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 espaço de trabalho do Log Analytics.

  Se você estiver usando vários espaços de trabalho, consulte o guia de arquitetura do espaço de trabalho do Log Analytics para obter práticas recomendadas.

• O Application Insights é uma extensão do Azure Monitor. Ele fornece recursos de APM.

• O Azure Monitor Insights é uma ferramenta de análise avançada para tecnologias específicas do Azure (como VMs, serviços de aplicativo e contêineres). Essas ferramentas fazem parte do Azure Monitor e do Log Analytics.

• O Azure Monitor for SAP solutions é uma ferramenta de monitoramento do Azure para cenários SAP executados no Azure.

• A Política do Azure pode ajudá-lo a aplicar padrões organizacionais e avaliar a conformidade em escala.

Ligações relacionadas

• Guia de instrumentação
• Recomendações para a conceção de uma estratégia fiável de monitorização e alerta
• Recomendações para monitorização e deteção de ameaças
• Recomendações para a recolha de dados de desempenho

Ligações da comunidade

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

Lista de verificação de Excelência Operacional

Consulte o conjunto completo de recomendações.