Настройка OpenTelemetry для сбора метрик, логов и трейсов

Мы сталкиваемся с ситуациями, когда распределённая система превращается в чёрный ящик: падает один микросервис, а причина — в другом, но трассировка оборвана, логи разрознены, метрики не связаны. OpenTelemetry (OTel) решает эту проблему, предоставляя единый vendor-neutral стандарт инструментирования. Наш опыт — 10+ лет в наблюдаемости и более 100 внедрений OTel — показывает, что корреляция трейсов, метрик и логов снижает среднее время восстановления (MTTR) на 40–60%.

Правильная настройка OpenTelemetry требует не только установки SDK, но и продуманной архитектуры сбора, обработки и экспорта данных. Мы предлагаем внедрение под ключ: от инвентаризации сервисов до настройки дашбордов в Grafana. Закажите аудит вашей системы — мы оценим сложность и подготовим план.

Почему корреляция трейсов и логов критична?

Трейсы — это последовательность spans, описывающая путь запроса через систему. Каждый span содержит trace_id, span_id, parent_span_id, duration, атрибуты и события. Метрики — числовые измерения со временем: Counter, UpDownCounter, Histogram, Gauge. OTel Metrics API — не замена Prometheus, а дополнение: из spans автоматически генерируются метрики через SpanMetrics Connector в OTel Collector. Логи — структурированные события. OTel определяет формат лог-записи с полями trace_id и span_id, что делает корреляцию логов с трейсами тривиальной.

Главное: когда trace_id пробрасывается из трейса в логи, вы получаете переход «из графика Grafana → в конкретный span → в логи этого span» одним кликом. Без этой корреляции observability остаётся набором разрозненных инструментов.

Как внедрение OpenTelemetry снижает MTTR?

Благодаря сквозной корреляции вы видите полную картину: какая операция вызвала ошибку, какие метрики изменились, какие логи связаны. Время поиска первопричины сокращается в среднем на 50%. Например, при падении сервиса вы сразу открываете трассировку, видите span с ошибкой и переходите в логи — всё за минуту, а не часы.

SDK: инициализация правильно с первого раза

Самая распространённая ошибка — инициализировать SDK внутри request handler. TracerProvider и MeterProvider должны быть синглтонами, создающимися один раз при старте приложения.

Python пример с полной инициализацией трёх сигналов:

from opentelemetry import trace, metrics
from opentelemetry.sdk.trace import TracerProvider
from opentelemetry.sdk.trace.export import BatchSpanProcessor
from opentelemetry.sdk.metrics import MeterProvider
from opentelemetry.sdk.metrics.export import PeriodicExportingMetricReader
from opentelemetry.exporter.otlp.proto.grpc.trace_exporter import OTLPSpanExporter
from opentelemetry.exporter.otlp.proto.grpc.metric_exporter import OTLPMetricExporter
from opentelemetry.sdk.resources import Resource, SERVICE_NAME

resource = Resource.create({SERVICE_NAME: "product-service", "deployment.environment": "production"})

# Traces
trace_exporter = OTLPSpanExporter(endpoint="http://otel-collector:4317", insecure=True)
tracer_provider = TracerProvider(resource=resource)
tracer_provider.add_span_processor(BatchSpanProcessor(trace_exporter))
trace.set_tracer_provider(tracer_provider)

# Metrics
metric_exporter = OTLPMetricExporter(endpoint="http://otel-collector:4317", insecure=True)
metric_reader = PeriodicExportingMetricReader(metric_exporter, export_interval_millis=30000)
meter_provider = MeterProvider(resource=resource, metric_readers=[metric_reader])
metrics.set_meter_provider(meter_provider)

BatchSpanProcessor обязателен в production — SimpleSpanProcessor блокирует вызывающий поток на время экспорта.

Auto-instrumentation: что работает из коробки

OTel предоставляет auto-instrumentation для популярных библиотек — patches, которые автоматически создают spans для HTTP-запросов, SQL, gRPC, redis, kafka. Ничего писать в коде не нужно.

