Como foi mencionado no texto Observabilidade e Monitoramento, a observabilidade permite que as equipes atuem com mais rapidez e eficiência nos efeitos e causas geradas por sistemas.
Para isso, podemos contar com os 3 pilares da observabilidade, métrica, trace e log, no capítulo 4 do ebook Distributed-Systems-Observability, a autora menciona, que ter acesso à métrica, trace e log não necessariamente torna o sistema mais observável, esses sinais são importantes e se bem compreendidos, podem gerar insights valiosos para melhorar o sistema.
Log
Log é um registro de evento relevante e imutável gerado por sistema computacional ao longo do tempo. Imagine um diário de bordo, onde os navegadores registram os acontecimentos mais importantes de sua jornada mar adentro.
Os registos de log são considerados um dos elementos fundamentais para qualquer sistema, e todos os registos de log possuem no mínimo 3 características, carimbo de data e hora do momento que o evento foi gerado, uma mensagem que descreve o acontecimento e uma severidade (INFO, WARN, ERROR, EMERGENCY) que classifica o tipo de evento.
Em ambientes distribuídos, os logs podem se tornar complexos devido ao excesso de informações geradas pelos sistemas.
A grande maioria das equipes adotam padrões e boas práticas para gerenciar eventos de logs.
Logs devem ser registrados no formato JSON, é adotado devido à sua estrutura organizada e fácil de analisar.
Informações de origem do registro do evento de logs, esse tipo de informação é muito útil em ambientes distribuídos. Segundo a documentação do OpenTelemetry, com esse tipo de abordagem podemos capturar a hierarquia de identificação da entidade que originou o evento. O log deve conter informação que descreve qual é o cluster, host, namespace, pod, contêiner, etc.
É esperado que toda inicialização e encerramento do sistema seja logado, isso ajuda a identificar possíveis problemas durante o processo de inicialização e encerramento do sistema.
Erros e Exceções, causas não esperadas na lógica do sistema precisam ser registradas.
Correlação de log e trace, segundo a documentação do OpenTelemetry, é uma prática padrão registrar o contexto de rastreamento (IDs de rastreamento e span, bem como contexto* definido pelo usuário) nos spans. O OpenTelemetry desenvolve essa prática aos logs incluindo TraceId e SpanId nos eventos de log.
O que é contexto*? são informações importantes do sistema, estado do sistema, configuração, metadados de telemetria e outras informações que ajudam a entender o funcionamento e o comportamento do sistema.
Cuidado com dados sensíveis, os registros de log não podem conter dados sensíveis como dados de usuário, chaves de segurança, segredos, etc.
Padrão de atributos de logs, em ambientes distribuídos cada equipe adota uma linguagem de programação para desenvolver seus sistemas. Cada linguagem possui bibliotecas e frameworks para instrumentar log e cada uma pode conter campos e formatos diferentes. Por exemplo, em um sistema desenvolvido em Python o campo http status code pode ser http.status_code enquanto na linguagem golang esse mesmo campo pode ser http.statuscode, essas diferenças entre atributos de log pode dificultar pesquisas no vendor de observabilidade.
Estas são apenas algumas recomendações propostas pela grande maioria dos serviços que coletam, processam, transmitem e armazenam dados de telemetria. É importante salientar que cada organização pode adotar um padrão próprio, conforme o negócio.
A seguir temos um exemplo de um log em JSON, isso ajuda a entender o modelo de dados dos eventos gerados por sistemas distribuídos. O objetivo do log é registrar, o que aconteceu e quando aconteceu.
{
"Timestamp": 1687520180000, //carimbo data e hora no formato epoch
"Attributes": { //atributos do evento gerado pelo sistema
"http.scheme": "https",
"http.method": "post",
"http.status_code": 500,
"http.url": "https://rapadura.com",
"http.target":"/order",
"my.custom.application.tag": "blablabla",
},
"Resource": { //informações da origem que gerou o evento
"service.name": "rapadura-shop",
"service.version": "v1.0.0",
"k8s.cluster.name": "k8s-cluster-prd",
"k8s.namespace": "app-rapadura",
"k8s.pod.uid": "1138528c-c36e-11e9-a1a7-42010a800198",
},
"TraceId": "f4dbb3edd765f620", //informações para correlacionar o log ao trace
"SpanId": "43222c2d51a7abe3",
"SeverityText": "ERROR", //categoria do log
"SeverityNumber": 17,
"Body": "I like rapadura" //mensagem do acontecimento
}
Trace
Também conhecido como rastreamento, trace ou tracing, possibilita acompanhar o fluxo e a condição de uma transação. Segundo a documentação do OpenTelemetry, os traces fornece uma visão geral do caminho e o que acontece quando uma solicitação é feita em um sistema.
O trace conta a história da interação entre sistemas distribuídos, uma transação pode interagir com vários sistemas o trace possibilita identificar qual sistema está causando a falha.
A imagem acima representa um trace, e cada interação nessa requisição é chamada de span (período), cada trace e cada span possui um identificador único, são conhecidos como traceid e spanid, esses valores serve para identificar as interações na transação.
Na figura é possível perceber que o tempo total dessa requisição foi de 320 milissegundos, bem como quais componentes essa transação interagiu e o tempo de interação.
Os registros de trace auxiliam as equipes a compreender as dependências entre sistemas, aumento de latência, onde a requisição falhou, o trace ajuda a atribuir um possível problema a um o serviço específico.
Métrica
Métrica é uma representação numérica de uma informação em relação ao tempo. As métricas fornecem uma visão geral da integridade do sistema ou ambiente.
As métricas também são úteis para escalar o ambiente para atender a demanda do sistema, sendo muito utilizados para criar alerta e são mais adequadas para criar dashboards.
A métrica é composta por um nome da métrica (por exemplo, http_requests_total), o registro de data e hora (com precisão em milissegundos), pelo valor da métrica (um valor float64) e tags, é a possibilidade de agregação da métrica (por exemplo, solicitações HTTP com método POST).
Após a coleta, as métricas apresentam maior flexibilidade para cálculos matemáticos, probabilidade, estatistificas, amostragem, etc. Essas características tornam as métricas mais adequadas para demostrar a integridade do sistema.
Conclusão
Os três pilares da observabilidade trace, métrica e log são complementares para compreender o comportamento e do desempenho de um sistema.
Como Brian Knox menciona:
The goal of an Observability team is not to collect logs, metrics, or traces. It is to build a culture of engineering based on facts and feedback, and then spread that culture within the broader organization.
A observabilidade não se limita a trace, log e métrica, trata-se de construir uma cultura onde as equipes sejam guiadas por fatos e comunicação.
Referências
- OpenTelemetry - Logs Data Model
- Humio - eBook Free - Distributed Systems Observability
- Elven Works - Os 3 Pilares da Observabilidade em sistemas distribuídos
- eBook SRE Google - Chapter 6 - Monitoring Distributed Systems
- Coralogix - Tracing vs. Logging: What You Need To Know
- W3 - Trace Context
- Prometheus - Data Model
Top comments (0)