Разница между мониторингом и наблюдаемостью¶

Про наблюдаемость (observability)¶

"Три столпа наблюдаемости" (метрики, логи и трейсы) - это не "наблюдаемость", это просто телеметрия, это сырой материал, просто набор байтов.

Наблюдаемость - это когда в едином хранилище (а не в трех разных, например, в Prometheus/ELK/Jaeger) хранятся высококонтекстные события (события, которые объединяют логи, метрики и трейсы в одном "обогащенном" событии, wide events) с высокой кардинальностью (user_id, trace_id, cart_id …), эти события собираются один раз и используются в дальнейшем много раз (можно на лету строить запросы), и инженер может задать системе любой вопрос, не предусматривая его заранее в дашборде или алерте, вообще на любой вопрос относительно этой системы.

Наблюдаемость - не замена мониторингу, это его дополнение.

Само понятие "наблюдаемость" берет начало из теории систем управления:

В 2016 году команда Honeycomb развернула это определение и переформулировала его в

Ben Sigelman в 2021 г. написал статью "Развенчание мифа о трех столпах наблюдаемости", в которой объяснил, что "метрики, журналы и трассировки — это не наблюдаемость, это просто телеметрия".

В 2025 году вышла статья, в которой было предложено называть относящимися к "Observability 1.0" решения, которые тесно связаны с "тремя столпами наблюдаемости" (логи, метрики и трейсы).

К сожалению, тенденция путать наблюдаемость с телеметрией или мониторингом сохранилась, сколько бы лидеры технологической отрасли ни пытались объяснить, что мониторинг может подсказать вам, когда что-то не так, а наблюдаемость позволяет понять, почему.

Все остальное - маркетинг.

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

{
  "timestamp": 1769529618,
  "service": "payment-api",
  "endpoint": "POST /v2/charge",
  "user_id": "user1",
  "order_id": "order-42be",
  "trace_id": "0x4a6f-b44c",
  "parent_span_id": "0x7e2",
  "status": "error",
  "error_code": "card_declined",
  "duration_ms": 142,
  "cpu_mcores": 27,
  "gc_pause_ms": 3,
  "build_id": "1.2.3-4-g42d9",
  "region": "mos-1a",
  "az": "use1-az1",
  "canary": false,
  "currency": "RUB",
  "amount_rub": 4999,
  "risk_score": 0.87,
  "experiments": ["exp_checkout_v2", "exp_3ds_off"]
}

Всё, что нужно, уже внутри: - Метрики: duration_ms, cpu_mcores, gc_pause_ms - Лог: status=error, error_code=card_declined - Трейс: trace_id, parent_span_id - Бизнес-контекст: user_id, order_id, amount_rub, risk_score - Инфра: region, az, canary, build_id

И всё это лежит в одном хранилище, "одно хранилище" - object storage + колоночный формат, например, CLickHouse. И с этим можно делать, что хочешь, например, корреляцию с бизнес-метриками (revenue impact) - и директор по финансам получает отчёт в рублях, а не "100500 ошибок в минуту".

sql -- сколько денег потеряли из-за card_declined за последний час SELECT sum(amount_rub)/100 AS lost_rub FROM payment_wide WHERE status='error' AND error_code='card_declined' AND timestamp >= now() - INTERVAL 1 HOUR;

Понедельник, 14:00. Звонок от инцидент-менеджера: "Пользователи не могут создать виртуальные машины в новом регионе, иногда процесс зависает на 20 минут вместо обычной минуты". Иногда. Не всегда. В определенной зоне доступности. Не во всех.

Смотрим на дашборды - там "все зеленое". Доступность API 99,9%, загрузка ресурсов кластера в норме, ошибок в логах наших сервисов нет. По нашим метрикам система абсолютно здорова. Но тикеты от клиентов продолжают поступать.

И вот здесь начинается observability. Нужно найти сбой в сложной цепочке зависимостей, не зная, какое именно звено сломано, или, другими словами, нужно найти иголку в стоге сена, не зная, как выглядит иголка.

Открываю трейсинг. Ищу все операции CreateVirtualMachine за последние два часа, которые длились больше 5 минут. Нахожу 8 из 5000. Доля в 0,16% - понятно, что SLO этого не уловили и p^95 это не показывает.

Анализирую эти зависшие трейсы. Во всех есть общий паттерн: они застревают на этапе выделения сетевого интерфейса. Но не всегда! Только когда машина запускается в зоне доступности pd-39, и только при использовании шаблона с определенным типом GPU.

Иду в логи внутреннего API. Фильтрую по correlation_id проблемных операций. Обнаруживаю, что запрос на создание сети возвращает успешный статус 202 Accepted, но коллбэк о завершении операции не приходит. Проблема только в пуле адресов этой конкретной зоны, и проявляется она лишь при запросе определенного типа ресурсов из-за тонкой race condition в системе оркестрации.

