Налаштування OpenTelemetry для збору метрик, логів та трейсів

Ми стикаємося з ситуаціями, коли розподілена система перетворюється на чорну скриньку: падає один мікросервіс, а причина — в іншому, але трасування обірване, логи розрізнені, метрики не пов'язані. OpenTelemetry (OTel) вирішує цю проблему, надаючи єдиний vendor-neutral стандарт інструментування. Наш досвід — 5+ років на ринку, понад 100 успішних впроваджень OTel — показує, що кореляція трейсів, метрик та логів знижує середній час відновлення (MTTR) на 40–60% (середній час розслідування зменшується з 2 годин до 30 хвилин).

Правильне налаштування 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. Нічого писати в коді не потрібно. Auto-instrumentation в 10 разів швидше ручного кодування для поширених фреймворків.

Для 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% (до $10,000 на рік). Ми гарантуємо якість: наші сертифіковані OTel експерти з 5+ років досвіду забезпечать безшовну інтеграцію. Зв'яжіться з нами для оцінки вашої системи — ми проаналізуємо архітектуру та запропонуємо оптимальну схему впровадження OpenTelemetry. Замовте аудит або отримайте консультацію вже сьогодні.