Мониторинг микросервисов с OpenTelemetry — метрики, трассировки и логи

В микросервисной архитектуре наблюдаемость становится критически важной. Когда система состоит из десятков сервисов, простые логи уже не дают полной картины — нужно понимать, как запрос проходит через всю систему, где возникают задержки и какие компоненты деградируют.

Для этого используется OpenTelemetry — стандарт и набор инструментов для сбора метрик, трассировок и логов.

Что такое OpenTelemetry

OpenTelemetry — это open-source стандарт для observability, который объединяет:

• метрики (metrics)
• трассировки (traces)
• логи (logs)

Его основная цель — дать единый способ инструментирования приложений независимо от языка и стека.

Поддерживаются практически все популярные языки:

• Go
• Java
• Python
• Node.js
• .NET

Это делает его идеальным выбором для микросервисов, где каждый сервис может быть написан на своём языке.

Три столпа observability

Метрики

Метрики — это числовые показатели во времени.

Примеры:

• количество запросов
• latency
• ошибки
• загрузка CPU

Они дают агрегированное представление о системе.

Трассировки

Трассировки показывают путь конкретного запроса через систему.

Например:

1. API Gateway
2. Auth сервис
3. Backend сервис
4. База данных

Каждый шаг — это span.

В результате можно увидеть:

• где именно возникла задержка
• какой сервис тормозит

Логи

Логи — это детализированные события.

Они помогают:

• понять причину ошибок
• увидеть контекст выполнения

В идеале логи связываются с трассировками через trace_id.

Как работает OpenTelemetry

Общая схема выглядит так:

1. Приложение инструментируется SDK
2. Данные (метрики, трейсы, логи) собираются
3. Отправляются в OpenTelemetry Collector
4. Collector пересылает их в систему хранения

Схема:

Applications → OpenTelemetry SDK → Collector → Storage (Prometheus, Jaeger, Loki и др.)

Collector играет роль промежуточного слоя:

• принимает данные
• агрегирует
• фильтрует
• маршрутизирует

Инструментирование приложений

Пример для Node.js

const { NodeSDK } = require('@opentelemetry/sdk-node');
const { getNodeAutoInstrumentations } = require('@opentelemetry/auto-instrumentations-node');
 
const sdk = new NodeSDK({
  instrumentations: [getNodeAutoInstrumentations()],
});
 
sdk.start();

Это включает автоинструментирование HTTP, базы данных и других библиотек.

Пример для Python

from opentelemetry import trace
from opentelemetry.sdk.trace import TracerProvider
 
trace.set_tracer_provider(TracerProvider())
tracer = trace.get_tracer(__name__)
 
with tracer.start_as_current_span("example-span"):
    print("Hello")

OpenTelemetry Collector

Collector — ключевой компонент.

Он позволяет:

• принимать данные по OTLP
• преобразовывать форматы
• отправлять в разные системы

Пример конфигурации:

receivers:
  otlp:
    protocols:
      grpc:
      http:
 
exporters:
  prometheus:
  jaeger:
 
service:
  pipelines:
    metrics:
      receivers: [otlp]
      exporters: [prometheus]
    traces:
      receivers: [otlp]
      exporters: [jaeger]

Где хранить данные

OpenTelemetry не хранит данные сам — он их только собирает.

Обычно используют:

• Prometheus — метрики
• Jaeger / Tempo — трассировки
• Loki / Elasticsearch — логи

Это позволяет гибко строить observability-стек.

Проблемы, которые решает OpenTelemetry

1. Нет единой картины

Без трассировок сложно понять, где тормозит система.

2. Разные языки и стеки

OpenTelemetry даёт единый стандарт.

3. Сложность отладки

Связка trace + logs позволяет быстро находить причину.

Где здесь место Statuser

OpenTelemetry отлично показывает, что происходит внутри системы:

• где тормозит запрос
• какой сервис падает
• какие метрики деградируют

Но пользователю важно другое — доступен ли сервис снаружи.

Здесь полезно дополнить внутреннюю наблюдаемость внешним мониторингом, например через Statuser:

• проверка доступности API и сайтов
• фиксация деградации
• уведомления при падениях

В результате получается полноценная картина:

• OpenTelemetry — внутренняя диагностика
• внешний мониторинг — пользовательский опыт

Практические советы

1. Используйте автоинструментирование
   • быстрее старт
2. Всегда прокидывайте trace_id
   • связывает логи и трейсы
3. Ограничивайте кардинальность метрик
   • иначе перегрузите хранилище
4. Используйте sampling для трассировок
   • снижает нагрузку
5. Разделяйте среды
   • dev / staging / prod

Итог

OpenTelemetry — это стандарт де-факто для мониторинга микросервисов.

Он позволяет:

• собирать метрики
• отслеживать трассировки
• анализировать логи

И главное — объединять всё это в единую систему наблюдаемости.

В сочетании с внешним мониторингом это даёт полный контроль над системой: от внутренней логики до пользовательского опыта.