Наблюдаемость

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

Обычно говорят о трёх столпах:

• Логи — что произошло: строки событий. Структурные (в JSON) и с единым trace_id, чтобы их можно было искать и связывать.
• Метрики — сколько и как быстро: числа во времени (запросов в секунду, задержка, ошибки, использование ресурсов). Дёшевы, агрегируются, по ним строят графики и алерты.
• Трассировка — где именно: путь одного запроса через все сервисы, с таймингом каждого шага. Отвечает на вопрос «на каком из десяти сервисов потерялись 800 мс».

Этот раздел разбирает наблюдаемость по темам:

• Логирование — структурные логи, уровни, что и как писать (и чего в логах быть не должно).
• Метрики — какие снимать (RED/USE), как именовать, не плодя кардинальность.
• Трассировка — distributed tracing, спаны, OpenTelemetry.
• Проброс контекста — как trace_id и контекст переезжают между сервисами через HTTP и брокеры.
• Health-проверки — liveness/readiness, чем они отличаются и зачем нужны оркестратору.
• SLO и алерты — на что заводить алерты, чтобы будили по делу, а не по шуму.
• Конфигурация — как всё это включить и настроить в сервисе.

Статьи есть в вариантах под разные языки и стеки — выберите свой.