Padrões de observabilidade

Dica

Esse conteúdo é um trecho do livro eletrônico, para Projetar os Aplicativos .NET nativos de nuvem para o Azure, disponível no .NET Docs ou como um PDF para download gratuito que pode ser lido offline.

Baixar PDF

Assim como os padrões foram desenvolvidos para auxiliar no layout do código em aplicativos, há padrões para aplicativos operacionais de maneira confiável. Três padrões úteis na manutenção de aplicativos surgiram: registro em log, monitoramento e alertas.

Quando usar o registro em log

Não importa o quão cuidadosos sejamos, os aplicativos quase sempre se comportam de maneiras inesperadas na produção. Quando os usuários relatam problemas com um aplicativo, é útil ver o que estava acontecendo com o aplicativo quando o problema ocorreu. Uma das maneiras mais testadas e verdadeiras de capturar informações sobre o que um aplicativo está fazendo durante a execução é fazer com que o aplicativo anote o que está fazendo. Esse processo é conhecido como registrar em log. Sempre que ocorrerem falhas ou problemas na produção, a meta deve ser reproduzir as condições sob as quais ocorreram as falhas, em um ambiente de não produção. Ter um bom registro em log em vigor fornece um roteiro para que os desenvolvedores sigam para duplicar problemas em um ambiente que pode ser testado e experimentado.

Desafios ao fazer registro em log com aplicativos nativos de nuvem

Em aplicativos tradicionais, os arquivos de log normalmente são armazenados no computador local. Na verdade, em sistemas operacionais semelhantes ao Unix, há uma estrutura de pastas definida para manter todos os logs, normalmente em /var/log.

Figura 7-1. Registrar em log em um arquivo em um aplicativo monolítico.

A utilidade do registro em log em um arquivo simples em um único computador é muito reduzida em um ambiente de nuvem. Os aplicativos que produzem logs podem não ter acesso ao disco local ou o disco local pode ser altamente transitório, pois os contêineres são embaralhados em máquinas físicas. Mesmo a escala simples de aplicativos monolíticos em vários nós pode tornar desafiador localizar o arquivo de log baseado em arquivo apropriado.

Figura 7-2. Registrar em log em arquivos em um aplicativo monolítico dimensionado.

Aplicativos nativos de nuvem desenvolvidos usando uma arquitetura de microsserviços também representam alguns desafios para os agentes baseados em arquivo. As solicitações de usuário agora podem abranger vários serviços executados em computadores diferentes e podem incluir funções sem servidor sem acesso a um sistema de arquivos local. Seria muito desafiador correlacionar os logs de um usuário ou de uma sessão entre vários serviços e computadores.

Figura 7-3. Registro em log em arquivos locais em um aplicativo de microsserviços.

Por fim, o número de usuários em alguns aplicativos nativos de nuvem é alto. Imagine que cada usuário gera cem linhas de mensagens de log quando faz registro em um aplicativo. Isoladamente, isso é gerenciável, mas multiplique que mais de 100.000 usuários e o volume de logs se tornam grandes o suficiente para que ferramentas especializadas sejam necessárias para dar suporte ao uso efetivo dos logs.

Registrar em log em aplicativos nativos de nuvem

Toda linguagem de programação tem ferramentas que permitem a gravação de logs e, normalmente, a sobrecarga para gravar esses logs é baixa. Muitas das bibliotecas de registro em log fornecem registro de diferentes tipos de aspectos críticos, que podem ser ajustados em tempo de execução. Por exemplo, a biblioteca Serilog é uma biblioteca de registro em log estruturada popular para .NET que fornece os seguintes níveis de log:

• Detalhado
• Depurar
• Informações do
• Aviso
• Erro
• Fatal

Esses diferentes níveis de log fornecem granularidade no registro em log. Quando o aplicativo está funcionando corretamente na produção, ele pode ser configurado apenas para registrar mensagens importantes no log. Quando o aplicativo está funcionando inadequado, o nível de log poderá ser aumentado para que logs mais detalhados sejam coletados. Isso equilibra o desempenho em relação à facilidade de depuração.

O alto desempenho das ferramentas de log e a adequação da verbosidade devem incentivar os desenvolvedores a fazer o registro com frequência. Muitos favorecem um padrão de registro em log da entrada e saída de cada método. Essa abordagem pode parecer um exagero, mas é pouco frequente que os desenvolvedores desejem menos registro em log. Na verdade, não é incomum executar implantações com a única finalidade de adicionar registro em log em torno de um método problemático. Err no lado de muito registro em log e não em muito pouco. Algumas ferramentas podem ser usadas para fornecer automaticamente esse tipo de registro em log.

Devido aos desafios associados ao uso de logs baseados em arquivo em aplicativos nativos de nuvem, os logs centralizados são preferenciais. Os logs são coletados pelos aplicativos e enviados para um aplicativo de registro em log central que indexa e armazena os logs. Essa classe de sistema pode ingerir dezenas de gigabytes de logs todos os dias.

Também é útil seguir algumas práticas padrão ao criar logs que abrangem muitos serviços. Por exemplo, gerar uma ID de correlação no início de uma interação longa e, em seguida, registrar em log em cada mensagem relacionada a essa interação, facilita a pesquisa de todas as mensagens relacionadas. É necessário encontrar apenas uma única mensagem e extrair a ID de correlação para localizar todas as mensagens relacionadas. Outro exemplo é garantir que o formato de log seja o mesmo para cada serviço, seja qual for a linguagem ou a biblioteca de log que ele usa. Essa padronização facilita muito a leitura de logs. A Figura 7-4 demonstra como uma arquitetura de microsserviços pode aproveitar o registro em log centralizado como parte de seu fluxo de trabalho.

