OpenTelemetry простыми словами: зачем это на одном сервере

MAATRIX

Вы читаете про мониторинг, натыкаетесь на слово OpenTelemetry — и первая мысль: «ещё один стандарт, ещё одна аббревиатура, а у меня всего один сервер и Grafana с парой дашбордов». Мысль честная. Но за скучным словом «стандарт» скрывается конкретная и довольно приземлённая идея, которая экономит вам недели работы в будущем — и вы удивитесь, насколько просто получить от неё пользу уже сегодня, даже если инфраструктура пока маленькая.

Что такое OpenTelemetry простыми словами

OpenTelemetry (сокращённо OTel) — это открытый стандарт и набор библиотек для сбора данных наблюдаемости (observability): метрик, логов и трассировки запросов. Ключевое слово здесь — «стандарт», а не «инструмент». OpenTelemetry сам по себе ничего не хранит и не рисует дашборды — он не конкурент Grafana, Prometheus или Jaeger. Он решает другую задачу: как именно ваш код собирает эти данные, прежде чем отправить их куда-либо для хранения и анализа.

Представьте разницу между розеткой и проводкой в доме. Розетка (стандарт) одна и та же независимо от того, какой чайник, лампу или зарядку вы в неё воткнёте. Если бы у каждого производителя техники была своя уникальная форма вилки, вам бы пришлось перестраивать проводку под каждый новый прибор. OpenTelemetry — это именно про «розетку»: единый способ инструментировать приложение (добавить в код сбор данных), после чего сами данные можно направить в любой совместимый «прибор» — систему анализа и визуализации.

Проект развивается под эгидой Cloud Native Computing Foundation (той же организации, что курирует Kubernetes), объединяет три ранее раздельных проекта (OpenTracing, OpenCensus и часть Jaeger) и на конец августа 2026 года — фактический отраслевой стандарт для новых систем наблюдаемости.

Проблема, которую решает стандарт: не привязываться к одному инструменту

До появления таких стандартов инструментирование кода делалось «под конкретный инструмент». Хотите метрики в Prometheus — добавляете в код библиотеку prometheus_client, размечаете счётчики и гистограммы её API, открываете эндпоинт /metrics именно в её формате. Хотите трассировку в конкретном коммерческом SaaS-сервисе мониторинга — ставите его проприетарный агент и его SDK, с его специфичными вызовами в коде.

Проблема вылезает не сразу, а через год-два, когда: вы вырастаете из бесплатного тарифа коммерческого сервиса и хотите перейти на self-hosted решение; решаете сменить Prometheus на что-то другое; добавляете второй-третий сервис, и метрики с трейсами в них собираются по-разному, потому что писали разные разработчики в разное время; либо инструмент анализа, выбранный три года назад, устарел или подорожал, и миграция означает переписывание всего инструментирования заново.

OpenTelemetry убирает эту привязку. Вы инструментируете код один раз, используя универсальный API и SDK OpenTelemetry, а куда отправлять итоговые данные — решается конфигурацией, а не переписыванием кода. Сменили Prometheus на VictoriaMetrics, Jaeger — на Grafana Tempo, самопальный ELK — на Grafana Loki? Меняете строчку адреса экспортёра в конфиге, а не библиотеки в коде приложения.

Как это устроено технически: SDK, коллектор, экспортёры

Схема OpenTelemetry состоит из трёх слоёв, и важно понимать их отдельно:

1. API и SDK внутри приложения. Библиотека OpenTelemetry для вашего языка (Node.js, Python, Go, Java, .NET, PHP и другие — список поддерживаемых языков большой и растёт) встраивается в код и собирает три типа сигналов:

• Трассировка (traces) — путь одного запроса через систему: пришёл на веб-сервер → пошёл в базу → сходил во внешний API → вернулся с ответом, с таймингами на каждом шаге.
• Метрики (metrics) — числовые показатели во времени: количество запросов в секунду, задержка ответа, размер очереди, использование памяти конкретным процессом.
• Логи (logs) — текстовые события с контекстом, желательно с привязкой к конкретной трассировке (чтобы по логу можно было найти весь путь запроса, который его породил).

2. OpenTelemetry Collector. Это отдельный процесс (можно запустить как Docker-контейнер прямо на вашем VPS), который принимает данные от приложений по протоколу OTLP (OpenTelemetry Protocol) и дальше решает, что с ними делать: агрегировать, фильтровать, обогащать метаданными и отправлять дальше. Коллектор не обязателен — SDK может слать данные напрямую в бэкенд, но на практике коллектор как прослойка сильно упрощает жизнь: приложению достаточно знать один адрес (коллектора), а куда слать данные дальше — настраивается в одном месте, а не в коде каждого сервиса.

