Collector OTel: receivers, processors, exporters и паттерны развёртывания

Поступает новое требование от бэкенда: маршрутизировать трассировки в vendor-A, логи — в vendor-B, и редактировать PII из обоих, начиная с понедельника. Без Collector — это три отдельных деплоя приложений в 50 командах. С Collector — одно изменение YAML и один перезапуск Collector.

Receivers, processors, exporters

Collector — это настраиваемый через YAML пайплайн с тремя стадиями:

Receivers принимают входящую телеметрию:

• otlp — gRPC (порт 4317) и HTTP (порт 4318), основной receiver для сервисов с OTel-инструментированием
• filelog — читает лог-файлы из файловой системы (полезен для legacy-приложений, пишущих в stdout/файлы)
• prometheus — скрейпит эндпоинты /metrics (соединяет Prometheus-экспортёры с OTel)
• kafka — читает телеметрию из Kafka-топиков
• Vendor-специфичные receivers для данных не в формате OTel

Processors преобразуют записи на лету:

• memory_limiter — сбрасывает новые записи, когда Collector превышает порог RAM; предотвращает OOM по замыслу
• batch — группирует записи в эффективные батчи (меньше сетевых round trips к экспортёрам)
• resource — добавляет service.name и другие Resource-атрибуты (например, инжектирует deployment.environment=production)
• attributes — редактирует, переименовывает, добавляет поля; используется для удаления PII и соблюдения Semantic Conventions
• tail_sampling — сохраняет/сбрасывает трассировки на основе полного контекста трассировки (ошибки, задержка, бизнес-критерии) — рассматривается в следующем уроке
• transform — универсальные преобразования через OTTL (OpenTelemetry Transformation Language)
• k8sattributes — обогащает спаны/логи метаданными Kubernetes: pod, namespace, node, deployment

Exporters отправляют записи в бэкенды:

• otlp — в другой OTel-совместимый бэкенд (другой Collector, Grafana Tempo, Jaeger и др.)
• datadog — vendor-специфичный
• prometheusremotewrite — в Prometheus или Grafana Mimir
• loki — в Grafana Loki для логов
• Vendor-специфичные экспортёры для New Relic, Honeycomb, Splunk, Elastic и др.

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
      http:
        endpoint: 0.0.0.0:4318

processors:
  memory_limiter:
    check_interval: 1s
    limit_percentage: 80
    spike_limit_percentage: 25
  batch:
    timeout: 10s
    send_batch_size: 512
  attributes:
    actions:
      - key: user.email
        action: delete

exporters:
  otlp/tempo:
    endpoint: tempo:4317
    tls:
      insecure: true

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [memory_limiter, batch, attributes]
      exporters: [otlp/tempo]

Три паттерна развёртывания

Agent — Collector работает как sidecar (один на pod) или DaemonSet (один на node). Принимает телеметрию от локального приложения, выполняет минимальную обработку (обогащение resource, батчинг), экспортирует напрямую в бэкенд. Минимальное количество сетевых хопов, но tail sampling сложно реализовать (каждый агент видит трафик только одной ноды).

Gateway — приложения экспортируют напрямую в центральный пул реплик Collector, который выполняет тяжёлую обработку (tail sampling, редактирование, маршрутизация в несколько бэкендов). Масштабировать обработку централизованно проще, но каждый спан пересекает сеть от приложения до шлюза.

Agent-to-gateway (production-canonical паттерн) — DaemonSet-агент на каждой ноде выполняет минимальную локальную обработку и пересылает через OTLP в централизованный пул шлюзов, который обрабатывает tail sampling, редактирование и маршрутизацию. Агент добавляет Kubernetes-метаданные (pod, namespace, node) через процессор k8sattributes перед пересылкой.

В паттерне agent-to-gateway loadbalancing exporter агента маршрутизирует по хэшу trace_id, гарантируя, что все спаны трассировки попадают на одну реплику шлюза — необходимо для tail sampling, рассматриваемого в следующем уроке.