От мониторинга к observability: смена концепции

5

Антон Новоженин, Технический директор GMONIT

Автор: Антон Новоженин, Технический директор GMONIT

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

В мире, где технологии развиваются с невероятной скоростью, требования пользователей к качеству и надежности ИТ-систем также неуклонно растут. Это неизбежно ведет к усложнению архитектуры и функциональности самих систем. Ранее эффективные методы мониторинга, нацеленные на отслеживание стандартных показателей, таких как время отклика или процент ошибок в запросах, теперь оказываются недостаточными. Ведь в условиях растущего множества взаимосвязей и зависимостей ключевым фактором становится не только «работает ли система?», но и «как хорошо она работает в различных сценариях использования?».

Такая динамика порождает потребность в глубоком понимании внутреннего устройства и взаимосвязей ИТ-систем. Теперь перед SRE (Site Reliability Engineering) и инженерами поддержки стоит задача не просто отслеживать факт доступности системы для пользователей, но и оценивать качество ее работы в комплексе. Таким образом, фокус сместился от классического мониторинга к observability – способности не только фиксировать проблемы, но и понимать их причины, а также предвидеть потенциальные трудности, опираясь на анализ данных. Чем же конкретно отличаются концепции? Разберемся далее.

Традиционный Мониторинг

Традиционные системы мониторинга основываются на методике сбора метрик с помощью заранее настроенных «датчиков». В определенные участки системы интегрируются специальные агенты или «экспортеры», которые либо инициируют отправку метрик через заданные временные интервалы, либо передают эти метрики в ответ на запросы от сервера мониторинга, реализуя таким образом push и pull модели. Этот подход отличается относительной простотой внедрения и способен охватывать разнообразные аспекты работы систем, включая потребление ресурсов сервером (CPU, IO, RAM и т.д.), показатели эффективности приложений (через ручную разметку кода), а также характеристики работы баз данных и шин сообщений. Кроме того, традиционные системы мониторинга часто оснащены гибкими и функциональными инструментами для оповещения о проблемах и сбоях, базирующихся на статических бейзлайнах и предопределенных условиях.

Но несмотря на свою эффективность в определенных сценариях, традиционный подход к мониторингу ИТ-систем имеет ряд ограничений, которые становятся особенно заметными в условиях современного технологического ландшафта. Одним из ключевых недостатков является его фокусировка на инфраструктурных метриках, что может не давать полной картины состояния сложных систем. Так, традиционный мониторинг часто игнорирует более глубокий анализ производительности сервисов и их взаимосвязей, пользовательского опыта и бизнес-процессов, что критически важно для современных приложений. Кроме того, в условиях быстро меняющихся технологий и повышенной динамики бизнес-требований, статические пороги и правила мониторинга могут быстро устаревать, требуя постоянной ревизии и адаптации. Это создает дополнительную нагрузку на ИТ-отделы и может привести к задержкам в выявлении и решении проблем. В эпоху, когда отказы и сбои в работе систем могут иметь серьезные последствия для бизнеса, подходы, основанные только на традиционном мониторинге, уже не могут полностью обеспечить требуемый уровень качества и надежности. Это подчеркивает необходимость перехода к более комплексным и продвинутым методам наблюдения за системами, способным адаптироваться к изменяющимся условиям и предоставлять более глубокое понимание работы ИТ-инфраструктуры.

Мониторинг Производительности Приложений (APM)

Application Performance Management (APM) представляет собой подход, преодолевающий недостатки традиционных систем мониторинга. В отличие от классических методов, ориентированных на инфраструктурные показатели, APM фокусируется на производительности и здоровье приложений с учетом пользовательского опыта. Это достигается за счет глубокого анализа транзакций, отслеживания ошибок, измерения времени отклика и мониторинга пользовательских сессий. APM интегрируется непосредственно в приложения (в основном через автоинструментацию кода), предоставляя более детализированное понимание их работы на уровне кода и позволяя быстро выявлять и устранять узкие места в производительности. Таким образом, APM не просто мониторит состояние системы, но и позволяет оптимизировать ее работу.

Хотя APM является мощным инструментом для улучшения производительности и стабильности приложений, у него есть свои недостатки. Основная проблема заключается в том, что APM сфокусирован преимущественно на производительности отдельных сервисов или приложений, а не на системе в целом. Это может привести к тому, что слабые места на уровне всей архитектуры или во взаимодействии между различными сервисами останутся без внимания. А это для сложных современных систем зачастую является главным источником проблем. Рассмотрим, чем же отличаются между собой подходы.

Наблюдаемость

Наблюдаемость (observability) – это свойство системы, позволяющее понимать ее внутреннее состояние на основе внешних выходных данных. В отличие от APM, которое фокусируется на производительности конкретных сервисов, наблюдаемость обеспечивает более глобальный и интегрированный взгляд на всю ИТ-инфраструктуру. Это достигается за счет анализа трех ключевых типов данных: логов, метрик и трассировок. Этот подход позволяет не только обнаруживать и диагностировать проблемы, но и понимать их причины и контекст, а также предсказывать потенциальные неполадки до того, как они проявятся. Наблюдаемость обеспечивает комплексное представление о работе системы, позволяя специалистам оценивать взаимодействие между различными компонентами и быстро находить корневые причины проблем. Таким образом, она решает ограничения APM, связанные с фокусировкой только на отдельных сервисах, и предлагает более глубокое и всестороннее понимание работы всей ИТ-системы.