Минимальный конфиг коллектора выглядит примерно так:

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

exporters:
  prometheus:
    endpoint: 0.0.0.0:8889
  otlp/jaeger:
    endpoint: jaeger:4317
    tls:
      insecure: true
  loki:
    endpoint: http://loki:3100/loki/api/v1/push

service:
  pipelines:
    metrics:
      receivers: [otlp]
      exporters: [prometheus]
    traces:
      receivers: [otlp]
      exporters: [otlp/jaeger]
    logs:
      receivers: [otlp]
      exporters: [loki]

Обратите внимание: в одном конфиге метрики уезжают в Prometheus, трейсы — в Jaeger, логи — в Loki. Приложению не важно, что стоит на другом конце — оно просто шлёт данные коллектору по одному универсальному протоколу.

3. Бэкенд для анализа. Это уже конечный инструмент, где вы смотрите дашборды и ищете трейсы: Grafana + Prometheus для метрик, Jaeger для трассировки, Grafana Loki для логов, или универсальные платформы вроде SigNoz, которые из коробки принимают все три типа сигналов в формате OpenTelemetry и показывают их в одном интерфейсе. Если вы уже настраивали трассировку запросов через Jaeger, хорошая новость: Jaeger изначально был одним из проектов, влившихся в OpenTelemetry, и умеет принимать данные по протоколу OTLP напрямую.

Зачем это нужно, если у вас один сервер — честный ответ

Вот тот самый естественный вопрос: «У меня один VPS, одно приложение, простенький Prometheus с парой алертов. Зачем мне ещё один стандарт поверх всего этого?» Ответ честный и без продажи воздуха — два конкретных практических довода.

Довод первый: инструментирование не придётся переписывать при росте или смене инструмента. Сегодня у вас один сервер и Prometheus. Через год — три сервера, очередь сообщений между ними, и вы понимаете, что одних метрик мало: нужна трассировка, чтобы понять, на каком из трёх сервисов застревает медленный запрос. Если код изначально писал метрики и логи через клиентские библиотеки, завязанные именно на Prometheus и файловый логгер, добавление трассировки — это отдельная, никак не связанная с существующим кодом работа, и велик риск, что три системы наблюдаемости в проекте будут жить порознь, без общего контекста.

Если же с самого начала вы инструментировали код через OpenTelemetry SDK (даже отправляя только метрики, только в Prometheus), то добавление трассировки в будущем — это в первую очередь смена конфигурации коллектора и, возможно, добавление недостающих span-ов в код, а не переписывание фундамента с нуля. Сам код сбора данных не меняется — меняется только маршрут, куда эти данные текут.

Довод второй: OpenTelemetry уже встроен во многие фреймворки и библиотеки, и часто получить базовое инструментирование проще, чем кажется. Для целого ряда популярных стеков существует «автоинструментирование» (auto-instrumentation) — пакет, который перехватывает вызовы HTTP-клиента, ORM, драйвера базы данных и сам генерирует трейсы и метрики без ручной разметки каждой функции. Например, в Node.js это выглядит примерно так:

npm install @opentelemetry/api @opentelemetry/sdk-node \
  @opentelemetry/auto-instrumentations-node \
  @opentelemetry/exporter-trace-otlp-http

// tracing.js — подключается ДО импорта остального кода приложения
const { NodeSDK } = require('@opentelemetry/sdk-node');
const { getNodeAutoInstrumentations } = require('@opentelemetry/auto-instrumentations-node');
const { OTLPTraceExporter } = require('@opentelemetry/exporter-trace-otlp-http');

const sdk = new NodeSDK({
  traceExporter: new OTLPTraceExporter({ url: 'http://localhost:4318/v1/traces' }),
  instrumentations: [getNodeAutoInstrumentations()],
});

sdk.start();

node -r ./tracing.js app.js

Для Python аналогично есть обёртка opentelemetry-instrument, которая запускает приложение с автоинструментированием вообще без изменения кода (opentelemetry-instrument --traces_exporter otlp python app.py), а для Java и .NET похожий эффект даёт подключение java-агента или пакета автоинструментирования без единой строчки в коде приложения.

