O que é OpenTelemetry? Distributed Tracing - Observability numa arquitetura de micro serviços
Tags: opentelemetry, opentracing, microservices, distributedsystems
Published: 2020-05-18 03:32:20

[O Princípio de responsabilidade única](https://en.wikipedia.org/wiki/Single-responsibility_principle), 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.

{% twitter 651897353889259520 %}

### 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](https://pt.wikipedia.org/wiki/Grafos_ac%C3%ADclicos_dirigidos) 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 no jaeger](https://www.jaegertracing.io/img/spans-traces.png)
 <figcaption id="fig1">
Spans e traces, fonte: [Documentação do Jaeger](https://www.jaegertracing.io/docs/1.17/architecture/)
</figcaption>

**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.

![opentelemetry](https://opentelemetry.io/img/logos/opentelemetry-horizontal-color.png)
### 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](https://github.com/census-instrumentation). Já o **OpenTracing**, apoiado pela [Cloud Native Computing Foundation (CNCF)],(https://www.cncf.io/) consiste em uma [especificação semântica](https://opentracing.io/specification/) 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](https://www.cncf.io/blog/2019/05/21/a-brief-history-of-opentelemetry-so-far/) para criar o OpenTelemetry que entrou oficialmente em beta [no dia 30 de março.](https://medium.com/opentelemetry/opentelemetry-is-officially-in-beta-352fa859db10)

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](https://dev.to/rafaelvitor/distributed-tracing-com-plugins-do-opentelemetry-node-e-jaeger-56pl-temp-slug-6297147?preview=fc08e16d7af87180fc480b87758ce1f45a49374a769e1b30595e1d24b90d544db087e66577d3658fb5a89e3e327828739e379fe5bd5f0b181f4c9073).