Ночь. Сервис падает, приложение не отвечает, а алерты летят пачками. Дежурный инженер понимает, что что-то сломалось, но из имеющихся данных не может выявить причину. Если просто, то именно так выглядит разрыв между мониторингом и наблюдаемостью.
Мониторинг отслеживает известные параметры — как камера, которая смотрит туда, куда вы её поставили. А наблюдаемость позволяет системе находить истину, отвечая даже на те вопросы, которые никто заранее не догадывался задать. В статье рассказываем, чем эти подходы отличаются, когда одного мониторинга недостаточно и как выстроить полноценный контроль над ИТ-инфраструктурой.
Разобраться в теме нам помогает Дмитрий Унтила, CPO «Пульта» и «Графини» в «Лаборатории Числитель», более 10 лет работающий с системами мониторинга.
Мониторинг отслеживает известные параметры — как камера, которая смотрит туда, куда вы её поставили. А наблюдаемость позволяет системе находить истину, отвечая даже на те вопросы, которые никто заранее не догадывался задать. В статье рассказываем, чем эти подходы отличаются, когда одного мониторинга недостаточно и как выстроить полноценный контроль над ИТ-инфраструктурой.
Разобраться в теме нам помогает Дмитрий Унтила, CPO «Пульта» и «Графини» в «Лаборатории Числитель», более 10 лет работающий с системами мониторинга.
Мониторинг: что это такое простыми словами
Система мониторинга: что это и зачем нужно
Система мониторинга — это набор инструментов и процессов, которые непрерывно следят за состоянием инфраструктуры: серверы, приложения, сеть и другое по заранее определенному набору показателей. Это автоматическое наблюдение за тем, что уже известно и ожидаемо.
Мониторинг в практическом смысле, прежде всего, подразумевает алерты, дашборды и иногда отчёты. Система собирает метрики (загрузка CPU, использование памяти, количество ошибок), сравнивает их с пороговыми значениями и сигнализирует, когда что-то выходит за норму. Так инженер узнает о проблеме быстрее, чем её обнаружит пользователь.
Мониторинг простыми словами — это «градусник» инфраструктуры, показывающий температуру и бьющий тревогу при жаре, но не объясняющий, чем вызвана болезнь.
Качество работы сервисов в мониторинге принято выражать через три понятия:
Мониторинг в практическом смысле, прежде всего, подразумевает алерты, дашборды и иногда отчёты. Система собирает метрики (загрузка CPU, использование памяти, количество ошибок), сравнивает их с пороговыми значениями и сигнализирует, когда что-то выходит за норму. Так инженер узнает о проблеме быстрее, чем её обнаружит пользователь.
Мониторинг простыми словами — это «градусник» инфраструктуры, показывающий температуру и бьющий тревогу при жаре, но не объясняющий, чем вызвана болезнь.
Качество работы сервисов в мониторинге принято выражать через три понятия:
- SLA (Service Level Agreement) — обещанный уровень обслуживания, зафиксированный в договоре с заказчиком.
- SLO (Service Level Objective) — целевые показатели качества, на которые ориентируется внутренняя команда.
- SLI (Service Level Indicator) — конкретные измеряемые показатели: время ответа, процент ошибок, доступность.
Что умеет мониторинг и где его предел
Хорошо настроенный мониторинг позволяет оперативно обнаружить и локализовать проблему, получить срез работы системы за конкретный период и минимизировать MTTR (Mean Time To Repair) — время восстановления после инцидента.
Однако мониторинг оперирует заранее известными метриками — теми, которые определяются при настройке. Если проблема возникает в неожиданном месте или по причине, которую никто не предвидел, мониторинг зафиксирует симптом («что-то пошло не так»), но не даст ответа на вопрос «почему». Кроме того, избыток алертов создает «шум»: когда уведомления сыплются постоянно, по-настоящему опасный сигнал может быть проигнорирован.
Дмитрий Унтила: «Мониторинг и observability не являются альтернативными или конкурирующими подходами. Они представляют собой части одного процесса: мониторинг фиксирует проблему, observability позволяет расследовать инцидент и предотвратить его повторение».
Именно здесь на помощь приходит наблюдаемость.
Однако мониторинг оперирует заранее известными метриками — теми, которые определяются при настройке. Если проблема возникает в неожиданном месте или по причине, которую никто не предвидел, мониторинг зафиксирует симптом («что-то пошло не так»), но не даст ответа на вопрос «почему». Кроме того, избыток алертов создает «шум»: когда уведомления сыплются постоянно, по-настоящему опасный сигнал может быть проигнорирован.
Дмитрий Унтила: «Мониторинг и observability не являются альтернативными или конкурирующими подходами. Они представляют собой части одного процесса: мониторинг фиксирует проблему, observability позволяет расследовать инцидент и предотвратить его повторение».
Именно здесь на помощь приходит наблюдаемость.
Наблюдаемость (Observability): новый уровень понимания систем
Итак, что такое observability? Наблюдаемость — это способность понять внутреннее состояние системы исключительно на основе её внешних сигналов. Не просто расширенный мониторинг, а принципиально иной подход к работе с данными. Система, обладающая наблюдаемостью, способна «рассказать» инженеру, что с ней происходит, даже если он заранее не знал, какой вопрос задать. Это свойство, которое достигается за счёт правильно организованного сбора и корреляции трёх типов данных: метрик, логов и трассировок. Их называют тремя столпами observability.
Три столпа наблюдаемости: метрики, логи, трассировки
Метрики — численные показатели, собираемые с течением времени: загрузка CPU, количество запросов в секунду, процент ошибок. Метрики показывают форму и масштаб проблемы, сигнализируют, что «что-то пошло не так», но не объясняют причину. Используются как инфраструктурные, так и пользовательские метрики. Типичные инструменты: Zabbix или «Пульт», Prometheus, Grafana или «Графиня».
Логи — детальные записи событий, которые фиксируют конкретные действия в коде: trace_id, user_id, order_id. Логи обеспечивают контекст: именно они отвечают на вопрос, что именно произошло в конкретный момент времени. Инструменты агрегации: Loki, ELK Stack.
Трассировки (traces) — сквозные цепочки вызовов, которые показывают путь запроса через все микросервисы и компоненты распределенной системы. Трассировки позволяют увидеть узкое место, понять причину задержки и отличить симптом от корневой причины. Это самый ценный тип данных для диагностики неизвестных проблем. Инструменты: Tempo, Jaeger, OpenTelemetry.
Логи — детальные записи событий, которые фиксируют конкретные действия в коде: trace_id, user_id, order_id. Логи обеспечивают контекст: именно они отвечают на вопрос, что именно произошло в конкретный момент времени. Инструменты агрегации: Loki, ELK Stack.
Трассировки (traces) — сквозные цепочки вызовов, которые показывают путь запроса через все микросервисы и компоненты распределенной системы. Трассировки позволяют увидеть узкое место, понять причину задержки и отличить симптом от корневой причины. Это самый ценный тип данных для диагностики неизвестных проблем. Инструменты: Tempo, Jaeger, OpenTelemetry.
Наблюдаемость системы: зачем нужны столпы
Каждый из столпов наблюдаемости ценен сам по себе, но полная картина возникает только при их корреляции. Метрика сигнализирует о всплеске ошибок; лог уточняет, в каком именно сервисе всё произошло; трассировка показывает, по какому пути прошёл сбойный запрос и на каком шаге всё пошло не так. Именно связка всех трёх даёт возможность за считанные минуты проводить RCA (root cause analysis) — анализ корневой причины инцидента.
Кроме классической «тройки», в современных observability-стеках используются события (events) и бизнес-контекст: данные о деплоях и конфигурационных изменениях. Это помогает понять, не совпало ли «неизвестное» падение с недавним релизом.
Кроме классической «тройки», в современных observability-стеках используются события (events) и бизнес-контекст: данные о деплоях и конфигурационных изменениях. Это помогает понять, не совпало ли «неизвестное» падение с недавним релизом.
Мониторинг и наблюдение: в чём отличия
Прежде чем углубляться в детали, разберёмся с терминологией. Отличия между мониторингом и наблюдением часто формулируют так: мониторинг — это процесс сбора и отображения данных, а наблюдение (наблюдаемость, observability) — это свойство самой системы быть понятной изнутри. Чем мониторинг отличается от наблюдения? Мониторинг фиксирует симптомы, а наблюдаемость раскрывает их причины.
Мониторинг и анализ — это одно и то же?
На самом деле — нет. Разница между ними в глубине погружения в данные. Мониторинг фиксирует факт отклонения от нормы и сигнализирует об этом. Анализ нужен для исследования собранных данных, чтобы понять причины произошедшего и предотвратить повторение. Наблюдаемость создает условия для качественного анализа, предоставляя богатый контекст.
Отличие мониторинга и наблюдаемости в направленности: если мониторинг отвечает на вопрос «что сломалось?», то наблюдаемость — «почему сломалось?». Эту разницу можно выразить через метафору: мониторинг — это рефлексы организма, а наблюдаемость — его нервная система.
Отличие мониторинга и наблюдаемости в направленности: если мониторинг отвечает на вопрос «что сломалось?», то наблюдаемость — «почему сломалось?». Эту разницу можно выразить через метафору: мониторинг — это рефлексы организма, а наблюдаемость — его нервная система.
Сравнительная таблица: мониторинг vs observability
Почему DevOps-командам недостаточно только мониторинга
Традиционный мониторинг разрабатывался для монолитных приложений с ограниченным набором серверов. Современная ИТ-инфраструктура устроена иначе: микросервисы, контейнеры, оркестрация, облачные платформы, интеграции с внешними API и SaaS-сервисами — все это порождает тысячи взаимозависимостей, которые невозможно предусмотреть заранее.
В распределённой системе один пользовательский запрос может пройти через десятки сервисов. Если где-то возникает задержка или ошибка, мониторинг покажет симптом, но не укажет, на каком именно звене цепочки произошел сбой. SRE-инженеры тратят часы на ручной «раскоп» логов из разрозненных источников.
Наблюдаемость решает эту проблему системно: позволяет выявлять деградацию до момента отказа, предоставлять контекст вместо разрозненных сигналов и автоматизировать реакцию через runbook automation. При этом мониторинг и наблюдаемость не конкурируют, а дополняют друг друга как части единого процесса.
В распределённой системе один пользовательский запрос может пройти через десятки сервисов. Если где-то возникает задержка или ошибка, мониторинг покажет симптом, но не укажет, на каком именно звене цепочки произошел сбой. SRE-инженеры тратят часы на ручной «раскоп» логов из разрозненных источников.
Наблюдаемость решает эту проблему системно: позволяет выявлять деградацию до момента отказа, предоставлять контекст вместо разрозненных сигналов и автоматизировать реакцию через runbook automation. При этом мониторинг и наблюдаемость не конкурируют, а дополняют друг друга как части единого процесса.
Матрица эскалации: инструмент реагирования на инциденты
Что такое матрица эскалации и зачем она нужна
Матрица эскалации — это структурированный регламент, который определяет порядок действий при инциденте: кто получает уведомление первым, через какое время подключается следующий уровень поддержки, кто принимает решения при критических сбоях.
Матрица эскалации — это обязательный инструмент зрелой команды по мониторингу. Без неё даже лучший observability-стек не гарантирует быстрой реакции, потому что люди не знают, что им делать с полученной информацией.
Матрица эскалации — это также способ управлять on-call-нагрузкой: чётко прописанные приоритеты и время реакции снижают стресс дежурных инженеров.
Матрица эскалации — это обязательный инструмент зрелой команды по мониторингу. Без неё даже лучший observability-стек не гарантирует быстрой реакции, потому что люди не знают, что им делать с полученной информацией.
Матрица эскалации — это также способ управлять on-call-нагрузкой: чётко прописанные приоритеты и время реакции снижают стресс дежурных инженеров.
Пример матрицы эскалации для ИТ-команды
Ниже приведен обобщенный пример матрицы эскалации — упрощенная структура для команды, эксплуатирующей микросервисное приложение.
В реальных командах матрица дополняется конкретными именами, ссылками на runbook-документацию и автоматическими триггерами из системы мониторинга или observability-платформы. Инцидент P1 должен автоматически создавать тикет, отправлять уведомление дежурному инженеру и запускать пошаговый runbook — без ручного вмешательства.
Как выстроить observability-стек на практике
С чего начать: от мониторинга к наблюдаемости
Внедрение observability — это не разовое действие, а эволюционный процесс. Показываем рекомендуемую последовательность шагов.
1. Определить норму. Выявить 3−5 критических пользовательских сценариев (авторизация, оформление заказа, поиск) и сформулировать SLO: например, «99,9% запросов выполняются быстрее 300 мс».
2. Ввести SLI/SLO. Без них алерты не будут связаны между собой. Начинать стоит с простого SLO и корректировать его на основе реального опыта.
3. Стандартизировать сбор данных. Единый формат логов (JSON), единая система наименования метрик, использование OpenTelemetry для трассировок — иначе данные из разных сервисов будет невозможно сопоставить.
4. Построить базовую «тройку»: метрики (RED/Golden Signals: rate, errors, duration), трассировки (end-to-end сквозные, с разумным sampling), структурированные логи с балансом между длительностью хранения и стоимостью.
5. Сделать алерт точкой входа в observability. Хороший алерт основан на SLO, содержит данные о том, что сломалось, кого затронуло, а также включает ссылки на дашборд и проблемную трассировку. Если алерт нельзя расследовать за 2−3 клика, он неэффективен.
6. Встроить observability в процесс релизов. Каждый деплой — потенциальный инцидент. Сравнение метрик до и после релиза должно стать стандартной практикой.
7. Использовать инциденты для улучшения. После каждого инцидента — аудит: каких сигналов не хватало, какой алерт должен был сработать раньше, какой контекст был потерян.
8. Назначить владельца процесса. Observability — это процесс, у которого должен быть ответственный. В его задачи входят регулярный пересмотр алертов, адаптация SLO с учетом изменений бизнеса и введение общих принципов для всех команд.
1. Определить норму. Выявить 3−5 критических пользовательских сценариев (авторизация, оформление заказа, поиск) и сформулировать SLO: например, «99,9% запросов выполняются быстрее 300 мс».
2. Ввести SLI/SLO. Без них алерты не будут связаны между собой. Начинать стоит с простого SLO и корректировать его на основе реального опыта.
3. Стандартизировать сбор данных. Единый формат логов (JSON), единая система наименования метрик, использование OpenTelemetry для трассировок — иначе данные из разных сервисов будет невозможно сопоставить.
4. Построить базовую «тройку»: метрики (RED/Golden Signals: rate, errors, duration), трассировки (end-to-end сквозные, с разумным sampling), структурированные логи с балансом между длительностью хранения и стоимостью.
5. Сделать алерт точкой входа в observability. Хороший алерт основан на SLO, содержит данные о том, что сломалось, кого затронуло, а также включает ссылки на дашборд и проблемную трассировку. Если алерт нельзя расследовать за 2−3 клика, он неэффективен.
6. Встроить observability в процесс релизов. Каждый деплой — потенциальный инцидент. Сравнение метрик до и после релиза должно стать стандартной практикой.
7. Использовать инциденты для улучшения. После каждого инцидента — аудит: каких сигналов не хватало, какой алерт должен был сработать раньше, какой контекст был потерян.
8. Назначить владельца процесса. Observability — это процесс, у которого должен быть ответственный. В его задачи входят регулярный пересмотр алертов, адаптация SLO с учетом изменений бизнеса и введение общих принципов для всех команд.
«Графиня» как инструмент визуализации в observability-стеке
При построении observability-стека важен вопрос инструментария, особенно в условиях импортозамещения. Среди открытых решений широко применяются Prometheus или Zabbix (сбор и хранение метрик), Grafana (визуализация и алертинг), Loki (агрегация логов), Tempo и Jaeger (трассировки), OpenTelemetry (стандарт сбора и передачи телеметрии).
Из российских коммерческих продуктов заметное место занимает «Графиня» — платформа для сбора, мониторинга и визуализации данных, разработанная «Лабораторией Числитель». «Графиня» предназначена для построения фундамента полноценного observability-стека: работа с метриками, логами и дашбордами в едином интерфейсе. Это особенно актуально для компаний, которым необходимо хранить данные телеметрии внутри российского периметра.
Комплексный подход реализует и «Пульт» — система мониторинга ИТ-инфраструктуры от «Лаборатории Числитель». Вместе «Пульт» и «Графиня» образуют связку «мониторинг + observability», закрывая потребности как в обнаружении инцидентов, так и в анализе их причин.
Из российских коммерческих продуктов заметное место занимает «Графиня» — платформа для сбора, мониторинга и визуализации данных, разработанная «Лабораторией Числитель». «Графиня» предназначена для построения фундамента полноценного observability-стека: работа с метриками, логами и дашбордами в едином интерфейсе. Это особенно актуально для компаний, которым необходимо хранить данные телеметрии внутри российского периметра.
Комплексный подход реализует и «Пульт» — система мониторинга ИТ-инфраструктуры от «Лаборатории Числитель». Вместе «Пульт» и «Графиня» образуют связку «мониторинг + observability», закрывая потребности как в обнаружении инцидентов, так и в анализе их причин.
Итоги
Мониторинг в контексте современной ИТ-инфраструктуры становится необходимым фундаментом, который обеспечивает быстрые сигналы об угрозе, алерты и автоматические реакции. Без него невозможно вовремя узнать о существовании проблемы. Но без наблюдаемости невозможно понять, как её решить. Поэтому она и становится логическим продолжением мониторинга, предоставляя глубокий и взаимосвязанный контекст из метрик, логов и трассировок.
DevOps-командам, работающим с микросервисами и распределёнными системами, обе практики необходимы одновременно. Зрелость подхода определяется не количеством инструментов, а качеством процессов: чёткими SLO, работающей матрицей эскалации, стандартизированным сбором телеметрии и культурой использования инцидентов для улучшения системы.
Observability — это инвестиция, которая окупается снижением MTTR, уменьшением нагрузки на on-call-инженеров и повышением надёжности сервисов. И в конечном итоге влияет на доверие пользователей.
DevOps-командам, работающим с микросервисами и распределёнными системами, обе практики необходимы одновременно. Зрелость подхода определяется не количеством инструментов, а качеством процессов: чёткими SLO, работающей матрицей эскалации, стандартизированным сбором телеметрии и культурой использования инцидентов для улучшения системы.
Observability — это инвестиция, которая окупается снижением MTTR, уменьшением нагрузки на on-call-инженеров и повышением надёжности сервисов. И в конечном итоге влияет на доверие пользователей.