Четыре часа расследования. Без телеметрии: распределенной трассировки, связанных логов и метрик и понимания полного контекста запроса я бы эту проблему не нашел. Все наши внутренние метрики были "зелёными", сбой проявлялся в 0,16% случаев, и только при уникальной комбинации: регион + зона + тип ресурса + шаг выделения сети.

"Всё работает" - это НЕ достаточная метрика.

Все эти слова (observability, monitoring и telemetry) для многих, к сожалению, почти одно и то же, но разница между ними, как между таксистом, который знает дорогу до Кремля, и системой навигации.

Мониторинг: это когда мы знаем, что должно сломаться, и ставим датчик на это место. Это пассивный процесс, проверка заранее известных параметров здоровья системы, мы заранее определяем список вопросов, на которые система должна уметь отвечать "да" или "нет". Мониторинг - это всего дишь процесс, который по заранее заданным правилам сообщает нам когда и что сломалось. Уже сломалось.

Представь, что наш продукт - это хомяк в клетке¶

Мониторинг - это когда мы повесили на клетку датчики¶

Мы смотрим на экран и видим красивые циферки (это наши SLIs, кстати):

• Датчик бега в колесе: 100 оборотов в минуту.
• Датчик температуры тела: 36,6°C.
• Датчик уровня воды в поилке: 80%.

Мы такие: "Ура! Все датчики в норме! Хомяк жив-здоров! Можно идти пить тыквенный латте и писать докладик на очередную конференцию.".

А НА САМОМ ДЕЛЕ: Хомяк уже второй час долбится головой о колесо, у него паническая атака, он дожирает свою подстилку и в глазах у него безумие. Но мы этого не видим, потому что наши датчики не измеряют "уровень паники хомяка". Они показывают, что он "активен", "температура тушки в норме" и "вода в поилке есть".

Мониторинг отвечает на вопрос "что происходит?" по заранее известным сценариям. Всё, что не предусмотрели - остаётся за кадром.

Наблюдаемость (observability) - это когда мы посадили хомяка в прозрачный аквариум с кучей камер и микрофонов¶

Мы не просто смотрим на цветные числа на дашборде. Мы можем задать ЛЮБОЙ, даже самый идиотский вопрос и получить на него ответ из данных, потому что у нас есть не просто датчики, а полная телеметрия всего, что происходит.

• Наши датчики (мониторинг) показывают: "Колесо крутится, уровень воды падает".
• А наблюдаемость позволяет спросить: "А сколько раз за последний час хомяк подбегал к поилке, но не пил, а просто тыкался в неё носом и убегал?"

И система нам ответит: "17 раз. И, кстати, это поведение сильно коррелирует с моментом, когда сосед включил Кадышеву".

Вот это наблюдаемость. Это возможность задавать ad-hoc вопросы о состоянии системы без дополнительных телодвижений.

Теперь приземлим на реальность¶

Допустим, у нас пользователь создает ВМ разных конфигураций.

Мониторинг (что у нас есть):¶

• График "Количество созданных ВМ в час". Падает - всё плохо, алертим. Хотя и неизвестно, может сейчас ночь или новогодние выходные. Все равно алертим, дежурному делать нечего, он разберется.
• График "Время ответа сервера". Растёт - всё плохо, алертим.
• Красная лампочка "База данных не отвечает". Ваще все плохо, алертим.

Это наши датчики на клетке. Они тупо и честно следят за известными метриками.

Наблюдаемость (о чём вы даже не думали, пока не случилась хрень):¶

• Внезапно перестали создаваться ВМ, но все датчики в мониторинге зелёные! Заказы идут, сервер быстрый, база жива. Чё за хтонь?
• Без наблюдаемости мы ходим кругами, зовем все больше и больше народу в ТКС и все вместе думаем и гадаем, в ТКС подключаются большие начальники, задают вопросы, накал растет, инженеры вешаются.
• С наблюдаемостью мы можем спросить систему: "Покажи мне поведение пользователей за последние 6 часов, которые зашли на страницу "Создать ВМ", но не почему-то ничего не создали. Сравни со вчерашним днём".

И система нам выдаёт: "93% таких пользователей спотыкаются на новом шаге "Укажите номер промокода в честь очередной конференции", который кто-то вчера вечером незаметно и мимо стейджа задеплоил из дева сразу в прод. На этом шаге падает promokod.js c ошибкой Promokod is not defined, которую не видно в общих метриках ошибок, потому что никто этого не предусмотрел".

Наблюдаемость это способность системы через свои логи, трейсы и метрики рассказать ПОЧЕМУ она болеет, а не просто констатировать факт, что у неё температура.

Короче говоря:¶

• Мониторинг: мы заранее знаем, на какие вопросы хотим получить ответы, и ставим датчики, которые нам эти ответы дают. ("Жив хомяк?").
• Наблюдаемость: мы не знаем, какие вопросы возникнут завтра, но мы построили систему так, чтобы она могла ответить на ЛЮБОЙ наш вопрос о своём состоянии. ("Почему хомяк, будучи живым, сжёг свою клетку и теперь строит гильотину из опилок?").

Еще короче:

• Мониторинг кричит: "ВСЁ ПРОПАЛО!" когда уже все пропало.
• Наблюдаемость подаёт отчёт: "Вот какой сервис виноват, вот где косяк, вот как это починить. Не благодари".

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

Еще пример: холодильник и шеф-повар¶

Мониторинг холодильника:¶

У нас есть датчики:

• Температура в камере: +4°C (норма).
• Дверь закрыта: Да.
• Компрессор работает: Циклируется штатно.

По мониторингу — всё идеально. Холодильник работает.

А НА САМОМ ДЕЛЕ: Внутри протухшее мясо и адски воняет. Просто потому что кто-то две недели назад забыл его там. Мониторинг не видит качества содержимого.

Наблюдаемость на кухне ресторана:¶

Это когда шеф-повар заходит на кухню и за 5 секунд по косвенным признакам понимает ВСЁ:

• Видит бледное лицо повара-стажёра (метрика).
• Слышит, как сотейник шипит слишком громко (лог).
• Чувствует запах подгоревшего чеснока (трейс).
• Видит, что соус "бешамель" имеет не ту консистенцию (производительность).

Он не просто видит "плита включена". Он понимает контекст и причину проблемы: "Стажёр пересыпал соли в соус, от стресса забыл про чеснок на сковороде, и теперь вся кухня в аду". Это наблюдаемость.

И еще пример: скорая в Москве¶

Мониторинг машины скорой помощи:¶

• Датчик уровня топлива: 70%.
• Датчик давления в шинах: 2,3 атм.
• Датчик скорости: 55 км/ч.

Всё в норме. Машина едет.

А НА САМОМ ДЕЛЕ: Водитель заблудился возле Кремля, навигатор глючит, врачи в панике, а пациент на заднем сиденье уже на полпути в мир иной. Мониторинг не видит миссию.

Наблюдаемость машины скорой помощи:¶

Это когда диспетчер видит у себя на экране:

• Трейс (траектория): машина третий раз объезжает один и тот же квартал.
• Логи (переговоры): водитель по рации матерится и говорит про "сломанный GPS".
• Метрики (состояние): пульс пациента и насышенность крови кислородом с телеметрии с носилок начали падать.
• Контекст: диспетчер видит, что в 500 метрах стоит другая свободная бригада.

Он не просто видит "машина едет". Он понимает полную картину провала миссии и может дать команду: "скорая 145, прекратите петлять и остановитесь! Пациента передавайте экипажу 146, который стоит за углом и через три минуты будет у вас!". Это наблюдаемость.

И еще пример:¶

Представь, что у тебя есть автомобиль.

Мониторинг — это все лампочки на твоей приборной панели.

• Лампочка "Кончается бензин".
• Лампочка "Проверь двигатель".
• Лампочка "Низкое давление масла".

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

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

Мониторинг отвечает на вопрос: "Система в норме или нет?"

Главный минус: Он может сказать тебе, что что-то где-то не так (лампочка горит красным), но он не может сказать почему это произошло или как это починить, если это что-то новенькое. Если у тебя взорвалось колесо, а лампочки "взорвалось колесо" на панели нет, мониторинг будет молчать, пока ты не врежешься в столб.

Мониторинг говорит, что система работает.

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

Как начать завтра строить у себя Observability 2.0¶

1. Выбрать одно хранилище:
2. маленький объём: например, ClickHouse-кластер
3. большой объём: Hydrolix/GreptimeDB/и т.п.
4. Поставить OpenTelemetry Collector Helm-чарт с exporter=clickhouse.
5. Включить eBPF-автоинструментацию на dev.
6. Создать одну таблицу events_wide (timestamp, service, trace_id, …).
7. Дать инженерам доступ к SQL-консоли и Grafana ClickHouse-datasource.
8. Запретить создавать новые дашборды без описания вопроса, который они отвечают.
9. Через 2 недели удалить 50 % старых Prometheus-алертов: вы увидите, что они дублируют burn-rate-запросы.

Анти-паттерны, которые убивают 2.0 на корню¶

• "Мы просто добавим ещё одну метрику".
• "А давайте хранить логи в ELK, а трейсы в Tempo".
• "У нас 1000 микросервисов, не потянем кардинальность": используйте sampling и TTL.
• "Безопасники запрещают хранить user_id": хешируйте на лету в Collector, но оставляйте уникальный хеш, иначе теряется смысл.

Что дальше: AI-операторы и "закрытые циклы"¶

Wide events это идеальный материал для LLM-агентов: агент получает естественно-языковый запрос: - "Почему платежи через ХБанк стали падать с 14:30?" - Автоматически генерирует SQL и видит аномальный рост error_code=3ds_failed. - Проверяет последний деплой: build_id=1.2.3 был rolled out в 14:28. - Создаёт откат-PR и поднимает on-call.

Через 5 минут ошибка исчезает, бюджет SLO не тронут. Так это работает в Netflix, Stripe, Shopify и других - у них нет дашбордов, есть query engine + автоматические "исполнители".