O registro é sem dúvida o elemento mais importante da sua solução de observabilidade. Os logs fornecem informações básicas e valiosas sobre o comportamento do sistema. Em um mundo ideal, você tomaria todas as decisões sobre o registro em log e implementaria uma abordagem consistente em todo o sistema.
No entanto, no mundo real, você pode trabalhar com software legado ou lidar com diferentes linguagens de programação, estruturas e pacotes de código aberto, cada um com seu próprio formato e estrutura para registro.
Com tanta diversidade de formatos de log em seu sistema, quais etapas você pode seguir para extrair o máximo valor de todos os seus logs? É isso que abordaremos neste post.
Veremos como os logs podem ser projetados, os desafios e soluções para o log em grandes sistemas e como pensar sobre métricas baseadas em log e retenção de longo prazo.
Vamos nos aprofundar nos níveis e formatos de log.
Muitas considerações são feitas no design do log, mas os dois aspectos mais importantes são o uso de níveis de log e se devem ser usados formatos de log estruturados ou não estruturados.
Os níveis de log são usados para categorizar mensagens de log com base em sua gravidade. Os níveis de log específicos usados podem variar dependendo da estrutura ou sistema de log. No entanto, os níveis de log comumente usados incluem (em ordem de detalhamento, do mais alto para o mais baixo):
O registro no nível apropriado ajuda a compreender o comportamento do sistema, identificar problemas e solucionar problemas de forma eficaz.
Quando se trata de componentes do sistema que você cria, recomendamos que você dedique algum tempo à definição do conjunto de níveis de log que são úteis. Entenda quais tipos de informações devem ser incluídas nas mensagens em cada nível de log e use os níveis de log de forma consistente.
Posteriormente, discutiremos como lidar com aplicativos de terceiros, nos quais você não tem controle sobre os níveis de log. Também veremos aplicativos legados que você controla, mas que são muito expansivos para serem migrados para os níveis de log padrão.
As entradas em logs estruturados têm um formato bem definido, geralmente como pares de valores-chave ou objetos JSON. Isso permite entradas de log consistentes e legíveis por máquina, facilitando a análise e análise de dados de log de forma programática.
O log estruturado permite consultas e análises avançadas de log, tornando-o particularmente útil em sistemas de grande escala.
Por outro lado, o log não estruturado (formato livre) captura mensagens em um formato mais legível, sem uma estrutura predefinida. Essa abordagem permite que os desenvolvedores registrem mensagens de maneira mais natural e flexível.
No entanto, extrair programaticamente informações específicas dos logs resultantes pode ser muito desafiador.
A escolha entre logs estruturados e não estruturados depende de suas necessidades específicas e dos requisitos e restrições do seu sistema. Se você antecipar a necessidade de análise avançada de logs ou integração com ferramentas de análise de logs, os logs estruturados podem fornecer benefícios significativos.
No entanto, se tudo o que você precisa é de simplicidade e legibilidade, os logs não estruturados podem ser suficientes.
Em alguns casos, também pode ser utilizada uma abordagem híbrida, onde se utilizam registos estruturados para eventos importantes e registos não estruturados para mensagens mais gerais.
Para sistemas de grande escala, você deve optar pelo registro estruturado sempre que possível, mas observe que isso adiciona outra dimensão ao seu planejamento. A expectativa para mensagens de log estruturadas é que o mesmo conjunto de campos seja usado de forma consistente em todos os componentes do sistema. Isso exigirá planejamento estratégico.
Com sistemas compostos por múltiplos componentes, cada componente provavelmente terá seu próprio modelo para gerenciar seus logs. Vamos revisar os desafios que isso traz.
Os componentes serão registrados em destinos diferentes – arquivos, logs do sistema, stdout ou stderr. Em sistemas distribuídos, coletar esses logs dispersos para uso eficaz é complicado.
Para isso, você precisará de uma abordagem diversificada para coleta de logs, como usar coletores instalados e coletores hospedados do Sumo Logic.
Alguns componentes usarão log não estruturado e de formato livre, sem seguir nenhum formato em particular. Enquanto isso, os logs estruturados podem ser mais organizados, mas os componentes com logs estruturados podem empregar conjuntos de campos completamente diferentes.
Unificar as informações obtidas de uma diversidade de registros e formatos requer as ferramentas certas.
Os componentes do seu sistema podem usar diferentes intervalos de níveis de log. Mesmo se você consolidar todas as mensagens de log em um sistema de log centralizado (como deveria), precisará lidar com a união de todos os níveis de log.
Um desafio que surge é quando diferentes níveis de log devem ser tratados da mesma forma. Por exemplo, ERRO em um componente pode ser igual a CRÍTICO em outro componente, exigindo escalonamento imediato.
Você enfrenta o desafio oposto quando o mesmo nível de log em componentes diferentes significa coisas diferentes. Por exemplo, as mensagens INFO em um componente podem ser essenciais para a compreensão do estado do sistema, enquanto em outro componente podem ser muito detalhadas.
Grandes sistemas distribuídos acumulam muitos logs. Coletar e armazenar esses logs não é barato. Os custos relacionados aos logs na nuvem podem representar uma parcela significativa do custo total do sistema.
Embora os desafios do registro em sistemas grandes e distribuídos sejam significativos, soluções podem ser encontradas por meio de algumas das práticas a seguir.
Ao executar um sistema distribuído, você deve usar uma solução de registro centralizada. À medida que você executa agentes de coleta de logs em cada máquina do seu sistema, esses coletores enviarão todos os logs para sua plataforma central de observabilidade.
Sumo Logic, que sempre se concentrou no gerenciamento e análise de logs , é o melhor da categoria quando se trata de agregação de logs.
Lidar com logs em formatos diferentes é um grande problema se você deseja correlacionar dados de log para análise e solução de problemas em aplicativos e componentes. Uma solução é transformar diferentes logs em um formato unificado.
O nível de esforço para esta tarefa pode ser alto, então considere fazer isso em fases, começando com os componentes mais essenciais e indo descendo.
Para seus próprios aplicativos, trabalhe para estabelecer uma abordagem de log padrão que adote um conjunto uniforme de níveis de log, um único formato de log estruturado e uma semântica consistente.
Se você também tiver aplicativos legados, avalie o nível de risco e custo associado à migração deles para aderir ao seu padrão.
Se uma migração não for viável, trate seus aplicativos legados como trataria aplicativos de terceiros.
Enriquecer logs de fontes de terceiros envolve aprimorar os dados de log com informações contextuais de sistemas ou serviços externos. Isso traz uma melhor compreensão dos eventos de log, auxiliando na solução de problemas, análise e atividades de monitoramento.
Para enriquecer seus logs, você pode integrar sistemas externos (como APIs ou filas de mensagens) para buscar dados complementares relacionados a eventos de log (como informações do usuário, detalhes do cliente ou métricas do sistema).
O gerenciamento cuidadoso do volume, da frequência e da retenção de logs é crucial para um gerenciamento e armazenamento eficientes de logs.
As métricas derivadas da análise de dados de log podem fornecer insights sobre o comportamento e o desempenho do sistema. Trabalhar com métricas baseadas em logs tem seus benefícios e desafios.
Definir métricas significativas : como o conjunto de métricas disponíveis em todos os seus componentes é incrivelmente vasto (e não faria sentido capturar todas elas), identificar quais métricas capturar e extrair dos logs pode ser uma tarefa complexa.
Essa identificação requer uma compreensão profunda do comportamento do sistema e um alinhamento próximo com seus objetivos de negócios.
Extração e análise de dados : a análise de logs para extrair métricas úteis pode exigir ferramentas especializadas ou analisadores personalizados. Isso é especialmente verdadeiro se os logs não estiverem estruturados ou formatados de forma inconsistente de um componente para outro.
Configurar isso pode ser demorado e exigir manutenção à medida que os formatos de log mudam ou surgem novas fontes de log.
Depois de migrar para a agregação de logs em um sistema centralizado, você ainda precisará considerar políticas de retenção de logs de longo prazo. Vamos cobrir as questões críticas para esta área.
Por quanto tempo você deve manter um registro depende de vários fatores, incluindo:
Excluir logs antigos é, obviamente, a maneira mais simples de reduzir seus custos de armazenamento. No entanto, pode ser um pouco pesado e, às vezes, você pode querer manter informações de registros antigos.
Quando você quiser manter informações de registros antigos, mas também quiser ser econômico, considere tomar algumas destas medidas:
Neste artigo, vimos como aproveitar ao máximo o registro em log em sistemas de grande escala.
Embora o registo nestes sistemas apresente um conjunto único de desafios, analisámos soluções potenciais para estes desafios, tais como agregação de registos, transformação de registos num formato unificado e enriquecimento de registos com dados de fontes de terceiros.
O registro é uma parte crítica da observabilidade. Seguindo as práticas descritas neste artigo, você pode garantir que seus logs sejam gerenciados de forma eficaz, permitindo solucionar problemas, identificar problemas e obter insights sobre o comportamento do seu sistema.
E você pode fazer isso enquanto mantém os custos de registro sob controle.
Também publicado aqui