Разумеется, автоинструментирование покрывает только типовые вещи (HTTP-запросы, обращения к базе, вызовы популярных библиотек) — специфичную бизнес-логику всё равно придётся размечать вручную через API. Но точка входа получается гораздо ниже, чем «сначала изучите всё API, потом пишите каждый span руками».

Когда OpenTelemetry не нужен, а когда окупается

Здесь стоит быть честным до конца, а не продавать стандарт как универсальное решение для всех.

Не нужен (или избыточен) если: у вас личный pet-проект, один разработчик, один сервер, приложение настолько простое, что вы и так знаете, что в нём происходит; хватает базовых логов и системного мониторинга ресурсов вроде мониторинга из коробки; проект не планирует расти в несколько сервисов и не будет передан другой команде.

В этом случае полноценное инструментирование через OpenTelemetry — это усложнение ради удобства, которое вы реально не почувствуете на таком масштабе. Собирать трейсы для приложения, которое обрабатывает двадцать запросов в день на одном сервере, — трата времени, которое лучше потратить на сам продукт.

Окупается, если:

• проект реально планирует расти — сейчас один сервер, но в планах разнести базу, добавить очередь заданий, вынести отдельный сервис авторизации;
• уже сейчас несколько взаимодействующих компонентов (веб-приложение + очередь + воркер + внешний API), и когда запрос «подвисает», непонятно, на каком из компонентов именно;
• команда больше одного человека, и через полгода эту систему может поддерживать кто-то другой — стандартизированное инструментирование читается предсказуемо, в отличие от самодельных решений каждого разработчика.

Практическое правило: если вы уже задаёте себе вопрос «а что если у нас будет больше одного сервера» — это сигнал, что инвестиция окупится. Внедрить стандартный подход с нуля на маленьком проекте занимает вечер-два. Переделывать задним числом инструментирование трёх продакшн-сервисов под единый стандарт, когда мониторинг уже стал насущной необходимостью, а хаос из трёх разных подходов уже мешает работать — на порядок дороже по времени и по нервам.

Практика: как начать инструментировать проект за вечер

Если решили попробовать на своём VPS, минимальный рабочий стек — это ваше приложение, OpenTelemetry Collector и один бэкенд для проверки (возьмём Jaeger для трейсов, раз он уже разбирался в блоге). Docker Compose файл:

version: "3.8"
services:
  otel-collector:
    image: otel/opentelemetry-collector-contrib:latest
    command: ["--config=/etc/otel-collector-config.yaml"]
    volumes:
      - ./otel-collector-config.yaml:/etc/otel-collector-config.yaml
    ports:
      - "4317:4317"
      - "4318:4318"
    depends_on:
      - jaeger

  jaeger:
    image: jaegertracing/all-in-one:latest
    environment:
      - COLLECTOR_OTLP_ENABLED=true
    ports:
      - "16686:16686"
      - "4317"

Конфиг коллектора (otel-collector-config.yaml) для одного только пайплайна трейсов:

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

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

service:
  pipelines:
    traces:
      receivers: [otlp]
      exporters: [otlp/jaeger]

Дальше запускаете и подключаете приложение из примера выше (или его аналог на своём языке), указывая адрес коллектора http://localhost:4318/v1/traces. Открываете http://ваш-сервер:16686 — интерфейс Jaeger — и видите первые трейсы. Дальше добавляете пайплайн для метрик (экспортёр prometheus) и логов (экспортёр loki или otlphttp в подходящий приёмник), если уже пользуетесь связкой Prometheus и Grafana или Grafana Loki для логов.

Несколько практических нюансов, о которых часто забывают:

• Ресурсы коллектора на маленьком VPS. Добавьте в пайплайн processors: [batch, memory_limiter] — иначе при всплеске трафика коллектор может начать копить данные в памяти быстрее, чем успевает их отправлять.
• Не инструментируйте всё сразу. Начните с одного важного сервиса и одного типа сигнала (обычно трейсы дают больше всего пользы для диагностики «где тормозит»), а не пытайтесь за вечер покрыть всё и сразу.
• Семплирование трейсов. Трассировать каждый запрос без разбора дорого по объёму данных даже на скромной инфраструктуре. SDK поддерживает семплирование (например, 10% запросов либо все запросы с ошибкой) — задайте его сразу.
• Логи в OpenTelemetry менее зрелые. На конец августа 2026 года часть спецификации для логов в некоторых языковых SDK помечена как менее стабильная по сравнению с метриками и трейсами — сверьтесь со статусом для вашего языка перед внедрением.

Частые вопросы