Gymterview
junior

Что такое Observability и чем она отличается от мониторинга?

Observability (наблюдаемость) — свойство системы, позволяющее понять её внутреннее состояние по внешним выходным данным. В отличие от мониторинга, который отвечает на заранее известные вопросы (“работает ли сервис?”, “какова загрузка CPU?”), Observability позволяет исследовать неизвестные заранее проблемы (“почему запросы из конкретного региона стали медленнее?”).

Аналогия из жизни: мониторинг — это приборная панель автомобиля (температура, скорость, уровень топлива). Observability — это возможность подключить диагностический сканер и понять, почему двигатель стучит, даже если на панели все показатели в норме.

Аспект Мониторинг Observability
Подход Реактивный — «что сломалось?» Проактивный — «почему это происходит?»
Вопросы Known-unknowns (известные неизвестные) Unknown-unknowns (неизвестные неизвестные)
Данные Предопределённые метрики и дашборды Произвольные запросы по любым измерениям
Фокус Состояние инфраструктуры Поведение системы глазами пользователя

Три столпа Observability

  1. Метрики (Metrics) — числовые измерения, агрегированные за период времени. Примеры: количество запросов в секунду, время ответа p99, процент ошибок. Метрики дёшевы в хранении и идеальны для алертинга.

  2. Логи (Logs) — дискретные события с текстовым описанием. Содержат контекст: timestamp, уровень, сообщение, stack trace. Дорогие в хранении, но незаменимы для диагностики конкретной проблемы.

  3. Трейсы (Traces) — запись прохождения запроса через все сервисы. Показывают причинно-следственные связи и позволяют найти узкое место в цепочке вызовов.

Пример
┌─────────────────────────────────────────────────────────────┐
│                    Observability                             │
│                                                              │
│   ┌──────────┐    ┌──────────┐    ┌──────────┐              │
│   │ Metrics  │    │   Logs   │    │  Traces  │              │
│   │          │    │          │    │          │              │
│   │ Counter  │    │ JSON     │    │ Span A   │              │
│   │ Gauge    │    │ Struct   │    │  └Span B │              │
│   │ Histogram│    │ Events   │    │   └Span C│              │
│   └──────────┘    └──────────┘    └──────────┘              │
│                                                              │
│   «Что происходит?» «Почему?»    «Где именно?»             │
└─────────────────────────────────────────────────────────────┘

Почему Observability критична для микросервисов

В монолите один запрос обрабатывается внутри одного процесса — достаточно логов и стек-трейса. В микросервисной архитектуре один пользовательский запрос может пройти через 10-20 сервисов, и без Observability невозможно:

  • Понять, какой из сервисов в цепочке тормозит
  • Найти причину каскадных сбоев
  • Оценить влияние деплоя одного сервиса на всю систему

Важное

  • Observability — это свойство системы, а не набор инструментов. Инструменты (Prometheus, Grafana, Jaeger) лишь помогают реализовать это свойство.
  • Мониторинг является подмножеством Observability: хороший мониторинг необходим, но недостаточен.
  • Без структурированных логов, метрик с правильными лейблами и distributed tracing система остаётся «чёрным ящиком».

Частые ошибки

  • Путать инструменты с Observability: установка Grafana не делает систему наблюдаемой, если логи неструктурированные и нет трейсов.
  • Мониторить только инфраструктуру: CPU и RAM важны, но бизнес-метрики (конверсия, время обработки заказа) важнее.
  • Игнорировать корреляцию: метрики, логи и трейсы должны быть связаны через общий traceId/correlationId.
  • Избыточный сбор данных: собирать всё подряд без анализа — дорого и бесполезно. Нужно осознанно выбирать, что мониторить.

Как используется в 2026

  • OpenTelemetry стал де-факто стандартом для инструментирования. Большинство фреймворков (Spring Boot 3.x, Quarkus, Micronaut) имеют встроенную поддержку OTel.
  • Grafana Stack (Mimir + Loki + Tempo) — популярная open-source альтернатива коммерческим APM-решениям.
  • eBPF-based observability (Cilium, Pixie) позволяет собирать метрики и трейсы без изменения кода приложения.
  • AI/ML для анализа: AIOps-инструменты автоматически обнаруживают аномалии и коррелируют события из разных источников.
  • Continuous Profiling (Pyroscope, Grafana Pyroscope) добавляется как четвёртый столп Observability.

На собеседовании: интервьюер ожидает, что вы не просто перечислите три столпа, а покажете понимание разницы между мониторингом и Observability. Частая ошибка — свести ответ к перечислению инструментов (Prometheus, Grafana). Сильный ответ: Observability — это свойство системы, а не набор тулов; мониторинг — подмножество; ключевое отличие — возможность исследовать неизвестные заранее проблемы.

#observability