Pular para o conteúdo principal

Dúvidas Comuns

Quero fazer um paralelo aproveitando um pouco mais do OTel e esclarecer algumas dúvidas.

Falando em métricas, sem logs e nem traces

Quando temos um cluster kubernetes, um servidor e infra de hardware em geral é normal querer monitorar e ter um painel bonito no Grafana para monitorar a saúde do cluster e dos servidores. Para isso usamos o Node Exporter que é uma ferramenta mais focada e específica, desenvolvida especialmente para exportar métricas do sistema operacional Linux/Unix para o Prometheus. Ele coleta:

  • Métricas do sistema: CPU, memória, disco, rede
  • Métricas do kernel: interrupções, contextos
  • Métricas de hardware: temperatura, energia
  • Outras métricas específicas do sistema operacional

Mas não é a ferramenta indicada para monitorar uma aplicação.

Poderíamos fazer isso com o OpenTelemetry? Sim, mas o Node Exporter é mais recomendado para monitoramento do cluster por algumas razões:

  • Eficiência: É mais leve e específico para esta função e foi otimizado para coletar métricas do sistema com menor sobrecarga nos nodes.
  • Simplicidade: É mais simples de configurar e manter e não requer instrumentação ou código adicional.
  • Integração: É uma ferramenta com integração nativa com Prometheus
  • Cobertura de métricas: Node Exporter tem métricas predefinidas que cobrem praticamente tudo que você precisa monitorar no nível de sistema.

O ideal é usar ambos de forma complementar:

Node Exporter: para métricas do cluster e dos servidores (CPU, memória, disco, etc)

OpenTelemetry: Para métricas das aplicações, traces e logs

Existe o OpenTelemetry Collector que pode coletar métricas do sistema operacional usando o receptor "hostmetrics". Porém, há algumas considerações importantes:

  • receptor hostmetrics do OpenTelemetry coleta métricas similares ao Node Exporter (CPU, memória, disco, rede, etc), mas precisa ser configurado explicitamente.

    • receivers:
        hostmetrics:
          collection_interval: 30s
          scrapers:
            cpu:
            memory:
            disk:
            filesystem:
            network:
            load:
            process:

No entanto, a maioria das pessoas ainda preferem o Node Exporter mesmo que tenham um collector por node no cluster porque:

  • É mais maduro e testado em produção.
  • Tem uma comunidade maior e mais dashboards prontos no Grafana.
  • É mais leve e específico para esta função.
  • Integra nativamente com o ecossistema Prometheus.

Se você quiser experimentar, pode usar o OpenTelemetry Collector com hostmetrics, mas saiba que:

  • Terá que fazer mais configurações.
  • Pode ter menos métricas disponíveis comparado ao Node Exporter.
  • Encontrará menos recursos e exemplos na comunidade.

Agora falando de aplicações e não do sistema operacional, o OpenTelemetry também coleta métricas, além de logs e traces.

O mesmo Prometheus (que só serve para métricas) pode buscar tanto as métricas do Node Exporter quanto do OpenTelemetry. Lembrando que o Prometheus é um banco de dados de séries temporais e não tem nada a ver com logs e traces.

Prometheus:

  • Prometheus faz SCRAPE (raspagem) das métricas através de endpoints /metrics.
  • Ele puxa (pull) as métricas, não recebe (push)
  • Tanto Node Exporter quanto OpenTelemetry expõem endpoints que o Prometheus scrapa.
Node Exporter expõe /metrics ←-- Prometheus faz scrape
                                      ↓
OpenTelemetry expõe /metrics ←-- Prometheus faz scrape

OpenTelemetry encaminha os diferentes tipos de dados (sinais) para os lugares corretos.

O OpenTelemetry Collector é a peça chave que lida com o roteamento dos dados:

Para métricas no Prometheus:

  • O Collector expõe um endpoint /metrics no formato Prometheus
  • O Prometheus faz scrape deste endpoint
  • O Collector converte os dados do formato OpenTelemetry para o formato Prometheus.

Para logs no Loki por exemplo:

  • O Collector envia (push) ativamente os logs para o Loki
  • Usa o protocolo do Loki para envio de logs
  • Pode fazer transformações e filtros nos logs antes de enviar

Para traces no Jaeger ou GrafanaTempo:

  • O Collector envia (push) os traces via gRPC ou HTTP
  • Suporta diferentes protocolos de traces (OTLP, Jaeger, Zipkin)
  • Pode fazer amostragem e processamento dos traces

Exemplo de configuração do Collector:

receivers:
  otlp:
    protocols:
      grpc:
      http:

processors:
  batch:

exporters:
  prometheus:
    endpoint: "0.0.0.0:8889"
  loki:
    endpoint: "http://loki:3100/loki/api/v1/push"
  jaeger:
    endpoint: "jaeger:14250"

service:
  pipelines:
    metrics:
      receivers: [otlp]
      processors: [batch]
      exporters: [prometheus]
    logs:
      receivers: [otlp]
      processors: [batch]
      exporters: [loki]
    traces:
      receivers: [otlp]
      processors: [batch]
      exporters: [jaeger]

Sua aplicação envia todos os dados (métricas, logs, traces) para o Collector usando o protocolo OTLP, e o Collector se encarrega de distribuir para os serviços corretos usando os protocolos apropriados.

Se você está usando o OpenTelemetry Exporter diretamente na aplicação sem o Collector, você precisa configurar cada exporter separadamente na sua aplicação:

Para métricas no Prometheus você precisa configurar o PrometheusExporter na aplicação que vai expor um endpoint /metrics para o Prometheus fazer scrape.

Para logs no Loki precisa configurar um LokiExporter que vai fazer push direto para o Loki (Precisa configurar a URL e autenticação do Loki)

Para traces no Jaeger tem que configura o JaegerExporter que envia traces diretamente para o Jaeger sendo necessário apontar o endpoint do Jaeger.

Só uma ilustração aqui em python de como seria uma configuração rápida.

from opentelemetry.exporter.prometheus import PrometheusMetricReader
from opentelemetry.sdk.metrics import MeterProvider
from opentelemetry.exporter.jaeger.thrift import JaegerExporter
from opentelemetry.sdk.trace import TracerProvider

# Configurando métricas para Prometheus
metric_reader = PrometheusMetricReader()
provider = MeterProvider(metric_readers=[metric_reader])

# Configurando traces para Jaeger
jaeger_exporter = JaegerExporter(
    agent_host_name="localhost",
    agent_port=6831,
)
trace_provider = TracerProvider()
trace_provider.add_span_processor(jaeger_exporter)

A principal desvantagem de não usar o Collector é precisar configurar cada exporter na aplicação trazendo mais complexidade no código, menos flexibilidade de mudanças nesses serviços e mais conexões diretas entre as aplicações e os diferentes serviços de backend dessas outras tools.

Por isso o Collector é recomendado em ambientes de produção, pois centraliza essa complexidade.