Observability vs мониторинг: чем отличается и зачем нужна наблюдаемость в 2026

Observability — что это такое понимаешь не по определению, а в ночь, когда все алерты зелёные, а пользователи пишут в поддержку. Обычно в таких случаях всё стандартно: страница оформления заказа зависает, но не у всех, а у части пользователей и только в часы пик. Загрузка CPU в норме, доля ошибок ниже порога, доступность 100%. Дашборд показывает здоровую систему, клиент видит крутящийся спиннер.

Классический мониторинг здесь не сломался — он отвечает ровно на тот вопрос, который вы задали заранее, когда писали алерт: порог пересечён или нет. В монолите набор таких вопросов конечен. В системе из полусотни сервисов путей запроса сотни, и заранее описать все способы деградации невозможно. Тормозит не сервис, а конкретный вызов внутри конкретной цепочки при конкретном состоянии кэша.

Наблюдаемость (observability) — это способность ответить на вопрос, который вы не готовили заранее. Ниже разберём, чем она отличается от мониторинга, как устроены три столпа и распределённая трассировка, что изменил OpenTelemetry, с чего начинать внедрение и где наблюдаемость не помогает.

Мониторинг: что он умеет и где его предел

Мониторинг собирает заранее определённый набор метрик и поднимает алерт, когда значение пересекает порог. Вопрос, на который он отвечает: «что происходит прямо сейчас». Загрузка CPU выше 80%, время ответа выше 500 мс, доля пятисотых выше 1%. Инструменты знакомые: Prometheus опрашивает экспортеры (скрейпит) и хранит ряды, Grafana рисует, Alertmanager рассылает уведомления. В российской практике рядом живут Zabbix и надстройки над ним.

Модель никуда не уходит и уходить не должна. По опросу Grafana Labs 2026 года, который проводит сам вендор наблюдаемости, в Prometheus инвестируют 77% организаций. Пороговый алерт по свободному месту на диске или по доле ошибок закрывает большой класс аварий дешевле любой трассировки.

Проблема известных неизвестных

Предел мониторинга заложен в его конструкции. Алерт существует только там, где инженер заранее предположил отказ и описал его условием. Это «известные неизвестные»: вы знаете, что диск может закончиться, и не знаете, когда именно.

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

Отсюда два следствия, которые видно в данных. Число алертов растёт быстрее пользы от них: крупнейшим единичным препятствием к быстрому реагированию на инциденты 30% респондентов Grafana Labs назвали alert fatigue (усталость от алертов) — почти вдвое чаще следующего по частоте ответа. Полезный сигнал при этом тонет в шуме: соотношение «сигнал/шум» заняло второе место среди проблем наблюдаемости с 34%.

Мониторинг отвечает на вопрос «что». Вопрос «почему» он не закрывает и не проектировался под него.

Observability — что это такое: наблюдаемость как свойство системы

Observability, то есть наблюдаемость — свойство, при котором внутреннее состояние системы определимо по внешним выходным данным за конечное время. Строгий ответ на вопрос «observability — что это» дала теория управления, а не маркетинг вендоров: понятие наблюдаемости ввёл Рудольф Калман в 1960 году. В эксплуатацию софта формулировка перенесена почти дословно: «внешние выходные данные» стали телеметрией, «внутреннее состояние» — тем, что происходит внутри процесса на конкретном поде.

Из формулировки следует неудобное для закупки: наблюдаемость нельзя купить отдельным продуктом. Она определяется тем, что система о себе рассказывает, а рассказывает она ровно то, что заложил разработчик. Вендор продаёт бэкенд для хранения и запросов, но если сервис не передаёт идентификатор трейса и не пишет контекст в лог, восстановить их не сможет ни один бэкенд.

Разница с мониторингом лежит в вопросе, а не в наборе инструментов. Мониторинг отвечает «что» по заранее описанным метрикам и порогам, наблюдаемость отвечает «почему», включая сценарии, которых никто не предвидел. Формула «мониторинг — известные неизвестные, наблюдаемость — неизвестные неизвестные» стала общим местом отрасли, но канонического первоисточника у неё нет, и выдавать её за определение из Google SRE Book не стоит.

Три столпа observability: метрики, логи, трейсы

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

• Метрики — числовые ряды во времени: RPS, время ответа, глубина очереди, насыщение диска. Дёшевы в хранении, агрегируются, годятся для алертов и трендов, отвечают на вопрос «что и насколько».
• Логи — дискретные события с контекстом: что случилось в конкретный момент, с какими параметрами, с каким идентификатором заказа. Самый дорогой по объёму сигнал, отвечает на вопрос «что именно произошло в этом запросе».
• Трейсы — цепочка вызовов одного запроса через все сервисы. Показывают, где потрачено время и какое звено вернуло ошибку, отвечают на вопрос «где именно».

