Práticas recomendadas para rastreamento e debug de microsserviços

Quando os aplicativos começaram a ser executados em pequenas fazendas, já não era possível saber exatamente qual máquina estava sendo executada. Um exame por toda a fazenda seria altamente ineficiente, mas muitas vezes era a única solução possível. “Com o advento da computação em nuvem, onde as instâncias de computação são efêmeras, não podemos confiar nos logs de máquina quando analisamos os dados de log.

Precisamos levar a sério a maneira como gerenciamos nossos logs para que tenhamos uma chance decente de rastrear e corrigir problemas”, comenta Andrew Rivers, engenheiro de software. “Ao passar de um sistema monolítico para um sistema distribuído, fazer o rastreamento e o debug pode se tornar uma tarefa realmente muito difícil. Felizmente, existem algumas coisas que podemos fazer para torná-la mais fácil”, diz.

Neste artigo, Andrew comenta algumas práticas que recomenda para o rastreamento e debug de microsserviços:

Centralize o armazenamento de logs

A primeira coisa a ser feita é tratar a integridade dos dados dos logs seriamente. Não se pode confiar em recuperar informações de uma máquina física posteriormente, especialmente em um ambiente virtual auto-escalável. “Já que não permitiríamos um design onde dados importantes do cliente sejam armazenados em uma única máquina virtual sem cópia de backup, o mesmo não deve ser feito para os logs”, afirma Andrew.

Não há nenhuma resposta certa para a forma como armazenamos as informações de log, seja em um banco de dados, em disco ou em um S3 bucket, mas precisamos ter a certeza de que o armazenamento usado seja duradouro e disponível.

Dica: Na AWS sempre é possível direcionar a saída para o CloudWatch. No Azure, considere usar o Application Insights.

Dados estruturados por log

Muitos dos componentes de log que recebemos produzirão documentos JSON para cada log em vez de produzir linhas em um arquivo de texto. Esse tipo de estrutura de dados é importante porque o processamento de log e as ferramentas de agrupamento podem processar facilmente cada registro, e as informações fornecidas em cada registro podem ser mais ricas.

Crie e habilite um identificador de correlação em todas as requisições

Quando recebemos uma requisição inicial que inicia algum processamento, precisamos criar um identificador com o qual possamos rastrear todo o caminho a partir dela e por todo o processamento subsequente. Se chamarmos outros componentes ou microsserviços para completar o processamento, então devemos passar o mesmo identificador de correlação a cada vez.

Cada um dos componentes subsequentes e microsserviços precisam usar esse identificador em seus próprios logs para que seja possível agrupar um histórico completo de todo o trabalho feito para processar uma requisição.

Retorne o identificador para o cliente

É muito interessante poder rastrear o fluxo através do sistema para uma determinada requisição, mas não muito divertido se recebermos uma chamada de suporte e não termos ideia de qual requisição precisa ser analisada.

Quando o cliente de API faz uma solicitação e inicia um processo, devemos retornar uma referência de transação nos cabeçalhos de resposta. Quando a equipe de operações precisa investigar o problema, ela deve ser capaz de fornecer a referência de transação com uma chamada de suporte para que seja possível encontrar as informações relevantes nos logs.

Torne os logs pesquisáveis

É um bom começo capturar os dados de log, mas muita informação acaba perdida no palheiro, mesmo em posse do identificador da agulha. Um suporte sério requer pesquisar e recuperar um conjunto de informações agrupadas e filtradas para uma mesma requisição.

Mesmo que os dados não estejam inicialmente sendo gravados em um data warehouse, é possível analisar o processamento offline que os carregam em um. Há muitas opções para isso, como a pilha ELK ou Redshift. Diante da pilha Azure, é possível escolher os Application Insights, como mencionado acima.

Permita que o nível de log seja alterado dinamicamente

A maioria dos frameworks de log suporta vários níveis de detalhamento. Normalmente, temos error, warning, info, debug, e verbose como níveis de log padrão disponíveis, e o código deve ser instrumentado adequadamente. Em produção, quando houver problemas em componentes específicos, é preciso alterar o rastreamento para debug ou verbose, a fim de capturar as informações de diagnóstico necessárias. Também é preciso fazer essa alteração para os níveis de log on the fly enquanto os sistemas estão em execução, diagnosticar o problema e, em seguida, retornar o log ao normal em seguida.

A detecção de falhas em microsserviços distribuídos pode ser difícil se não tivermos pronto acesso aos logs de todas as máquinas em que o código é executado. As instâncias de nuvem virtualizadas, que podem desaparecer a qualquer momento, exacerbam o problema porque não é possível retornar a uma instância de máquina mais tarde para ver o que aconteceu.

O planejamento da gestão de logs e como a descoberta de falhas é conduzida precisam ser feitos na fase de projeto, e executados com a ferramenta e técnica adequadas. Uma vez superada essa etapa, suportar os sistemas será algo muito mais fácil.

Fonte: DZone.com

Gostou do conteúdo? Tem alguma dúvida? Entre em contato com nossos Especialistas Mandic Cloud, ficamos felizes em ajudá-lo.