Recomendações para instrumentar um aplicativo

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 projetar e criar um sistema de monitoramento

Este guia descreve as recomendações para habilitar a observabilidade do seu aplicativo usando instrumentação. Gere telemetria significativa que pode ser ingerida e integrada ao seu sistema de monitoramento. Usando a instrumentação, você pode coletar informações sem entrar em um servidor de produção remoto para executar manualmente o rastreamento ou a depuração. Os dados de instrumentação incluem métricas e logs que você pode usar para avaliar o desempenho, diagnosticar problemas e tomar decisões de carga de trabalho.

Principais estratégias de design

Para otimizar a telemetria para sua carga de trabalho, instrumente seu aplicativo para gerar os seguintes dados:

• Os logs são registros com carimbo de data/hora de eventos discretos. Existem três formas de logs: texto simples, estruturado e binário.

• Os logs de rastreamento distribuídos permitem que você veja o caminho de uma solicitação à medida que ela percorre diferentes serviços e componentes.

• As métricas são valores numéricos que descrevem um aspeto de um sistema em um determinado momento.

Usar logs estruturados e rastreamento

Use o registro estruturado para integrar facilmente os logs em plataformas de monitoramento e análise. Instrumente sua aplicação para que os níveis de detalhamento possam ser alterados. O registro detalhado constante pode desperdiçar recursos de armazenamento, por isso deve ser ligado e desligado conforme necessário para a solução de problemas.

Os logs de rastreamento contêm dados textuais ou dados binários criados a partir de um evento de rastreamento, se o aplicativo usar o Rastreamento de Eventos para Windows (ETW). Os logs do sistema geram conteúdo de log de rastreamento a partir de eventos na infraestrutura, como o servidor Web. O conteúdo de log textual foi projetado para ser legível por humanos, mas você deve garantir que ele seja escrito em um formato que um sistema automatizado também possa analisar.

Categorize logs e use logs separados para registrar a saída de rastreamento de cada aspeto operacional do sistema. Se você categorizar seus logs, poderá filtrar rapidamente as mensagens de log em vez de processar um único arquivo longo. Nunca escreva informações com requisitos de segurança diferentes, como informações de auditoria e dados de depuração, no mesmo log.

Capture métricas de aplicativos

Métricas, ou amostras, são uma contagem de algum aspeto ou recurso no sistema em um momento específico, com uma ou mais tags ou dimensões associadas. Uma única instância de uma métrica não é útil isoladamente, as métricas devem ser capturadas ao longo do tempo. Considere quais métricas você deve registrar e com que frequência. Os dados gerados com muita frequência podem impor uma carga pesada ao sistema, mas a captura de dados pouco frequente pode fazer com que você perca as circunstâncias que levam a um evento significativo. A frequência apropriada para a captura de dados pode variar de métrica para métrica. Por exemplo, o uso da CPU em um servidor pode variar significativamente de segundo para segundo, mas o alto uso só se torna um problema se for consistente por muitos minutos.

Facilitar a correlação entre componentes

Você pode monitorar facilmente contadores de desempenho individuais e no nível do sistema, capturar métricas para recursos e obter informações de rastreamento de aplicativos de vários arquivos de log. Alguns monitoramentos exigem correlação de dados durante o estágio de análise e diagnóstico no pipeline de monitoramento. Esses dados podem assumir várias formas e o processo de análise deve ser fornecido com dados de instrumentação suficientes para mapear essas diferentes formas. Por exemplo, no nível da estrutura do aplicativo, um ID de thread pode identificar uma tarefa. Dentro de um aplicativo, o mesmo trabalho pode ser associado ao ID do usuário que conclui essa tarefa.

É improvável que seja um mapa 1:1 entre threads e solicitações de usuário, porque operações assíncronas podem reutilizar os mesmos threads para mais de um usuário. Para complicar ainda mais as coisas, uma única solicitação pode se correlacionar a mais de um thread à medida que flui pelo sistema. Se for possível, associe cada pedido com um ID de atividade exclusivo propagado pelo sistema como parte do contexto do pedido. A técnica para gerar e incluir IDs de atividade em informações de rastreamento depende da tecnologia usada para capturar os dados de rastreamento.

Todos os dados de monitorização devem ter o carimbo de data/hora da mesma forma. Por razões de consistência, registe todas as datas e horas através da Hora Universal Coordenada.

