# Introdução ao Opentelemetry

OpenTelemetry é uma estrutura (biblioteca) de observabilidade open-source que fornece um conjunto unificado de APIs, SDKs e ferramentas para coletar, processar e exportar dados de telemetria (métricas, logs e traces) de aplicações e serviços.

## Principais características:

Ele não está vinculado a nenhum fornecedor específico, permitindo que você colete dados uma vez e os exporte para diferentes backends de observabilidade como Prometheus, Jaeger, Elasticsearch, Dynatrace, etc.

Ou seja, após a instrumentação da sua aplicação você consegue fazer o envio dos dados para qualquer destino que você queira. Isso é muito útil já que as vezes existem mudanças nos provedores, por exemplo: você instrumentou sua aplicação para usar Datadog mas 2 ou 3 anos depois sua empresa decide mudar de contrato para um NewRelic, isso exigiria um retrabalho já que você vai precisar fazer alguns ajustes para a coleta e envio destes dados. Usando o OpenTelemetry (OTLP) você não teria este retrabalho já que sua aplicação já está instrumentada, basta indicar pra onde o dado precisa ir.

## **Três pilares da observabilidade**:

* **Traces**: Rastreiam o fluxo de requisições através de sistemas distribuídos.
    
* **Metrics**: Coletam medições numéricas sobre performance e comportamento.
    
* **Logs**: Capturam eventos discretos e mensagens de debug.
    

## Instrumentação:

* **Auto-instrumentação**: Oferece instrumentação automática para linguagens populares (Java, Python, .NET, Node.js, Go) sem necessidade de modificar o código da aplicação. Não precisa de mudanças no código.
    
* **Auto-instrumentação no Kubernetes**: É possivel receber e enviar dados da sua aplicação através do OTLP Operator, você pode ter instrumentação completamente automática apenas com annotations. São 3 modos do Operator: Deployment, Sidecar, Daemonset. Não precisa de mudanças no código.
    
* **Instrumentação manual**: Permite adicionar telemetria customizada específica para sua aplicação.Utilizado OTLP API e OTLP SDK. Precisa de mudanças no código.
    

OBS: também é possivel usar a instrumentação manual ou auto-instrumentação no Kubernetes, basicamente são 3 formas diferentes de conseguir coletar dados da sua aplicação. Fica a seu critério definir qual será a melhor maneira pra você.

## Arquitetura:

Existem vários tipos de arquiteturas possíveis, abaixo está uma delas. Eu digo que existem várias, porque o OTLP pode enviar os dados dependendo do Backend diretamente, sem ter um OTLP Collector fazendo essa intermediação para o recebimento, processamento e envio destes dados.

O Jaeger por exemplo aceita dados OTLP, alguns outros providers de backend não aceitam, então você precisaria utilizar o OTLP Collector pra fazer esse processamento.

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1758808812084/f7a0ad4e-42a0-4d0b-8998-705cf2b42648.png align="center")

A arquitetura utilizando o OTLP Operator no Kubernetes é um pouco diferente também já que o Cluster Kubernetes possui um Server API para o recebimento de algumas chamadas HTTP.  

![](https://cdn.hashnode.com/res/hashnode/image/upload/v1758812893458/dad25a44-8f26-4481-b72f-7db3d8728dc2.png align="center")

O operator consegue fazer essa “mágica” de descobrir as aplicações através dessa configuração do seu Deployment:

```yaml
# Sua aplicação
metadata:
  annotations:
    instrumentation.opentelemetry.io/inject-java: "true"  # 👈 ESTA é a "chave"
```

## Vantagens:

* Padronização da coleta de telemetria
    
* Evita vendor lock-in
    
* Reduz complexidade de instrumentação
    
* Comunidade ativa e suporte da CNCF
    
* Integração nativa com Kubernetes
    

## Próximos Passos:

Vou criar mais 3 tutoriais mostrando como é feito os diferentes tipos de implementação e qual o resultado.