Observability (наблюдаемость) — способность понимать состояние системы через данные: метрики, логи, трейсы и профили. Это основа для поиска причин сбоев, оценки производительности и быстрой реакции на инциденты.

Метрики и мониторинг

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

• RPS (requests per second) — запросы в секунду.
• TPS (transactions per second) — транзакции в секунду (одна транзакция может включать несколько запросов).
• Latency / Response Time — время ответа (часто смотрят перцентили, например p95).
• Error Rate — доля ошибочных ответов (например, 5xx).
• Системные метрики: CPU, RAM, диск, сеть, размеры очередей, uptime.

Метрики не смотрят вручную 24/7 — настраивают алерты при превышении порогов (например, memory_usage > 80% или error_rate > 5%). Уведомления уходят в Slack/Telegram, команда начинает разбор.

Инструменты: Prometheus (сбор и хранение временных рядов), Grafana (дашборды).

Трейсинг

Трейсинг — отслеживание пути запроса через распределённую систему (много микросервисов). Каждому запросу присваивается trace_id; каждый сервис создаёт «спаны» (операции с временем и trace_id). Спаны собираются в централизованной системе и собираются в один трейс — цепочку операций по всем сервисам. Видно, где возникла задержка или ошибка.

Без трейсинга при проблеме пришлось бы смотреть логи на каждом сервере; с трейсингом — один граф запроса. Контекст (trace_id) пробрасывается через HTTP-заголовки; библиотеки (например, OpenTelemetry) создают спаны автоматически.

Инструменты: Jaeger, Zipkin, OpenTelemetry.

Логирование

Логи — запись событий приложения в файлы или централизованное хранилище. При сбое по логам восстанавливают последовательность событий (например, «Failed to assign driver for ride_001»).

Проблемы классического подхода: логи только на каждой машине — нужен SSH и grep по серверам; в продакшене доступ часто ограничен. Современный подход — демон (Fluentd, Filebeat) собирает логи и отправляет в централизованную систему; поиск и агрегация через веб-интерфейс (например, по ride_id или «все ошибки за 24 часа»).

Инструменты: ELK Stack (Elasticsearch, Logstash, Kibana), Graylog.

Профилирование

Профилирование — сбор данных о производительности (CPU, память, время выполнения функций). Сервис периодически снимает профили и отправляет их в систему. При инциденте (например, рост памяти в 2:00) смотрят профиль за 1:55 и находят причину (утечка в определённой функции). Сравнение профилей до и после релиза выявляет регрессии.

Инструменты: Pyroscope, Parca.

Обработка ошибок (Sentry-подобные системы)

При ошибке или панике приложение отправляет стек и контекст в централизованную систему (Sentry, Kabrio). Ошибки агрегируются по типу и сервису; не нужно искать их по логам или core dump на каждом хосте. В коде используется SDK (например, sentry.CaptureException(err)).

Зачем это при проектировании

Без observability запуск сервиса — как вождение без приборной панели. На этапе проектирования закладывают: какие метрики собирать (RPS, latency, ошибки), как настроить трейсинг между сервисами, куда отправлять логи и как их искать, как профилировать и куда слать ошибки. Это основа для прозрачности и управляемости системы в проде.