Почему ваши логи бесполезны без трейсов

Представьте: 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 минут после деплоя.