Capturar dados relevantes

Considere os seguintes pontos ao decidir quais dados de instrumentação você precisa coletar.

Dados legíveis por pessoas

Certifique-se de que as informações capturadas por eventos de rastreamento sejam legíveis por máquina e por humanos. Adote esquemas bem definidos para essas informações para ajudar a implementar o processamento automatizado de dados de log em todos os sistemas e para fornecer consistência para a equipe de operações e engenharia que lê os logs.

Inclua as seguintes informações ambientais em seus dados:

• Ambiente de implementação
• Máquina de processamento
• Detalhes do processo
• Pilha de chamadas

Investir na rastreabilidade e correlação

Forneça contexto suficiente, como um ID de atividade associado a uma instância específica de uma solicitação, para que o desenvolvedor ou administrador possa determinar a origem de cada solicitação.

O contexto de dados também pode incluir informações usadas para correlacionar uma atividade com o trabalho computacional realizado e os recursos usados. Este trabalho pode cruzar os limites do processo e da máquina.

Para a medição, o contexto deve incluir, direta ou indiretamente, uma referência ao cliente que causou o pedido. Este contexto fornece informações importantes sobre o estado da aplicação no momento em que os dados de monitorização foram capturados.

Capture todos os dados relevantes

Registre todas as solicitações e os locais ou regiões onde elas são feitas. Você pode usar essas informações para ajudar a identificar pontos de acesso específicos do local. Essas informações também podem ser úteis para determinar se um aplicativo deve ser reparticionado ou os dados que ele usa.

Registe e capture cuidadosamente os detalhes de exceções. As informações críticas de depuração geralmente são perdidas devido ao tratamento deficiente de exceções. Capture todos os detalhes de exceção que o aplicativo lança, incluindo exceções internas ou outras informações contextuais, como a pilha de chamadas, se possível.

Esforce-se pela consistência dos dados

Dados consistentes podem ajudá-lo a analisar eventos e correlacioná-los com as solicitações do usuário. Considere o uso de um pacote de log abrangente e configurável para coletar informações. Os pacotes de registro em log podem ajudá-lo a evitar a dependência de desenvolvedores para adotar sua abordagem à medida que implementam diferentes partes do sistema.

Reúna dados, como volume de entrada/saída, número de solicitações e uso de memória, rede e CPU, dos principais contadores de desempenho. Alguns serviços de infraestrutura fornecem seus próprios contadores de desempenho, como:

• O número de conexões com um banco de dados.
• A taxa de transação.
• O número de transações bem-sucedidas ou com falha.

Os aplicativos também podem definir seus próprios contadores de desempenho.

Considerar dependências externas

Registre todas as chamadas de serviço externo. As chamadas externas podem ser feitas para:

• Sistemas de bases de dados.
• Serviços Web.
• Outros serviços ao nível do sistema que fazem parte da infraestrutura.

Registar informações sobre a duração de cada chamada e o sucesso ou insucesso da chamada. Se possível, capture informações sobre todas as tentativas e falhas de repetição para quaisquer erros transitórios que ocorram.

Garantir a compatibilidade do sistema de telemetria

Em muitos casos, as informações de instrumentação são geradas como uma série de eventos e passadas para um sistema de telemetria separado para processamento e análise. Normalmente, um sistema de telemetria é independente de qualquer aplicação ou tecnologia específica.

Os sistemas de telemetria usam esquemas definidos para analisar informações. O esquema especifica um contrato que define os campos de dados e os tipos que o sistema de telemetria pode ingerir. Generalize o esquema para permitir a chegada de dados de várias plataformas e dispositivos. Um esquema comum deve incluir campos relevantes para todos os eventos de instrumentação, tais como:

• Nome do evento.
• Hora do evento.
• Endereço IP do remetente.
• Detalhes necessários para a correlação de eventos, incluindo:
  • ID de Utilizador
  • ID do Dispositivo
  • ID da aplicação

Lembre-se de que muitos dispositivos podem gerar eventos para o mesmo aplicativo, portanto, o esquema não deve depender do tipo de dispositivo. O aplicativo deve suportar roaming ou distribuição entre dispositivos. O esquema também pode incluir campos de domínio relevantes para um cenário específico que é comum entre aplicativos, como:

• Informações sobre exceções.
• Eventos de início e fim do aplicativo.
• Sucesso ou falha de chamadas de API de serviço Web.

Estabeleça campos de domínio que produzam o mesmo conjunto de eventos para criar um conjunto de relatórios e análises comuns entre aplicativos. Talvez seja necessário configurar um esquema para conter campos personalizados para capturar os detalhes de eventos específicos do aplicativo.

OpenTelemetry é uma coleção neutra do fornecedor de APIs, SDKs e outras ferramentas. Você pode usar o OpenTelemetry para instrumentar aplicativos e gerar telemetria significativa de forma consistente entre idiomas. O OpenTelemetry é independente de ferramentas, por isso é compatível com muitas plataformas de observabilidade, incluindo ofertas comerciais e de código aberto. A Microsoft está adotando o OpenTelemetry como a ferramenta padrão para instrumentação.

Otimizar o código de instrumentação

A lista a seguir resume as práticas recomendadas para instrumentar um aplicativo distribuído em execução na nuvem:

• Facilite a leitura e a análise dos registos. Utilize registos estruturados sempre que possível.

• Seja conciso e descritivo nas mensagens de registo.

• Identifique a origem do log.

• Adicione informações de carimbo de data/hora à medida que cada registro de log é gravado.

• Use o mesmo fuso horário e formato para todos os carimbos de data/hora.

• Categorize logs e escreva mensagens no local apropriado.

• Não revele informações confidenciais sobre o sistema ou informações pessoais sobre os usuários. Limpe essas informações antes de serem registradas, mas mantenha todos os detalhes relevantes.

• Registre todas as exceções críticas, mas permita que o administrador ative e desative o logon conforme necessário para menos exceções e avisos.

• Capture e registre todas as informações de lógica de repetição. Esses dados são úteis para monitorar a integridade transitória do sistema.

• Rastreie chamadas de processo, como solicitações para serviços Web externos ou bancos de dados.

• Não misture mensagens de registo com diferentes requisitos de segurança no mesmo ficheiro de registo.

• Certifique-se de que todas as chamadas de registro sejam operações de disparo e esquecimento que não bloqueiem o progresso das operações de negócios. Exclua os eventos de auditoria dessa regra porque eles são essenciais para os negócios.

• Certifique-se de que o registro em log seja extensível e não tenha dependências diretas em um destino concreto.

• Certifique-se de que todo o registro seja à prova de falhas e não acione erros em cascata.

• Trate a instrumentação como um processo iterativo contínuo e revise os logs regularmente.

Usar o perfil do aplicativo

• Implemente a criação de perfis somente quando necessário, pois ela pode impor uma sobrecarga significativa ao sistema. Usando instrumentação, a criação de perfil registra um evento, como uma chamada de método, sempre que ele ocorre. No entanto, a amostragem registra apenas eventos selecionados.

• As seleções de criação de perfil podem ser baseadas no tempo, como uma vez a cada n segundos, ou na frequência, como uma vez a cada n solicitações. Se os eventos ocorrerem com frequência, a criação de perfis pode sobrecarregar o sistema e afetar o desempenho geral. Neste caso, é preferível a abordagem por amostragem. No entanto, se a frequência de eventos for baixa, a amostragem pode perdê-los. Neste caso, a definição de perfis pode ser a melhor abordagem.

Facilitação do Azure

A Autoinstrumentação está disponível para muitos tipos de aplicativos do Azure e locais monitorados com o Application Insights. A função de autoinstrumentação configura automaticamente seu aplicativo para fornecer telemetria avançada ao Application Insights e fornece acesso fácil a experiências como o painel do aplicativo e o mapa do aplicativo. Para plataformas de hospedagem e linguagens de desenvolvimento suportadas, consulte Ambientes suportados, idiomas e provedores de recursos.

Ligações relacionadas

• Visão geral do Application Insights
• O que é a autoinstrumentação para o Application Insights?
• Visão geral dos logs do Azure Monitor
• Visão geral das métricas do Azure Monitor
• Coletando eventos ETW para análise de logs do Azure Monitor
• Recomendações para projetar e criar uma estrutura de observabilidade
• O que é rastreamento distribuído e correlação de telemetria?

Ligações da comunidade

• OpenTelemetria

Lista de verificação de Excelência Operacional

Consulte o conjunto completo de recomendações.