Собрать все три сигнала мало: пока они не связаны общим идентификатором, у дежурного оказывается три инструмента вместо одной картины.

Четвёртый сигнал, continuous profiling (непрерывное профилирование), отвечает на вопрос «какая функция съела процессор». В OpenTelemetry он с 26 марта 2026 года находится в статусе public alpha: планировать на нём продакшен рано, знать о нём стоит.

Distributed tracing: как найти проблему в цепочке микросервисов

Distributed tracing (распределённая трассировка) — способ проследить путь одного запроса через все сервисы системы. Каждый входящий запрос получает идентификатор трейса, дальше он передаётся из сервиса в сервис в HTTP-заголовках, и каждый участок работы записывается отдельным span'ом (шагом трейса) со временем начала и окончания. На выходе получается дерево вызовов: видно, кто кого вызвал, сколько занял каждый вызов и где ветка оборвалась ошибкой.

Держится это на стандарте W3C Trace Context. Заголовок traceparent переносит идентификатор трейса и родительского span'а, tracestate — вендор-специфичный контекст. Первый уровень спецификации имеет финальный статус W3C Recommendation с 23 ноября 2021 года. Второй уровень находится в статусе Candidate Recommendation Draft и может измениться до финального: рабочая группа ждёт минимум двух реализаций с прогоном тестового набора. Отсюда практический вывод: propagation (передача контекста трейса между сервисами) — не деталь реализации конкретного вендора, а то, без чего трассировка не становится распределённой.

Хранят и показывают трейсы отдельные системы: Jaeger, Zipkin, Grafana Tempo. Distributed tracing даёт не ещё один дашборд, а связь между сервисами, которой нет ни в метриках, ни в логах.

Разбор инцидента с оформлением заказа по трейсу

Вернёмся к зависшей странице оформления заказа. Разбор по шагам выглядит так:

1. Берём идентификатор. Из структурированного лога фронтенда достаём trace_id любого медленного запроса, попавшего в жалобу. Без общего идентификатора этот шаг невозможен, и дальше идти некуда.
2. Открываем трейс. В Jaeger по trace_id поднимается дерево span'ов всей цепочки: фронтенд → API-шлюз → order-service → payment-service.
3. Смотрим распределение времени. Общая длительность запроса 14 с, из них 13,3 с приходится на один span вызова payment-service, остальные звенья отработали за десятки миллисекунд.
4. Раскрываем узкое звено. Внутри span'а payment-service видно дочерний вызов fraud-check с таймаутом 3 с и четырьмя ретраями.
5. Читаем атрибуты span'а. Ретраи срабатывают только на запросах с определённым типом карты, поэтому проблема воспроизводится у части пользователей и растёт в часы пик вместе с нагрузкой на fraud-check.
6. Фиксируем вывод. Виновата не «оформление заказа» целиком и не сеть, а политика ретраев на одном вызове. Доступ к серверам для этого не понадобился.

Трейс показывает, какой именно вызов в цепочке отдал ошибку или задержку, и снимает этап «воспроизвести и перебрать логи пяти сервисов вручную». Насколько это сократит разбор в конкретной команде, зависит от того, инструментированы ли все сервисы на пути запроса и умеет ли дежурный читать дерево span'ов. Ни то ни другое трассировка за вас не делает.

OpenTelemetry: единый стандарт инструментирования

OpenTelemetry (OTel) — набор SDK, семантических соглашений и протокол передачи OTLP под эгидой CNCF. Смысл в разделении труда: приложение инструментируется один раз, а телеметрия после этого уходит в любой совместимый бэкенд. Меняете хранилище трейсов — код приложения не трогаете.

11 мая 2026 года проект перешёл в CNCF на уровень зрелости graduated, а публично CNCF объявил об этом 21 мая 2026 года на Observability Summit в Миннеаполисе. Для планирования это значит, что стандарт перестал быть ставкой на будущее.

OTel не заменяет Prometheus, а кормит его

Частая ошибка при планировании миграции — считать OpenTelemetry конкурентом Prometheus. Роли разные: OTel отвечает за сбор и стандартизацию телеметрии, хранение, запросы и алертинг остаются за бэкендами вроде Prometheus, Jaeger, Loki и Tempo.

