Skip to main content

Open Telemetry Protocol | OTL | Devops

  • Open Telemetry Protocol | OTL | Devops

1. O que é OpenTelemetry​

OpenTelemetry (OTel) é:

  • ✅ Um padrão aberto
  • ✅ Um projeto open-source
  • ✅ Mantido pela CNCF (Cloud Native Computing Foundation)

Ele define como coletar, representar e transportar telemetria de aplicações e infraestrutura de forma padronizada e independente de fornecedor (vendor-neutral).

OpenTelemetry não é um produto nem um backend de observabilidade. Ele é o padrão universal de instrumentação e transporte de telemetria.

2. O problema que o OpenTelemetry resolve​

Antes do OpenTelemetry:

  • Cada ferramenta tinha sua própria API
  • Código ficava acoplado a vendors
  • Trocar de backend exigia refatoração
  • Logs, métricas e traces não se correlacionavam bem

Com OpenTelemetry:

  • Um único padrão
  • Uma única instrumentação
  • Vários backends possíveis
  • Correlação nativa entre sinais

3. Os três sinais do OpenTelemetry​

OpenTelemetry trabalha com três tipos de telemetria, chamados de signals.

3.1 Traces (Tracing distribuído)​

Representam o fluxo de uma requisição através de serviços.

  • Composto por spans
  • Cada span mede tempo, erro, atributos
  • Identificado por traceId e spanId

Usado para:

  • Latência
  • Gargalos
  • Dependências entre serviços

3.2 Metrics (Métricas)​

Valores numéricos ao longo do tempo.

Exemplos:

  • Requests por segundo
  • Latência p95/p99
  • CPU, memória, GC
  • Filas, erros, throughput

Usado para:

  • Dashboards
  • Alertas
  • SLO / SLA

3.3 Logs​

Eventos estruturados.

  • Mensagens
  • Exceções
  • Contexto
  • Correlacionáveis com traces

Logs modernos com OpenTelemetry:

  • carregam traceId
  • carregam spanId
  • permitem navegação log → trace

4. OTLP – OpenTelemetry Protocol​

OTLP é o protocolo padrão do OpenTelemetry para transportar telemetria.

Ele transporta:

  • Traces
  • Metrics
  • Logs

Protocolos suportados:

  • gRPC (mais eficiente, recomendado)
  • HTTP/Protobuf

Endpoints padrão:

/v1/traces
/v1/metrics
/v1/logs

Alguns backends adicionam prefixos próprios (ex: /ingest/otlp/...), mas o modelo de dados continua sendo OTLP.

5. Componentes do ecossistema OpenTelemetry​

5.1 APIs​

Definem interfaces para criar spans, métricas e logs.

  • Sem dependência de implementação
  • Baixo acoplamento

5.2 SDKs​

Implementam as APIs.

Responsáveis por:

  • Criar spans/métricas/logs
  • Gerenciar contexto
  • Exportar dados

Disponíveis para:

  • .NET
  • Java
  • JavaScript
  • Python
  • Go
  • Ruby
  • PHP
  • Rust
  • C++

5.3 Instrumentação​

Automática​

Bibliotecas prontas para:

  • ASP.NET Core
  • HttpClient
  • gRPC
  • SQL
  • Messaging (Kafka, RabbitMQ via libs)

Manual​

Uso direto de:

  • Activity / ActivitySource (.NET)
  • métricas customizadas
  • spans de negócio

6. OpenTelemetry Collector​

O OpenTelemetry Collector é um serviço standalone, open-source, que atua como hub central de observabilidade.

Ele:

  • recebe telemetria
  • processa
  • exporta para um ou mais destinos

6.1 Por que o Collector existe​

Sem Collector:

App → Prometheus
App → Jaeger
App → Seq

Com Collector:

App → Collector → Backends

6.2 Componentes do Collector​

Receivers (entrada)​

Recebem dados.

Exemplos:

  • otlp
  • jaeger
  • zipkin
  • prometheus (scrape)

Processors (processamento)​

Executam lógica no meio do pipeline.

Principais:

  • batch (agrupamento)
  • memory_limiter
  • attributes
  • filter
  • sampling
  • tail_sampling

Exporters (saída)​

Enviam dados para backends.

Exemplos:

  • otlp
  • prometheus
  • jaeger
  • zipkin
  • elastic
  • datadog
  • loki
  • splunk

Pipelines​

Composição:

receiver → processor → exporter

7. Escala e alta carga​

O Collector lida com escala através de:

  • batching
  • retry com backoff
  • backpressure
  • sampling
  • fan-out
  • load balancing
  • escalabilidade horizontal
  • arquitetura agent + gateway

Isso protege:

  • a aplicação
  • os backends
  • os custos

8. Como cada backend consome OpenTelemetry​

8.1 Métricas – Prometheus​

  • Modelo pull
  • Prometheus faz scrape
  • Collector expõe /metrics
Prometheus → Collector (/metrics)

8.2 Traces – Push​

Collector envia para:

  • Tempo
  • Jaeger
  • Datadog
  • New Relic
  • Elastic
Collector → Backend

8.3 Logs – Push​

Collector ou app envia logs OTLP para backend de logs.

9. Backends conhecidos compatíveis com OpenTelemetry​

9.1 Traces​

  • Grafana Tempo
  • Jaeger
  • Zipkin
  • Datadog APM
  • New Relic
  • Elastic APM
  • Lightstep
  • Honeycomb
  • AWS X-Ray (via tradução)

9.2 Métricas​

  • Prometheus
  • Grafana Mimir
  • Datadog
  • New Relic
  • Elastic
  • Azure Monitor
  • Google Cloud Monitoring
  • AWS CloudWatch

9.3 Logs​

  • Grafana Loki
  • Elastic
  • Splunk
  • Seq
  • Datadog
  • New Relic
  • OpenSearch

10. Arquitetura recomendada (padrão)​

Aplicações
   |
   | OTLP
   v
OpenTelemetry Collector
   |
   +--> Prometheus (metrics)
   +--> Tempo / Jaeger (traces)
   +--> Seq / Loki (logs)
   |
Grafana (visualização)

11. Docker-Compose (Collector + Prometheus + Tempo + Grafana + Seq)​

(Resumo — mesma estrutura discutida anteriormente)

  • Collector recebe OTLP
  • Prometheus faz scrape
  • Tempo recebe traces
  • Grafana visualiza
  • Seq recebe logs

(Configuração completa permanece válida e pode ser reutilizada)

12. Exemplo .NET – conceitos-chave​

ASP.NET Core​

  • Instrumentação automática
  • Exportação OTLP → Collector

Desktop / Console​

  • Spans manuais
  • Métricas de runtime
  • Exportação OTLP → Collector

Logs​

  • Logs estruturados
  • TraceId nos logs
  • Envio OTLP (direto ou via Collector)

13. O que OpenTelemetry não é​

  • ❌ Não é um backend
  • ❌ Não é um APM visual
  • ❌ Não substitui Grafana, Prometheus ou Seq

Ele padroniza e conecta tudo isso.

14. Resumo final​

OpenTelemetry é um padrão open-source de observabilidade que define como coletar, transportar e correlacionar traces, métricas e logs, permitindo que aplicações permaneçam desacopladas dos backends e escalem observabilidade de forma profissional.