Pular para o conteúdo principal

Instrumentação vs Coleta

A instrumentação é o processo de gerar os dados de telemetria no seu código. É como "instalar sensores" na sua aplicação que vão criar os traces, métricas e logs.

Existem dois tipos principais de instrumentação:

  • Automática: Usando bibliotecas que já instrumentam automaticamente frameworks e bibliotecas comuns. O OTel vem crescendo e ganhando essa automatação para as linguagens gradativamente. Hoje só temos disponíveis para as linguagens: .NET, Go, Java, JavaScript, PHP, Python. Veja https://opentelemetry.io/pt/docs/getting-started/ops/ caso queira iniciar rápido se a linguagem do seu projeto já está automatizada.

  • Manual: Quando você adiciona código específico para gerar telemetria em partes importantes da sua aplicação. Nesse caso temos várias bibliotecas disponíveis para várias linguagens. Consulte https://opentelemetry.io/pt/docs/getting-started/dev/ para mais informações.

A coleta é o processo de capturar esses dados gerados e enviá-los para um destino. É realizada pelo OpenTelemetry Collector que receberá dados de telemetria das aplicações instrumentadas, processa esses dados (pode filtrar, transformar, agregar) e exporta para sistemas de observabilidade (como Jaeger, Prometheus, etc).

O Collector funciona como um intermediário central (um Hub) que recebe dados de múltiplas fontes, padroniza o formato e encaminha para um ou mais destinos

A Instrumentação GERA os dados (é onde os dados nascem) e a Coleta PROCESSA e ENCAMINHA esses dados (é como os dados viajam).

O Collector é um componente separado da aplicação. Pode ser um binário independente, um container que funciona como um sidecar, um service no sistema operacional, etc. O Collector foi projetado para ser um componente independente e funcionar como um serviço centralizado que pode receber dados de múltiplas aplicações no mesmo SO.

Se você precisa de algo mais leve e integrado à aplicação, o OTel oferece o conceito de "exporter" que pode enviar dados diretamente para seu sistema de observabilidade. O Exporter não é tão poderoso quanto o collector e é muito mais limitado. O ideal é sempre apontar para um collector, mas em alguns casos específicos de arquitetura o uso do exporter pode fazer sentido.

Collector como Sidecar vs Collector Centralizado​

É bom explicar isso pois provavelmente você deve estar pensando que deve ter uma collector enorme esperando todo mundo mandar para ele os sinais.

Sidecar Pattern​

Usamos essa arquitetura quando precisamos de alta performance, segurança estrita, cada aplicação tem necessidades específicas de processamento e os recursos do cluster não são uma limitação.

Pod
├── Container da Aplicação
└── Container do Collector (sidecar)

Vantagens do Sidecar

  • Isolamento
    • Cada aplicação tem seu próprio collector
    • Falhas não afetam outras aplicações
    • Mais fácil de debugar problemas
  • Performance
    • Comunicação local (dentro do mesmo pod)
    • Menor latência
    • Menos tráfego de rede
  • Segurança
    • Dados não trafegam pela rede antes de serem processados
    • Mais fácil de controlar acesso

Collector Centralizado​

Partimos para essa arquitetura quando precisamos:

  • Economizar recursos
  • Aplicações similares
  • Configuração padronizada
  • Simplicidade de manutenção e atualização
Cluster Kubernetes
├── Pod Crítico (com sidecar)
├── Pod Normal (sem sidecar)
└── Collector Central

As mudanças afetam todas as aplicações de uma vez.

Nada impede de utilizarmos as duas coisas e formar um híbrido. Um collector por node? Por namespace? Não existe um certo e errado, depende de muitos fatores. Mas se eu pudesse te dar uma dica, sidecar não tem erro!