Практика это подтверждает. По опросу Grafana Labs 2026 года 65% организаций инвестируют одновременно и в Prometheus, и в OpenTelemetry, а общий уровень инвестиций почти сравнялся: 77% против 76%. Различается стадия зрелости: на этапе изучения и пилота OTel находятся 35% организаций против 18% у Prometheus, нарастили вложения за год 47% против 42%. Принятие по сигналам тоже неравномерное: метрики через OTel собирают 57% респондентов, трейсы 50%, логи 48%.

Prometheus остаётся местом жизни метрик, а OTel становится слоем, который до него их доводит и заодно приносит трейсы и логи в том же формате. Стек от этого не упрощается — компонентов больше, связывать их приходится самим.

Четвёртый сигнал: профили пока в статусе alpha

Continuous profiling в OpenTelemetry перешёл в public alpha 26 марта 2026 года. eBPF-профайлер работает как receiver в OpenTelemetry Collector, добавлены автоматическая символизация Go и поддержка новых языковых рантаймов, среди контрибьюторов Google, Datadog и Elastic.

Именно на этом месте чаще всего ошибаются обзоры: сигналу приписывают GA (general availability, общедоступный релиз) или release candidate. Официальный анонс говорит про alpha, публичной даты выхода в GA нет. Планировать разбор инцидентов вокруг профилей рано, пробовать на некритичном контуре можно.

Что для этого есть в VK Cloud

Управляемый Kubernetes в VK Cloud называется Cloud Containers (в материалах блога тот же сервис встречается как Managed Kubernetes). Наблюдаемость собирается из аддонов кластера, и они не преднастроены. Аддон выбирается явно при создании кластера через Terraform или позже, во вкладке «Аддоны» в личном кабинете, и работает на ресурсах worker-узлов.

• Kube Prometheus Stack — Prometheus, Grafana и Alertmanager одним аддоном. У версии с доработками VK Tech (суффикс vk в номере версии) есть прогнозирование потребления ресурсов кластера методом линейной регрессии: дашборды прогнозов в Grafana и алерты о скором исчерпании ресурсов. Для master-узлов прогноз не считается.
• Jaeger — распределённая трассировка с приёмом по OTLP. Управляемого OpenTelemetry Collector в платформе нет: приложение инструментируется OTel SDK самостоятельно, эндпоинт задаётся переменными OTEL_EXPORTER_OTLP_ENDPOINT и OTEL_EXPORTER_OTLP_PROTOCOL.
• logaas-integration — доставка логов кластера в Cloud Logging. Обычный Fluent Bit доступен только кластерам первого поколения.

Cloud Monitoring и Cloud Logging не тарифицируются . Две честные оговорки для планирования: обновление аддона мониторинга средствами платформы недоступно, его обновляют вручную через удаление старой версии и установку новой. Jaeger требователен к ресурсам: worker-узлы от STD3-4-4 для тестового контура и от STD3-6-6 для продуктивного.

В том же кластере живут соседние аддоны. GPU Operator в Managed Kubernetes пригодится, если в нём есть GPU-узлы. Argo CD в Managed Kubernetes закрывает доставку изменений, которую наблюдаемость только фиксирует.

Мониторинг vs observability: таблица сравнения

Отличие мониторинга и observability не в списке инструментов, а в том, какие вопросы можно задать после того, как что-то сломалось. Таблица сводит ответ на «observability — что это» к практическим различиям, которые видно на дежурстве.

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

Как внедрить observability: практический минимум

Что ломается на масштабе: кардинальность

Наблюдаемость дорожает нелинейно, и техническая причина у этого конкретная. Кардинальность — число уникальных комбинаций значений лейблов метрики, и каждая такая комбинация создаёт отдельный временной ряд. Каждый активный ряд занимает память, поэтому счёт идёт не на метрики, а на миллионы рядов . Prometheus сжимает head-блок в постоянные блоки каждые два часа, и на миллионах серий компакция ощутимо давит на производительность записи.

Типовые причины взрыва кардинальности одни и те же: в лейблы попадают идентификатор пользователя, идентификатор трейса или URL с параметрами. Лечится это в месте создания ряда, а не в месте хранения: удаление и переписывание лейблов через metric_relabel_configs, предагрегация через recording rules (заранее посчитанные ряды), ограничение sample_limit на скрейп, замена неограниченного значения на ограниченный набор корзин.

С трейсами работает похожая логика через семплирование — отбор части трейсов на хранение. При head-based-семплировании решение принимается в начале запроса, до того как известен его исход. При tail-based-семплировании система дожидается завершения трейса и решает по полному контексту: все ошибочные и медленные трейсы сохраняются, рутинные выбрасываются.

