Представьте: production, 3 часа ночи, пользователи жалуются на ошибки. Вы открываете логи и видите:

[ERROR] Request failed: Connection timeout
[ERROR] Request failed: Connection timeout
[ERROR] Request failed: Connection timeout

Что упало? Какой сервис? Какой запрос спровоцировал? Это была одна цепочка вызовов или разные? Логи молчат.

Именно здесь логи без трейсов превращаются в шум.

Что не так с обычными логами

Логи отвечают на вопрос «что произошло», но не отвечают на «почему» и «где именно».

В монолите это ещё терпимо — можно хотя бы grep'нуть по request ID. В микросервисах это катастрофа: запрос проходит через 5–7 сервисов, каждый пишет свои логи, и связать их между собой без общего контекста невозможно.

Типичная картина:

# api-gateway
[INFO] POST /checkout — 502 Bad Gateway (320ms)

# order-service  
[ERROR] Failed to reserve inventory — timeout

# inventory-service
[INFO] Lock acquired on item #4821
[INFO] Lock released

Три сервиса, три лог-файла. Связаны ли эти строки одним запросом? Непонятно. Проблема в inventory или между order и inventory? Непонятно.

Что добавляют трейсы

Трейс — это сквозная запись одного запроса через всю систему. Каждый шаг (span) фиксирует: что делал сервис, сколько времени занял, какие атрибуты передавал.

Та же ситуация с трейсом:

Trace: POST /checkout (320ms) ❌
  └─ api-gateway → order-service (12ms) ✓
       └─ order-service → inventory-service (301ms) ❌
            └─ AcquireLock(item #4821) — TIMEOUT after 300ms ❌

За 10 секунд видно: bottleneck в AcquireLock, конкретный item, конкретный сервис.

Реальный пример: медленный API-эндпоинт

Допустим, есть Express-приложение с эндпоинтом GET /api/users/:id. Пользователи жалуются что он иногда тормозит. Логи говорят только:

[INFO] GET /api/users/42 — 200 OK (1240ms)

1240ms — это много, но почему? Запрос делает несколько вещей: проверяет JWT, достаёт пользователя из PostgreSQL, подгружает его настройки из Redis, формирует ответ.

С трейсом картина сразу другая:

Trace: GET /api/users/42 (1240ms)
  └─ verify JWT (4ms) ✓
  └─ postgres: SELECT users (8ms) ✓
  └─ redis: GET user:settings:42 (1228ms) ❌  ← вот оно

Redis отвечал 1.2 секунды — ключ не был закэширован, пошёл cold miss с дополнительным запросом в БД. Без трейса это можно было искать часами, перебирая гипотезы.

Настройка за 5 минут — Node.js + OpenTelemetry

В примере будем отправлять трейсы в Uptrace — OpenTelemetry-native APM. Можно зарегистрироваться бесплатно или поднять self-hosted версию через Docker. DSN берётся в настройках проекта.

Устанавливаем пакеты:

npm install @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({
  serviceName: 'my-service',
  traceExporter: new OTLPTraceExporter({
    url: 'https://otlp.uptrace.dev/v1/traces',
    headers: { 'uptrace-dsn': process.env.UPTRACE_DSN },
  }),
  instrumentations: [getNodeAutoInstrumentations()],
});

sdk.start();

Запускаем:

node -r ./tracing.js app.js

Всё. getNodeAutoInstrumentations() автоматически инструментирует HTTP, Express, PostgreSQL, Redis — без изменений в бизнес-коде.

Связываем логи с трейсами

Трейсы и логи полезны по отдельности, но вместе они дают полный контекст. Идея простая: добавить в каждую строку лога trace_id и span_id текущего span'а.

const { trace } = require('@opentelemetry/api');

function log(level, message, extra = {}) {
  const span = trace.getActiveSpan();
  const ctx = span ? span.spanContext() : {};
  
  console.log(JSON.stringify({
    level,
    message,
    trace_id: ctx.traceId,
    span_id: ctx.spanId,
    ...extra,
  }));
}

// Использование
log('error', 'Failed to reserve inventory', { item_id: 4821 });

Теперь в логах есть trace_id. По нему в любом APM можно открыть полный трейс и увидеть весь путь запроса.

Uptrace: где всё это удобно смотреть

Трейсы нужно куда-то отправлять. Uptrace — open-source APM, построенный на OpenTelemetry: принимает трейсы, метрики и логи через стандартный OTLP-протокол, ничего лишнего настраивать не нужно.

Именно здесь история с медленным Redis приобретает смысл. Открываешь Trace Explorer, находишь GET /api/users/42 — и видишь waterfall: JWT 4ms, Postgres 8ms, Redis 1228ms. Один экран, без grep'а по логам, без гипотез.

Что ещё даёт из коробки:

• Service Map — автоматическая карта зависимостей, сразу видно какой сервис деградирует

• Связанные логи — клик на любой span показывает логи именно этого запроса, с тем самым trace_id

• Алерты — по error rate и p99 latency, срабатывают до того как пользователи начнут жаловаться

Бесплатный self-hosted вариант разворачивается через Docker за несколько минут.

Итог

Логи фиксируют события внутри одного сервиса — и на этом останавливаются. Трейсы показывают полный путь запроса через всю систему: какой сервис, какой метод, сколько времени, почему упало.

Без трейсов при инциденте в микросервисах вы тратите часы на ручную склейку картины из разрозненных лог-файлов. С трейсами — минуты, потому что вся цепочка уже перед глазами.

OpenTelemetry + Uptrace — это не абстрактная "observability". Это конкретный ответ на вопрос "почему тормозит /api/users/:id" — прямо в браузере, через 5 минут после деплоя.