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

8 минут чтения
Средний рейтинг статьи — 4.9

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

Для этого используется 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 — это стандарт де-факто для мониторинга микросервисов.

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

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

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

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

8 минут чтения
Средний рейтинг статьи — 4.9

Настроить мониторинг за 30 секунд

Надежные оповещения о даунтаймах. Без ложных срабатываний