Несмотря на свои многочисленные преимущества, подход наблюдаемости также имеет свои ограничения. Одним из ключевых недостатков является отсутствие возможности глубокого анализа работы конкретного приложения на уровне кода, что является сильной стороной APM. Когда дело доходит до детального анализа производительности или поиска ошибок в коде отдельных приложений, наблюдаемость может не предоставлять такого уровня детализации и специфичности, как APM. Это может означать, что в некоторых случаях для полного понимания и решения проблем на уровне приложений потребуется дополнительный анализ или интеграция с другими инструментами, специализированными на производительности приложений.

Интеграция и синергия

Традиционный мониторинг, APM и наблюдаемость, хотя и имеют свои уникальные характеристики и ограничения, могут эффективно дополнять друг друга, создавая комплексную систему управления производительностью и надежностью ИТ-инфраструктур. Традиционный мониторинг служит надежной основой для отслеживания фундаментальных показателей инфраструктуры, таких как производительность серверов и сетевых устройств. APM вносит в эту систему глубокий анализ работы приложений, обеспечивая детальное понимание производительности на уровне кода и пользовательского опыта. Наблюдаемость, в свою очередь, расширяет эти возможности, предоставляя более широкий контекст и понимание всей системы, что включает в себя взаимодействие между различными компонентами и услугами. В совокупности, эти подходы позволяют организациям получить полное представление о состоянии их ИТ-среды, оптимизировать ее работу и своевременно реагировать на любые проблемы, тем самым повышая общую эффективность и надежность системы.

Заключение

Переход к наблюдаемости систем – это лишь начало пути в эволюции подходов к мониторингу и анализу работы ИТ-инфраструктур. Нынешние реалии и возрастающая сложность систем стимулируют разработку и внедрение новых инструментов, основанных на прогрессивных технологиях, таких как искусственный интеллект (ИИ) и машинное обучение. Эти технологии играют решающую роль в предсказании потенциальных сбоев, анализе больших объемов данных и нахождении неочевидных корреляций. Использование ИИ для автоматизации и оптимизации процессов мониторинга позволяет не только своевременно реагировать на проблемы, но и предвидеть их, минимизируя возможные негативные последствия.

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

Отдельно можно выделить класс задач по переосмыслению подходов к совместной работе над устранением инцидентов и анализом их причин. Сейчас команды вынуждены постоянно переключаться между различными инструментами (дашборды, чаты, системы учета задач и т.д.), часто теряя контекст или оперативность в обмене информацией и принятии решений. А это в свою очередь ведет к увеличению времени расследования инцидентов и как следствие, к длительным простоям систем.

Все эти тенденции задают вектор развития современных систем мониторинга. Ведь со временем ИТ-системы становятся более интегрированными, многоуровневыми и динамичными. А следовательно, для поддержания высокого уровня сервиса и удовлетворения возрастающих ожиданий пользователей, подходы к мониторингу должны адаптироваться, чтобы быть на шаг впереди этих изменений.

761
Коментарии: 5

Комментировать могут только авторизованные пользователи.
Предлагаем Вам в систему или зарегистрироваться.

  • Андрей Семёнов
    Рейтинг: 12
    Клуб ИТ директоров Тюменской области
    Председатель правления клуба
    30.09.2025 17:24

    Простите, но похоже, что в статье завуалировано рассматривается вопрос как решить задачу некорректного планирования архитектуры и своевремной амортизации онного... :-)
    Не правильнее ли решать корневые проблемы, чем пытаться придумывать костыль в виде "наблюдаемости систем"?!

  • Екатерина Ляско
    Рейтинг: 989
    Global CIO
    Генеральный директор
    01.10.2025 11:05

    Андрей, спасибо за вопрос. Спросим у автора его точку зрения

    • Андрей Семёнов Екатерина
      Рейтинг: 12
      Клуб ИТ директоров Тюменской области
      Председатель правления клуба
      01.10.2025 17:02

      Спасибо!

  • Елена Аверьянова
    Рейтинг: 371
    АО GlobalCIO
    Редактор
    01.10.2025 17:59

    Отвечает автор, Антон Новоженин, Технический директор GMONIT:

    Спасибо за комментарий!
    Вы абсолютно правы в том, что архитектурные ошибки никакая «наблюдаемость» сама по себе не исправит.

    Но если смотреть шире, то в реальности мы редко имеем идеальные условия: системы эволюционируют, бизнес-требования меняются быстрее, чем успевают адаптироваться архитектурные решения. В таких условиях observability - не «костыль», а инструмент управления рисками. Она позволяет:
    • раньше замечать деградации и аномалии,
    • подтверждать или опровергать гипотезы о поведении системы,
    • принимать обоснованные решения о том, где именно «корень зла» и стоит ли инвестировать в рефакторинг.

    По сути, наблюдаемость помогает как раз добраться до первопричин и не тратить ресурсы вслепую. А грамотное сочетание архитектурной гигиены и observability даёт максимальный эффект.

  • Андрей Семёнов
    Рейтинг: 12
    Клуб ИТ директоров Тюменской области
    Председатель правления клуба
    02.10.2025 18:44

    Спасибо!

    Но всё же я склонен считать, что корректнее быть честным с задачами бизнеса. Бизнес строит планы, ИКТ строит поддержку этих планов, не только ИТ-решениями, но и экономикой, так честно, для качественной поддекржки бизнеса через ИКТ-сервисы требуется вот столько. Мониторить конечно нужно и копать в первопричины конечно правильно и даже причины будут найдены, но что уже после драки махать кулаками?! Когда уже всё случилось (потрачено или не потрачено)!

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

Предметная область
Отрасль
Управление
Мы используем файлы cookie в аналитических целях и для того, чтобы обеспечить вам наилучшие впечатления от работы с нашим сайтом. Заходя на сайт, вы соглашаетесь с Политикой использования файлов cookie.