Почему ваши логи бесполезны без трейсов
В микросервисах один запрос может пройти через 5–7 сервисов, и каждый из них пишет отдельные логи. Без общего контекста непонятно, относятся ли строки из api-gateway, order-service и inventory-service к одному запросу, где именно произошёл сбой и между какими сервисами искать проблему.
Трейс — это сквозная запись запроса через систему: каждый span фиксирует действие сервиса, длительность и атрибуты. В примере с checkout сразу видно, что ошибка возникает на AcquireLock в inventory-service после 300 мс, а в примере с GET /api/users/:id задержку в 1240 мс даёт Redis, который отвечал 1,2 секунды из-за cold miss.
Для Node.js предлагается связка OpenTelemetry и Uptrace: SDK подключается до основного кода, auto-instrumentations автоматически покрывают HTTP, Express, PostgreSQL и Redis, а трейсы отправляются через OTLP. Чтобы логи работали вместе с трейсами, в каждую строку добавляют trace_id и span_id; тогда из лога можно открыть полный путь запроса в APM, включая waterfall, Service Map, связанные логи и алерты по error rate и p99 latency.
Коротко
- Обычные логи отвечают на вопрос «что произошло», но без trace_id не показывают, какой запрос связал несколько сервисов.
- Трейс собирает путь одного запроса через сервисы и span'ы, показывая длительность, атрибуты и конкретное место сбоя.
- В примере с Express задержку GET /api/users/:id объясняет Redis: 1228 мс из 1240 мс пришлись на получение настроек пользователя.
- OpenTelemetry для Node.js можно подключить без изменений бизнес-кода: auto-instrumentations покрывают HTTP, Express, PostgreSQL и Redis.
- Uptrace принимает трейсы, метрики и логи по OTLP, показывает waterfall, Service Map, связанные логи и алерты по error rate и p99 latency.
FAQ
Зачем добавлять трейсы, если в системе уже есть подробные логи по каждому сервису и endpoint'у?
Логи фиксируют события внутри отдельных сервисов, но не собирают их в один путь запроса. Трейсы показывают, где именно в цепочке появилась задержка или ошибка.
Как связать строки логов с конкретным трейсом, чтобы не искать проблему вручную по разным сервисам?
В логи добавляют trace_id и span_id текущего span'а. По trace_id можно открыть полный трейс в APM и увидеть все связанные события одного запроса.
Что даёт OpenTelemetry в примере с Node.js, Express, PostgreSQL и Redis без переписывания бизнес-логики?
OpenTelemetry SDK с auto-instrumentations автоматически собирает трейсы по HTTP, Express, PostgreSQL и Redis. Приложение запускается с подключённым tracing.js, а данные отправляются в Uptrace через OTLP.
Читайте также
Динамический ресайзинг изображений (Image Previewer)- Как тимлид заменил десятки вкладок на файловую систему и Claude Code
- От хаоса к системе: как выстроить процесс Discovery (часть 1)
- Как сегментировать базу: основные критерии сортировки контактов
- Альтман в панике: зачем ChatGPT превратили в рекламную помойку и почему это не спасёт OpenAI
- Логи должны связываться с трейсами через trace_id: В распределённой системе лог без общего идентификатора запроса быстро превращается в изолированное событие: видно ошибку, но не видно её место в цепочке. Для production-сервисов нужно добавлять в каждую строку лога trace_id и span_id, чтобы из записи лога можно было открыть полный путь запроса в APM.
[Observability и инциденты]
Зарегистрированные пользователи видят только два тезиса.
Зарегистрироваться
Логи без трейсов плохо помогают при инцидентах: они фиксируют событие, но не показывают, какой запрос и какая цепочка сервисов привели к ошибке. Трейсы связывают вызовы в один маршрут и позволяют быстро увидеть конкретный bottleneck.