Figura 7-4. Os logs de várias fontes são ingeridos em um repositório de logs centralizado.

Desafios para detectar e responder os possíveis problemas de integridade do aplicativo

Alguns aplicativos não são críticos. Talvez eles sejam usados apenas internamente e, quando ocorre um problema, o usuário pode entrar em contato com a equipe responsável e o aplicativo pode ser reiniciado. No entanto, os clientes geralmente têm expectativas maiores para os aplicativos que consomem. Você deve saber quando ocorrem problemas com seu aplicativo antes dos usuários, ou antes que os usuários o notifiquem. Caso contrário, a primeira vez que você sabe sobre um problema pode ser quando você percebe um dilúvio raivoso de postagens nas redes sociais ridicularizando seu aplicativo ou até mesmo sua organização.

Alguns cenários que talvez você precise considerar incluem:

• Um serviço em seu aplicativo continua falhando e reiniciando, resultando em respostas lentas intermitentes.
• Em alguns momentos do dia, o tempo de resposta do aplicativo é lento.
• Após uma implantação recente, a carga no banco de dados foi triplicada.

Implementado corretamente, o monitoramento pode informá-lo sobre as condições que levarão a problemas, permitindo que você resolva as condições subjacentes antes que elas resultem em qualquer impacto significativo do usuário.

Monitoramento de aplicativos nativos de nuvem

Alguns sistemas de registro em log centralizados assumem uma função adicional de coleta de telemetria fora de logs puros. Eles podem coletar métricas, como tempo para executar uma consulta de banco de dados, tempo médio de resposta de um servidor Web e até mesmo médias de carga de CPU e pressão de memória, conforme relatado pelo sistema operacional. Em conjunto com os logs, esses sistemas podem fornecer uma visão holística da integridade dos nós no sistema e no aplicativo como um todo.

Os recursos de coleta de métricas das ferramentas de monitoramento também podem ser alimentados manualmente de dentro do aplicativo. Fluxos de negócios de interesse específico, como novos usuários que se inscrevem ou pedidos que estão sendo feitos, podem ser instrumentados de modo que incrementem um contador no sistema de monitoramento central. Esse aspecto desbloqueia as ferramentas de monitoramento para não apenas monitorar a integridade do aplicativo, mas a integridade dos negócios.

As consultas podem ser construídas nas ferramentas de agregação de log para procurar determinadas estatísticas ou padrões, que podem ser exibidos em forma gráfica, em painéis personalizados. Com frequência, as equipes investirão em grandes exibições montadas na parede que giram através das estatísticas relacionadas a um aplicativo. Dessa forma, é simples ver os problemas conforme eles ocorrem.

As ferramentas de monitoramento nativas de nuvem fornecem telemetria e insights em tempo real sobre aplicativos, independentemente de serem aplicativos monolíticos de processo único ou arquiteturas de microsserviço distribuído. Elas incluem ferramentas que permitem a coleta de dados do aplicativo, bem como ferramentas para consultar e exibir informações sobre a integridade do aplicativo.

Desafios para reagir a problemas críticos em aplicativos nativos de nuvem

Se você precisar reagir a problemas com seu aplicativo, precisará de alguma maneira para alertar o pessoal certo. Esse é o terceiro padrão de observabilidade do aplicativo nativo de nuvem e depende do registro em log e monitoramento. Seu aplicativo precisa ter o registro em log para permitir que os problemas sejam diagnosticados e, em alguns casos, se alimentar em ferramentas de monitoramento. Ele precisa de monitoramento para agregar métricas de aplicativo e dados de integridade em um só lugar. Depois que isso for estabelecido, as regras poderão ser criadas que dispararão alertas quando determinadas métricas ficarem fora dos níveis aceitáveis.

Em geral, os alertas são colocados em camadas sobre o monitoramento, de modo que determinadas condições disparem alertas apropriados para notificar os membros da equipe sobre problemas urgentes. Alguns cenários que podem exigir alertas incluem:

• Um dos serviços do aplicativo não está respondendo após 1 minuto de tempo de inatividade.
• Seu aplicativo está retornando respostas HTTP mal-sucedidas para mais de 1% das solicitações.
• O tempo médio de resposta do aplicativo para pontos de extremidade de chave excede 2.000 ms.

Alertas em aplicativos nativos de nuvem

Você pode criar consultas nas ferramentas de monitoramento para procurar condições de falha conhecidas. Por exemplo, as consultas podem pesquisar nos logs de entrada indicações do código de status HTTP 500, o que indica um problema em um servidor Web. Assim que um deles for detectado, um email ou um SMS poderá ser enviado ao proprietário do serviço de origem que pode começar a investigar.

Normalmente, porém, um único erro 500 não é suficiente para determinar que ocorreu um problema. Isso pode significar que um usuário digitou incorretamente sua senha ou inseriu alguns dados mal-formados. As consultas de alerta só podem ser acionadas quando um número maior que a média de erros 500 for detectado.

Um dos padrões mais prejudiciais no alerta é disparar muitos alertas para as pessoas investigarem. Os proprietários de serviços rapidamente serão dessensibilizados com erros que já investigaram e consideraram benignos. Em seguida, quando ocorrerem erros verdadeiros, eles serão perdidos no ruído de centenas de falsos positivos. A parábola do Garoto que Gritou Lobo é frequentemente instruída às crianças a avisá-las sobre esse perigo. É importante garantir que os alertas que disparam sejam indicativos de um problema real.

AnteriorAvançar