Ограничения наблюдаемости

Ответ на «observability — что это» будет неполным без обратной стороны. Данные 2026 года показывают, что узкое место сместилось: телеметрии стало достаточно, а разбор инцидентов быстрее не стал.

Сложность обогнала стоимость

Главный сигнал 2026 года неудобен для отрасли, которая продаёт телеметрию. В уже упомянутом опросе Grafana Labs первое место среди проблем наблюдаемости заняли сложность и накладные расходы с 38%, соотношение «сигнал/шум» набрало 34%, стоимость — 31%. То есть команды жалуются уже не на счёт, а на то, что для получения одного ответа приходится поднять и связать между собой пять-семь компонентов.

Про источник стоит сказать прямо: это опрос вендора. Grafana Labs собрала 1 363 ответа инженеров, SRE и техруководителей из 76 стран. Поле работало с 1 октября 2025 по 6 января 2026 года, результаты опубликованы 18 марта 2026 года. Методология раскрыта, но Grafana заинтересована в open-source-нарративе, и читать цифры нужно с этой поправкой.

Контраргумент к собственному тезису тоже есть в тех же данных. Сложность растёт отчасти потому, что наблюдаемость работает: 77% организаций говорят, что сэкономили время или деньги благодаря централизации телеметрии. Половина ожидает роста трат, но главные драйверы здесь — расширение охвата (63%) и ожидание большего ROI (31%), а рост цен вендоров называет лишь четверть. Стек усложняется, потому что его сознательно расширяют.

«Три столпа» как коммерческая конструкция

Отдельная линия критики принадлежит Charity Majors, сооснователю и техническому директору Honeycomb. В пересказе её позиция такая: деление на три столпа — конструкция маркетинговая, а не техническая, и удобна она в первую очередь вендорам, которым так проще продавать три отдельных продукта. Один и тот же запрос сохраняется несколько раз в разных инструментах, связей между копиями почти нет, а платить за хранение приходится трижды. В качестве альтернативы Majors описывает единое хранилище широких структурированных событий с высокой кардинальностью.

Дисклеймер обязателен: Honeycomb продаёт продукт, построенный ровно на этой модели, поэтому перед нами позиция заинтересованной стороны, а не нейтральный разбор. Полезна она другим: заставляет проверить, сколько раз ваша команда платит за хранение одних и тех же данных в разных системах и можете ли вы связать копии между собой.

Инструмент не заменяет инженерную дисциплину

Экономика подтверждает, что покупкой вопрос не закрывается. По отчёту Elastic (опрошено более 500 ИТ-руководителей) 97% организаций сталкиваются с перерасходом бюджета на наблюдаемость, а 67% сообщают о регулярных сюрпризах по стоимости. Ещё 54% руководителей отмечают рост запросов сверху обосновать эти расходы. Это тоже вендорский отчёт, и Elastic продаёт в том числе контроль стоимости телеметрии.

Самый неприятный аргумент даёт DORA. В отчёте State of DevOps 2025 зафиксировано, что рост внедрения ИИ коррелирует с ростом нестабильности поставки ПО, даже когда индивидуальная продуктивность инженеров растёт. Заодно метрика Failed Deployment Recovery Time в редакции 2025 года переопределена и перенесена из категории стабильности в категорию пропускной способности. Вывод общий для обоих наблюдений: скорость восстановления определяется процессами поставки, а не количеством собранных сигналов.

Практическое следствие для планирования: добавление ещё одного сигнала само по себе не сокращает время разбора инцидента, оно расширяет пространство поиска. Сокращают время связность сигналов между собой, дисциплина инструментирования и работающий процесс дежурства.

Заключение

Мониторинг и наблюдаемость не конкуренты и не стадии эволюции, между которыми надо выбрать. Мониторинг — реактивный контроль известных параметров, и в этой роли он дёшев и незаменим. Наблюдаемость — свойство системы, при котором её поведение можно исследовать даже в сценариях, которых никто не предусмотрел заранее. В микросервисной архитектуре без второго не обойтись, но покупкой инструментов оно не появляется.

Начать разумно с малого: RED-метрики на сервисах, структурированные логи с идентификатором трейса, трассировка одного критичного пути. Дальше смотреть не на количество сигналов, а на то, связаны ли они между собой. В опросе Grafana Labs 2026 года первыми проблемами наблюдаемости названы сложность стека и шум в сигнале, а не стоимость телеметрии. Observability — что это в сухом остатке: способность задать системе вопрос, которого вы не готовили заранее, и получить ответ по уже собранным данным.