O Princípio de responsabilidade única, cunhado por Robert C. Martin, basicamente diz: "junte as coisas que mudam pelo mesmo motivo, e separe as coisas que mudam por motivos diferentes".
Uma arquitetura de micro serviços exerce muito bem esse princípio e traz uma série de benefícios na capacidade de desenvolver, manter e publicar de forma independente os diferentes componentes de um sistema. O aumento da granularidade traz também alguns pontos negativos e uma preocupação constante ao adotar micro serviços é o aumento da complexidade no monitoramento do sistema e na dificuldade de entender por que algo deu errado, identificar gargalos de performance e ter uma visão macro do funcionamento do sistema.
Distributed Tracing
É aqui que Distributed Tracing entra, como uma série de técnicas que tem como principal objetivo prover aos desenvolvedores uma maneira de rastrear requisições individuais enquanto elas "pulam" de árvore em arvore numa floresta de micro serviços. Em vez de monitorar entidades ou eventos isolados, Distributed Tracing nos permite acompanhar traces de cada componente envolvido. cada trace é composto de spans que registram detalhes da interação com um componente.
São possibilidades desbloqueadas ao adotar alguma forma de Distributed Tracing:
- Saber exatamente o caminho percorrido para uma determinada solicitação.
- Mensurar a latência de cada componente ao longo do caminho.
- Identificar qual serviço gera uma falha ou um gargalo.
Conceitos chave de Distributed Tracing:
Trace: Registro de uma atividade através de um sistema distribuído. Uma árvore ou um Grafo acíclico dirigido de spans
Spans: Representam um segmento nomeado e contínuo de processamento em um trace. Tem relações causais ou de Pai-Filho com outros spans.
Spans e traces, fonte: Documentação do Jaeger
Span root: Primeiro span num trace. geralmente tem a duração exata ou aproximada de todo o trace. Na imagem, o span A é o span root.
Context propagation: Base do processo de Tracing. Como o rastro distribuído atravessa mais de um serviço, informações únicas de identificação são necessárias em todos os caminhos que a requisição pode tomar.
Tracer interface: Provê os meios para criar e interagir com spans.
OpenTracing, OpenCensus e, finalmente, OpenTelemetry
Até um passado não tão distante, dois projetos de instrumentação de Distributed Tracing competiam. O OpenCensus começou no Google como uma plataforma de Observability interna com participação da forte da Microsoft que começou a contribuir e ajudar a guiar o avanço do projeto logo após sua abertura para open source no GitHub. Já o OpenTracing, apoiado pela [Cloud Native Computing Foundation (CNCF)],(https://www.cncf.io/) consiste em uma especificação semântica que tem como meta a definição de uma API de tracing padronizada.
Reconhecendo a dificuldade de adoção da tecnologia trazida pela divisão da comunidade e pela falta de um padrão único de implementação, as lideranças dos dois projetos se uniram para criar o OpenTelemetry que entrou oficialmente em beta no dia 30 de março.
O projeto reúne os pontos fortes do OpenCensus e do OpenTracing para prover um conjunto único de APIs específicas de linguagens, SDKs, agentes e outros componentes que podem ser usados para coletar traces distribuídos, métricas e metadados relacionados nas aplicações. Como descrito no post de lançamento, muito da utilidade do OpenTelemetry vem da integração com bibliotecas HTTP e RPC e clientes de armazenamento, permitindo a captura de dados de observação das aplicações com esforço muito reduzido.
O lançamento do beta do OpenTelemetry é um passo importante para a popularização da prática de Distributed Tracing. Novas funcionalidades continuarão sendo adicionadas e agora com colaboradores de bibliotecas se adaptando as APIs do OpenTelemetry e usuários finais integrando OpenTelemetry aos seus serviços, o nível de maturidade da tecnologia só tende a crescer.
Para mais detalhes de como o OpenTelemetry funciona, com um exemplo de implementação, clique aqui.
Top comments (0)