Эволюция Observability — от версии 1.0 до 3.0

Что такое observability и зачем она нужна?

Observability — это возможность понять, что происходит внутри системы, не заглядывая в код. Представьте: у вас есть приложение. Оно падает. Вы не знаете почему.

Observability даёт три типа «подсказок»:

1. Логи — текстовые сообщения: «Ошибка 404», «Пользователь 123 вошёл».
2. Метрики — цифры: «CPU 85%», «2000 запросов в секунду».
3. Трассировки — цепочка: «запрос прошёл через сервис A → B → C, задержка на B — 2 сек».

Зачем это бизнесу?

• SRE: находит проблему за 5 минут вместо часа.
• Продукт: видит, что 10% пользователей уходят на шаге оплаты.
• Финансы: считает, сколько стоит каждый час простоя.

Наблюдаемость 1.0 — каждый инструмент в отдельной вкладке

Наблюдаемость 1.0 определяется как использование «трёх столпов»: журналов, метрик и трассировок.

Как это выглядело на практике: ошибка → вы открываете три разных сервиса:

Как решали проблему:

1. Kibana → ищем логи по времени.
2. Grafana → смотрим метрики.
3. Jaeger → ищем трассировку.
4. Вручную соединяем: «ага, в 14:32 был пик CPU и ошибка в логе».

Главные проблемы:

• 5+ инструментов для одной ошибки.
• 10–15 минут на переключение между вкладками.
• Данные теряются — не всё индексируется.
• Инструментирование — ручная работа для каждого языка.

Реальный кейс: команда из 10 человек тратила 2 часа в день на корреляцию логов и метрик.

Наблюдаемость 2.0 — «всё в одном месте»

Тезис Observability 2.0 заключается в том, что мы должны отправлять полноценные данные в системы хранения и обработки запросов в виде «широкоструктурированных журналов». Это, по сути, журналы с множеством полей, которые должны быть «самостоятельными» и рассказывать историю о определённой части системы. Теперь можно отслеживать путь пользователя от начала до конца.

Что изменилось:

Появился OpenTelemetry — единый стандарт сбора всех сигналов. Платформы вроде Datadog, Grafana Cloud, Elastic теперь показывают всё в одном дашборде.

Как это работает:

• Один trace ID связывает лог, метрику и трассировку.
• Структурированные логи: {"user_id": 123, "error": "timeout", "latency_ms": 1200}.
• Единый интерфейс: кликаете на ошибку → сразу видите метрику и трассировку.

Плюсы:

• Ошибка → 2 клика → корень проблемы.
• OpenTelemetry SDK — один код для Java, Python, Go.
• Команды видят одно и то же — меньше «я вижу, а ты нет».

Минусы:

• Отправляем всё → счёт за терабайты.
• OpenTelemetry — «просто добавь 10 строк» → на деле неделя на настройку.
• Бизнес не видит ROI: «красиво, но где деньги?»

Реальный кейс: компания с 200 микросервисами перешла на Datadog + OTel.

Результат:

• Время на инцидент: –70% (с 45 мин до 13).
• Затраты на телеметрию: +$Х / год.

Наблюдаемость 3.0 — «умная, дешёвая, бизнесовая»

Главная идея: собираем всё — отправляем только важное (работает как видеорегистратор: пишет всё, но загружает только при аварии)

Новые тренды 3.0

Эволюция в одной таблице