Во многих инфраструктурах система мониторинга воспринимается как вспомогательный сервис. Основное внимание обычно уделяется отказоустойчивости серверов, сетевого оборудования, СХД и виртуализации, тогда как сам мониторинг часто разворачивается по остаточному принципу: один сервер, один канал связи, одно хранилище событий и единая точка питания.
Проблема становится заметной во время аварий. Именно в этот момент мониторинг оказывается недоступен одновременно с инфраструктурой, которую должен контролировать. В результате организация теряет не только часть сервисов, но и возможность быстро понять масштаб инцидента, последовательность событий и первопричину отказа.
Особенно критично это для распределённых объектов, инженерной инфраструктуры, серверных и ЦОД, где потеря телеметрии во время аварии существенно усложняет диагностику.
Что такое единая точка отказа в мониторинге
Единая точка отказа возникает в ситуации, когда критически важный компонент системы мониторинга существует в единственном экземпляре и его отказ делает недоступной всю систему наблюдаемости.
На практике подобные проблемы чаще всего возникают не из-за сложных программных ошибок, а из-за архитектурных решений. Например, сервер мониторинга может располагаться внутри того же кластера виртуализации, который он контролирует. При сбое гипервизора одновременно теряются и рабочие сервисы, и сам мониторинг.
Аналогичная ситуация возникает, когда система мониторинга зависит от единственного коммутатора, одного канала связи или общего PDU вместе с контролируемой инфраструктурой. В такой архитектуре отказ одного элемента способен полностью лишить персонал телеметрии и механизмов оповещения.
Во многих инфраструктурах подобные зависимости становятся заметны только после первого серьёзного инцидента.
Типичные ошибки при проектировании
Одной из наиболее распространённых ошибок является размещение системы мониторинга внутри контролируемой инфраструктуры без какого-либо независимого контура.
Например, сервер мониторинга, syslog и база данных метрик могут находиться внутри одной системы виртуализации. В случае проблем с гипервизором организация одновременно теряет и рабочие сервисы, и всю диагностическую инфраструктуру.
Другой частый сценарий — отсутствие независимого питания. Если сервер мониторинга, коммутаторы и контролируемое оборудование подключены к одному PDU или ИБП, авария питания может полностью сделать систему мониторинга бесполезной именно в момент возникновения инцидента.
Проблемы также возникают при использовании единственного канала уведомлений. Email-оповещения часто перестают работать при отказе интернет-канала, DNS или почтовой инфраструктуры. Формально система мониторинга продолжает функционировать, однако уведомления до персонала уже не доходят.
Отдельную проблему создаёт отсутствие out-of-band доступа. Во многих инфраструктурах мониторинг полностью зависит от основной производственной сети. При аварии маршрутизации или отказе ядра сети система теряет связь со всеми площадками одновременно.
Рис. 1. Пример архитектуры мониторинга с единой точкой отказа
Почему мониторинг часто перестаёт работать первым
Во многих авариях система мониторинга начинает деградировать раньше основной инфраструктуры. Причина заключается в высокой концентрации зависимостей.
Мониторинг одновременно зависит от сетевой инфраструктуры, DNS, синхронизации времени, баз данных, систем хранения, виртуализации и каналов уведомлений. Даже частичная деградация одного из этих компонентов способна вызвать цепную реакцию.
Например, после отказа гипервизора администратор может потерять не только виртуальные машины, но и сам сервер мониторинга, syslog и систему уведомлений. В результате персонал остаётся без телеметрии именно в момент максимальной деградации инфраструктуры.
Не менее опасны ситуации, когда мониторинг продолжает работать формально, но перестаёт выполнять свою основную задачу. Переполнение хранилища метрик может остановить запись новых событий, потеря NTP — сделать недостоверной временную корреляцию, а деградация DNS — нарушить отправку уведомлений и работу интеграций.
Особенно тяжёлые последствия возникают при лавинообразном росте событий во время аварии. Система мониторинга оказывается перегружена потоком новых данных, перестаёт успевать обрабатывать события и начинает терять часть телеметрии.
Ложная отказоустойчивость
Во многих инфраструктурах система мониторинга выглядит отказоустойчивой только формально.
Например, организация может использовать резервный сервер мониторинга, однако оба узла будут подключены к одному коммутатору или одному PDU. Аналогично резервный канал уведомлений может проходить через тот же маршрутизатор или интернет-провайдера, что и основной.
Похожая ситуация возникает при использовании GSM-уведомлений без резервного питания. После отключения основного электропитания модем и контроллер перестают работать одновременно с инфраструктурой, которую должны контролировать.
Подобная архитектура создаёт иллюзию резервирования, но не обеспечивает реальной устойчивости во время аварии.
Практический подход к отказоустойчивости
Отказоустойчивость мониторинга не всегда требует сложных кластерных решений. Во многих случаях значительно важнее уменьшить количество общих зависимостей и разделить критичные компоненты.
Практический подход обычно строится вокруг независимого питания, отдельного сегмента управления и резервных каналов уведомлений. Особенно важны аварийные каналы связи, которые продолжают работать даже при полной потере основной сети или интернет-доступа.
В распределённых инфраструктурах полезным оказывается локальное буферизирование событий. Даже если связь с центральным сервером временно потеряна, данные продолжают сохраняться и передаются после восстановления соединения.
Существенную роль играет и централизованное хранение журналов. События инженерной инфраструктуры, переключения питания, потеря связи и аварийные уведомления должны сохраняться независимо от состояния основной системы мониторинга.
Что действительно стоит резервировать
При проектировании мониторинга важно понимать, что резервирование всех компонентов одинаково нецелесообразно.
В большинстве аварий критически важными оказываются доставка уведомлений, сохранность событий, доступ к актуальной телеметрии и корректная временная шкала. При этом потеря части исторических графиков или временная недоступность аналитических отчётов обычно значительно менее критична.
По этой причине в инженерной инфраструктуре часто важнее обеспечить независимый канал аварийных уведомлений, резервирование хранения событий и автономную работу контроллеров, чем строить сложные схемы высокодоступных дашбордов.
Именно эти компоненты определяют, сможет ли организация восстановить реальную картину инцидента после аварии.
Практический пример отказоустойчивой архитектуры
Практическая архитектура отказоустойчивого мониторинга обычно строится по принципу разделения зон ответственности.
Система мониторинга размещается отдельно от основной производственной инфраструктуры и использует независимый сегмент управления. Критичные устройства подключаются через отдельные коммутаторы или out-of-band сеть. Уведомления отправляются одновременно через несколько каналов, например Email и GSM.
События инженерной инфраструктуры централизованно сохраняются на сервере журналов или SIEM-платформе, а распределённые контроллеры продолжают локальную работу даже при потере связи с центральной системой.
Подобный подход позволяет сохранить наблюдаемость инфраструктуры даже во время серьёзных аварий.
Рис. 2. Пример отказоустойчивой архитектуры системы мониторинга
Что происходит во время реальной аварии
Практическая ценность отказоустойчивого мониторинга особенно заметна во время комплексных аварий.
Например, при потере основного питания часть серверов и сетевого оборудования может оказаться недоступна. Однако система мониторинга продолжает работать за счёт резервного питания, отдельного сегмента управления и независимого канала уведомлений.
В результате персонал продолжает получать уведомления о состоянии ИБП, события переключения питания, данные датчиков температуры и информацию о недоступности оборудования даже во время серьёзной деградации инфраструктуры.
Без подобной архитектуры организация одновременно теряет и инфраструктуру, и возможность понять, что именно произошло.
Система мониторинга должна проектироваться как самостоятельная отказоустойчивая инфраструктура, а не как второстепенный сервис внутри основной среды.
Во многих случаях именно мониторинг становится единственным источником информации о развитии аварии, последовательности событий и причинах отказа. Если система мониторинга выходит из строя одновременно с основной инфраструктурой, организация теряет возможность быстро локализовать проблему и восстановить картину инцидента.
При проектировании мониторинга особенно важно минимизировать количество общих зависимостей, резервировать критичные компоненты и заранее предусматривать сценарии деградации инфраструктуры.
Именно способность продолжать работу во время аварии определяет реальную ценность системы мониторинга.
Для подбора оборудования, проектирования систем мониторинга и построения отказоустойчивой инженерной инфраструктуры можно обратиться к специалистам «Алентис Электроникс».
Отдел продаж: sales@alentis.ru
Pre-sale-консультации: pre-sales@alentis.ru
Техническая поддержка: support@netping.ru