Мониторинг давно перестал быть просто проверкой состояния серверов — в сложной современной инфраструктуре он должен показывать взаимосвязи и реальные причины сбоев, влияющих на бизнес. В тексте IT-World на примерах показано, как централизованный анализ и визуализация помогают быстрее находить и устранять инциденты. Отдельное внимание уделено роли ситуационных центров и LED-экранов, которые делают инфраструктуру по-настоящему «видимой» для всей команды.
Почему мониторинг уже давно не про серверы
Обычно разговор с заказчиками о мониторинге начинается с простой жалобы: пользователи говорят, что система тормозит. Инженеры запускают систему мониторинга и… видят вполне приличную картину: серверы живы, база отвечает, сеть вроде бы не падает, ничего аварийного нет. Но работа приложений при этом медленная, пользователи нервничают, увеличилась нагрузка на хранилище, а в производственной системе появилась серия ошибок.
И вот тут становится понятно, что привычная логика “сервер жив — значит всё нормально” перестала работать. Когда-то это было действительно так, но и инфраструктура была проще: несколько серверов, сеть, пара ключевых сервисов. Проверили доступность, посмотрели загрузку, убедились, что ничего не упало — на этом диагностика часто заканчивалась.
Сегодня всё устроено иначе. Даже в компании среднего масштаба инфраструктура — это довольно сложный клубок систем. Планирование ресурсов предприятия (ERP), система управления взаимоотношениями с клиентами (CRM), прикладные сервисы, сеть, системы хранения, безопасность, иногда ещё телеметрия оборудования или видеонаблюдение. Каждая из этих систем живёт своей жизнью, но при этом постоянно зависит от других. И каждая генерирует события.
На первый взгляд это хорошо, так как больше информации подразумевает, что будет легче разобраться. Но на практике всё выходит наоборот, потому что данные лежат в разных местах. В итоге инженер смотрит на поток предупреждений и отклонений, но не всегда может быстро ответить на самый простой вопрос, что именно стало причиной проблемы. А в чем проблема — как раз то, что интересует бизнес.
Современный сбой редко выглядит как классическая авария, когда что-то одно сломалось и всё остановилось. Гораздо чаще это цепочка: где-то выросла задержка в сети; где-то хранилище начало отвечать медленнее; где-то сервис перестал отвечать. В итоге пользователь делает вывод — система работает плохо.
Приведу пример. В одном из наших проектов в научно-исследовательской сфере был создан вычислительный комплекс на базе Ceph-кластера с использованием отечественного оборудования и системы мониторинга собственной разработки. Инфраструктура предназначалась для хранения и обработки больших массивов научных данных, а также для выполнения высокопроизводительных вычислений (HPC).
В системе мониторинга отслеживалось состояние ключевых компонентов комплекса: загрузка вычислительных узлов, состояние хранилища Ceph, параметры сети и показатели выполнения вычислительных задач. Контроль осуществлялся по нескольким направлениям: вычислительные ресурсы, система хранения данных, сеть и системные метрики выполнения задач.
В процессе эксплуатации при запуске ресурсоёмкого расчёта произошла деградация производительности: часть вычислительных узлов оказалась перегружена, что привело к увеличению времени выполнения задач. Система мониторинга зафиксировала рост загрузки ЦПУ и дисковой подсистемы, а также увеличение времени отклика при обращении к хранилищу, после чего автоматически сформировала критическое событие.
При анализе инцидента мы выявили превышение допустимой загрузки на ряде вычислительных узлов, сопровождавшееся ростом задержек операций чтения и записи в системе хранения и увеличением времени выполнения вычислительных задач. При этом была установлена прямая связь между нагрузкой на вычислительные ресурсы и снижением производительности Ceph-кластера.
Централизованный мониторинг вывел всю информацию одновременно всем участникам процесса: инженеры инфраструктуры увидели перегруженные серверы, специалисты по системам хранения — влияние нагрузки на Ceph-кластер, а операторы HPC — снижение эффективности выполнения задач.
Это позволило оперативно принять решение: нагрузка была перераспределена между узлами, а часть задач перенаправлена на менее загруженные ресурсы. Как следствие, показатели производительности быстро стабилизировались — время выполнения задач сократилось, а параметры системы хранения вернулись в допустимые значения.
Руководитель смены в режиме реального времени зафиксировал, что инцидент локализован и не привёл к срыву выполнения вычислительных задач и потере данных.
Отследить такую реальную историю по отдельным оповещениям мониторинга — занятие утомительное. Нужно не просто видеть события, а понимать, как они связаны между собой, где началась проблема и как она распространилась, почему локальный технический сбой в итоге стал проблемой для бизнес-сервиса. Сначала нужно собрать данные из разных источников, привести их к единому виду, а потом ещё и связать между собой. Чтобы оповещения системы мониторинга не создавали для инженеров шум, а помогали разобраться в проблеме, нужно понять:
- какие данные действительно важны,
- какие зависимости между системами критичны,
- какие сигналы требуют реакции,
- а какие только засоряют картину.
Когда всё это сделано, мониторинг начинает работать совсем по-другому. Появляется возможность быстрее находить первопричины инцидентов, сокращать время простоя и в целом лучше понимать, как инфраструктурные проблемы влияют на бизнес-сервисы.
Но тут возникает ещё один практический вопрос. Даже если данные собраны, события связаны между собой, причины понятны — как всё это показать так, чтобы сотрудник действительно мог быстро разобраться?
И здесь начинается следующая история — про визуализацию. Не как красивую картинку для отчёта, а как инструмент, который помогает быстрее увидеть проблему.
Когда инфраструктура становится видимой
Современные системы мониторинга строятся как многоуровневая архитектура обработки данных. На входе находятся источники событий: сетевые устройства, серверы, системы хранения данных, бизнес-приложения, промышленные контроллеры и датчики. Потоки событий поступают в слой сбора, где данные принимаются, буферизуются и приводятся к единому формату.
Далее начинается самая интересная часть — потоковая аналитика. Здесь система сопоставляет события из разных источников, выявляет взаимосвязи и ищет аномалии. В результате отдельные логи и метрики превращаются в связанную картину происходящего в инфраструктуре. В аналитическом контуре формируются исторические выборки, рассчитываются уровень качества предоставления услуг (SLA) и ключевые показатели эффективности (KPI), строятся тренды и прогнозы.
Но даже самая мощная аналитика не приносит пользы, если она остается скрытой в технических интерфейсах, поэтому финальным уровнем современной архитектуры становится визуализация.
Во многих компаниях для этого создаются ситуационные центры — пространства, где состояние инфраструктуры отображается на больших информационных экранах. Здесь инженеры и руководители могут видеть происходящее в системе в режиме реального времени. Именно в таких центрах всё чаще используются LED-видеостены.
В отличие от традиционных видеостен из отдельных дисплеев, LED-экраны формируют единое бесшовное изображение. Они обладают высокой яркостью и контрастностью, хорошо читаются даже при ярком освещении. Благодаря этому их можно устанавливать в операционных залах, диспетчерских и ситуационных центрах без затемнения помещений. На таких экранах отображается состояние всей инфраструктуры предприятия. Здесь можно одновременно видеть загрузку серверов, состояние сетей, показатели бизнес-процессов и критические инциденты.
Когда происходит сбой, информация о нем сразу появляется на экране ситуационного центра. Это позволяет инженерам быстрее реагировать на проблемы, а руководителям — понимать, что происходит в инфраструктуре.
По сути, LED-экран становится частью системы управления. Расскажу из опыта. В финтех-компании LED-экран был установлен в Ситуационном центре. Круглосуточно отслеживалось состояние ключевых цифровых сервисов банка. На экран выводились информационные панели из систем мониторинга: состояние вычислительных кластеров, сетевых узлов, статус микросервисов интернет-банка и показатели транзакционных систем. Экран был разделён на несколько зон: инфраструктура (серверы и виртуализация), сеть, прикладные системы и бизнес-метрики — количество обрабатываемых платежей в секунду.
В часы пиковой нагрузки произошёл сбой в системе обработки карточных транзакций: один из сервисов авторизации начал отвечать с задержкой, из-за чего увеличилось время обработки платежей. Система мониторинга зафиксировала рост латентности и автоматически сформировала оповещение о критической ситуации (crit-sit).
Оповещение появилось на LED-экране ситуационного центра:
- в зоне прикладных сервисов загорелся красный индикатор статуса сервиса авторизации;
- на графике транзакционной системы стало видно падение количества успешно обработанных операций;
- одновременно отобразилась корреляция с ростом загрузки одного из серверных узлов.
Благодаря большому бесшовному LED-экрану вся эта информация была видна одновременно всей команде: инженеры инфраструктуры увидели перегруженный узел, специалисты по приложению — деградацию конкретного микросервиса, а дежурный менеджер — влияние на бизнес-метрику платежей.
Таким образом, удалось быстро принять решение: инженеры перераспределили нагрузку на резервный кластер, после чего показатели транзакций на экране вернулись в норму. Руководитель смены в тот же момент видел на общем экране, что инцидент локализован и не перерос в массовый отказ платежных сервисов.
Важно понимать: сама по себе установка экранов не решает задачу. Чтобы визуализация действительно работала, она должна быть интегрирована с системой мониторинга и аналитики. Когда данные начинают отображаться таким образом, мониторинг меняет своё значение. Он перестает быть инструментом для инженеров и становится частью операционного управления.
И в этот момент инфраструктура предприятия впервые становится по-настоящему видимой.