Для Python: opentelemetry-instrument python app.py — запускает приложение с автоматическим инструментированием всех поддерживаемых библиотек.

Для Java: -javaagent:opentelemetry-javaagent.jar + переменные окружения:

OTEL_SERVICE_NAME=product-service \
OTEL_EXPORTER_OTLP_ENDPOINT=http://otel-collector:4317 \
OTEL_LOGS_EXPORTER=otlp \
java -javaagent:opentelemetry-javaagent.jar -jar app.jar

Java-агент инструментирует Spring MVC, Hibernate, JDBC, Kafka, Redis, HTTP-клиенты — автоматически. Для Spring Boot 3.x нужен агент версии 2.x (новая мажорная версия со сломанной обратной совместимостью конфигов).

receivers:
  otlp:
    protocols:
      grpc:
        endpoint: 0.0.0.0:4317
processors:
  batch:
    timeout: 10s
    send_batch_size: 100
exporters:
  otlp:
    endpoint: "tempo:4317"
    tls:
      insecure: true
service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [batch]
      exporters: [otlp]
    metrics:
      receivers: [otlp]
      processors: [batch]
      exporters: [otlp]
    logs:
      receivers: [otlp]
      processors: [batch]
      exporters: [otlp]

Что даёт использование Semantic Conventions?

OTel определяет стандартные имена атрибутов — Semantic Conventions. Их соблюдение критически важно, потому что Grafana, Datadog и другие бэкенды ищут именно эти атрибуты для автоматических дашбордов.

Несколько обязательных:

http.request.method (не http.method — устаревшее)
http.response.status_code
url.full
db.system (postgresql, redis, mongodb)
db.statement (осторожно: не логировать sensitive данные)
messaging.system (kafka, rabbitmq)
messaging.destination.name

Как избежать разрыва trace между сервисами?

Для работы distributed tracing trace_id должен передаваться через все сервисы. OTel использует W3C Trace Context (заголовок traceparent) как дефолтный формат. Для совместимости с Zipkin или Jaeger-форматами добавляется дополнительный propagator.

from opentelemetry.propagate import set_global_textmap
from opentelemetry.propagators.composite import CompositePropagator
from opentelemetry.propagators.b3 import B3MultiFormat
from opentelemetry.propagators.jaeger import JaegerPropagator

set_global_textmap(CompositePropagator([
    TraceContextTextMapPropagator(),  # W3C
    B3MultiFormat(),  # Zipkin legacy
]))

Проблема, которая съедает много времени: один из сервисов не пробрасывает заголовки при исходящих HTTP-запросах — трейс обрывается. Симптом: span без parent, хотя сервис явно вызывается из другого. Диагностируется через OTel Collector с debug exporter.

Процесс внедрения

1. Инвентаризация — языки, фреймворки, внешние зависимости (БД, очереди, кеш)
2. OTel Collector — деплой и настройка пайплайнов экспорта
3. Auto-instrumentation — подключение агентов/патчей для каждого языка
4. Семантические атрибуты — аудит и исправление нестандартных имён
5. Context propagation — проверка сквозного trace через все сервисы
6. Корреляция логов — настройка injection trace_id в лог-форматтеры
7. Бэкенды — настройка экспорта в Jaeger/Tempo + Prometheus

Что входит в работу

• Инвентаризация сервисов и зависимостей
• Развёртывание OTel Collector с кастомными пайплайнами
• Подключение auto-instrumentation для всех языков
• Настройка context propagation и корреляции логов
• Создание дашбордов и алертов в Grafana
• Документация по инцидентам и runbook

OTel внедряется в 2-3 раза быстрее по сравнению с vendor-специфичными решениями благодаря auto-instrumentation и единому конфигу. Экономия на лицензионных отчислениях может достигать 70%. Свяжитесь с нами для оценки вашей системы — мы проанализируем архитектуру и предложим оптимальную схему внедрения OpenTelemetry. Закажите аудит или получите консультацию уже сегодня.