Логирование и наблюдаемость
Превратите работающий Node-сервис в то, что вы действительно можете видеть изнутри
- объяснить, почему структурированное (JSON) логирование в продакшене лучше
console.log, и использовать pino для него; - выбирать правильный уровень логирования и настраивать его для каждого окружения;
- прикреплять correlation id к каждой строке лога запроса с помощью
AsyncLocalStorage; - отдавать метрики в формате Prometheus и рассуждать о методе RED;
- описывать, как распределённая трассировка сшивает спаны в один трейс через распространение контекста;
- писать корректные проверки здоровья liveness и readiness.
1. Наблюдаемость против мониторинга: три столпа
Мониторинг говорит вам, здорова ли система относительно известных порогов ("CPU > 90%", "частота ошибок > 1%"). Наблюдаемость шире: это свойство, позволяющее исследовать почему, идя по следу от симптома к корневой причине, которую вы не задавали заранее. Её нельзя добавить задним числом — сервис наблюдаем только если он был инструментирован для излучения полезных сигналов.
Каждый из трёх столпов отвечает на свой вопрос:
- Логи — "что именно произошло в этот момент?" Отдельные события с меткой времени и контекстом. Высокая детализация, большой объём, выше стоимость за байт.
- Метрики — "сколько / как много / как быстро, во времени?" Дешёвые числовые временные ряды (счётчики, gauge, гистограммы), которые хорошо агрегируются и питают дашборды и алерты.
- Трейсы — "каков был сквозной путь этого одного запроса?" Дерево замеренных по времени спанов через сервисы, показывающее, куда на самом деле ушла задержка.
Они дополняют друг друга, а не взаимозаменяемы. Срабатывает алерт по метрике ("p99 задержки оформления заказа подскочил"); трейс показывает, что медленный спан — это вызов базы данных; логи на этом спане раскрывают точный запрос и заблокированную строку. Используйте каждый по назначению.