Статья от начала декабря на Хабре о том, как ИТ-Град создавал объединенную систему мониторинга как услугу для облачных сервисов МТС, собственного IaaS и инфраструктуры 1cloud. Это типа всё объединилось.
Пишут:
В результате трансформации основными требованиями стали:
- система мониторинга должна работать не только на ИТ-ГРАД, но и стать внутренним сервисом для «Объединенного облачного провайдера» и услугой для заказчиков.
- требовалось решение, которое будет собирать статистику со всей IT-инфраструктуры.
- так как систем много, все события мониторинга должны сходиться в едином агрегаторе данных, где события и триггеры сверяются с единой CMDB и при необходимости происходит автоматическое оповещение пользователей.
В цитате выше смотреть нужно на 3 пункт. CMDB — полезная штука для сервисных провайдеров (и всех остальных). События/инциденты обогащаются данными оттуда и сразу видно какой заказчик, где оборудование, когда инсталлировано и т.д. Но в статье нет ничего про связи между КЕ (конфигурационными единицами). А наличие связей — очень большое преимущество. Если они есть, в инциденте можно сразу же показать соседние устройства.
Если к системе мониторинга прикрутить автоматизацию, то, до генерации события/инцидента эти соседние устройства можно пропинговать (или собрать любую другую статистику) и приложить к инциденту/событию. Получится некая первичная диагностика. Конечно, можно прикрутить и какие-то другие проверки. Вы удивитесь насколько быстрее будут решаться инциденты. Надеюсь, те ребята уже идут по этому пути.
Следующий момент. Обратите внимание на прилепленную к этому посту схему. Данные мониторинга собираются 4 различными системами — это 4 источника событий. В статье не сказано как в такой ситуации ведётся работа с шумовыми событиями. Но эту работу вести надо, иначе заказчики через некоторое время перестанут доверять такой системе мониторинга.
А теперь гипотетическая часть. Как там на самом деле я не знаю, но потеоретизирую. SCOM здесь, скорее всего, используется для серверов на Windows, а Zabbix для Unix. vCenter это, возможно, на самом деле система мониторинга vRealize. СХД может быть какими-то вендорскими схдешными решениями мониторинга. Очевидно, что часть Unix и Windows машин виртуализировано, следовательно, события по серверам приходят сразу из трёх систем мониторинга: SCOM, Zabbix, vRealize (vCenter). По СХД события приходят их двух источников: СХД и vRealize (vCenter). Вывод: шумовые события есть, их не может не быть.
Снижение количества шумовых событий отдельная и трудоёмкая задача. Здесь многое зависит от используемого стека систем мониторинга и сервис-деска. Можно почитать об этом коротку статью на Медиуме. Думаю, с этим тоже ведётся определённая работа.
Пишут:
В результате трансформации основными требованиями стали:
- система мониторинга должна работать не только на ИТ-ГРАД, но и стать внутренним сервисом для «Объединенного облачного провайдера» и услугой для заказчиков.
- требовалось решение, которое будет собирать статистику со всей IT-инфраструктуры.
- так как систем много, все события мониторинга должны сходиться в едином агрегаторе данных, где события и триггеры сверяются с единой CMDB и при необходимости происходит автоматическое оповещение пользователей.
В цитате выше смотреть нужно на 3 пункт. CMDB — полезная штука для сервисных провайдеров (и всех остальных). События/инциденты обогащаются данными оттуда и сразу видно какой заказчик, где оборудование, когда инсталлировано и т.д. Но в статье нет ничего про связи между КЕ (конфигурационными единицами). А наличие связей — очень большое преимущество. Если они есть, в инциденте можно сразу же показать соседние устройства.
Если к системе мониторинга прикрутить автоматизацию, то, до генерации события/инцидента эти соседние устройства можно пропинговать (или собрать любую другую статистику) и приложить к инциденту/событию. Получится некая первичная диагностика. Конечно, можно прикрутить и какие-то другие проверки. Вы удивитесь насколько быстрее будут решаться инциденты. Надеюсь, те ребята уже идут по этому пути.
Следующий момент. Обратите внимание на прилепленную к этому посту схему. Данные мониторинга собираются 4 различными системами — это 4 источника событий. В статье не сказано как в такой ситуации ведётся работа с шумовыми событиями. Но эту работу вести надо, иначе заказчики через некоторое время перестанут доверять такой системе мониторинга.
А теперь гипотетическая часть. Как там на самом деле я не знаю, но потеоретизирую. SCOM здесь, скорее всего, используется для серверов на Windows, а Zabbix для Unix. vCenter это, возможно, на самом деле система мониторинга vRealize. СХД может быть какими-то вендорскими схдешными решениями мониторинга. Очевидно, что часть Unix и Windows машин виртуализировано, следовательно, события по серверам приходят сразу из трёх систем мониторинга: SCOM, Zabbix, vRealize (vCenter). По СХД события приходят их двух источников: СХД и vRealize (vCenter). Вывод: шумовые события есть, их не может не быть.
Снижение количества шумовых событий отдельная и трудоёмкая задача. Здесь многое зависит от используемого стека систем мониторинга и сервис-деска. Можно почитать об этом коротку статью на Медиуме. Думаю, с этим тоже ведётся определённая работа.