ФАЗА 55. НАДЁЖНОСТЬ И ЭКСПЛУАТАЦИЯ Наблюдаемость

Логи, метрики и трассировка показывают систему в проде

Logs · Metrics · Tracing

Наблюдаемость связывает события, состояние и путь запроса с контекстом, health-проверки и SLO помогают принимать решения.

1. Лог объясняет конкретное событие

1 / 5

Структурированные поля фиксируют время, операцию, результат и идентификатор, чтобы восстановить причину без догадок по экрану.

  • Контекст полезен.
  • Уровень соответствует смыслу.
  • Секреты исключены.
СобытиеLog fieldsДиагноз

2. Метрика показывает динамику

2 / 5

RPS, ошибки, latency и использование ресурсов позволяют заметить тренд и сравнить периоды, кардинальность ограничена.

  • Метрика имеет вопрос.
  • Перцентиль важен.
  • Деплой отмечается.
ДинамикаRPS и errorsLatencyResources

3. Трассировка связывает путь запроса

3 / 5

Trace и span показывают вызовы сервисов, длительность и место ожидания, контекст передаётся через заголовки.

  • Вызов имеет границы.
  • Пропагация не теряется.
  • Узкое место видно.
Client spanService spansИтоговая latency

4. Health-проверка отвечает на разные вопросы

4 / 5

Liveness показывает нужен ли перезапуск, readiness готов ли экземпляр принимать трафик, зависимость не проверяется тяжело без нужды.

  • Проверка лёгкая.
  • Готовность меняется при остановке.
  • Метрика самой проверки видна.
LivenessReadiness

5. Сигналы вместе приводят к решению

5 / 5

Метрика замечает аномалию, трассировка показывает путь, лог раскрывает факт, SLO определяет срочность и действие.

  • Сигнал связан с пользователем.
  • Диагноз подтверждён.
  • Решение записывается.
АномалияПуть и фактыДействие

Наблюдаемость: логи, метрики, трассировка

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

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

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

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

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

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