Привет, Хабр! Эту статью пишет авторский коллектив центра экспертизы по комплексному сервису К2Тех: я, Пётр Михнюк, руководитель группы инженеров по поддержке системного ПО, и мои коллеги Александр Овчинников, старший инженер по поддержке вычислительного оборудования, и Алексей Яковлев, эксперт по мониторингу ИТ-инфраструктуры и приложений. У нас на поддержке около 550 клиентов из сегмента enterprise, многие с географически распределенной инфраструктурой, и практически все они так или иначе опираются на Zabbix или его наследников.​

По нашему опыту, главная угроза для эффективного мониторинга — иллюзия контроля. Часто бывает так, что система развернута, графики рисуются, алерты шлются, но команда тонет в сотнях уведомлений и не успевает ловить действительно важные события: вместо одного «критического инцидента» получаются десятки разрозненных тикетов. При этом проблемы с лавиной оповещений, тарированием порогов и общей логикой мониторинга почти не зависят от того, используете ли вы «голый» Zabbix или его форки вроде «Пульт», Glaber или UDV ITM. Учитывая, что в большинстве случаев «наследием» наших клиентов является именно Zabbix, мы будем опираться на конкретные примеры из работы с ним. Под катом не теория, а наши подходы и примеры: как перестать тонуть в алертах и превратить Zabbix в инструмент, которому можно доверять.

Почему Zabbix «из коробки» не работает в enterprise

В Enterprise редко получается обойтись дефолтными шаблонами. Инфраструктура компаний часто состоит из зоопарка систем с древним железом, кастомными сборками, сложными сетевыми зависимостями (упал коммутатор в Екатеринбурге, а парализован Новосибирск) и разными политиками обновлений. В таких условиях «дефолтные» настройки сопровождают три типичные проблемы:

  1. Большое количество алертов, которые срабатывают примерно раз в пять минут, а то и чаще. Все потому, что дефолтные шаблоны Zabbix могут содержать 200–300 метрик, в то время как  для бизнеса на самом деле важны 7–10–15 ключевых показателей. Вручную разобрать такой поток невозможно, хотя некоторые смельчаки среди наших клиентов пытались. Логичный выход — попытаться автоматизировать разбор этого потока, но это очень ресурсозатратно. Если у вас десятки или сотни тысяч объектов и жёсткие требования к корреляции событий, имеет смысл смотреть в сторону специализированных Event Intelligence‑систем, но у них тоже есть особенность, они используют ИИ, который необходимо контролировать.​

  2. Каскадные алерты. Инфраструктура крупных компаний часто имеет иерархическую структуру, где стандартные настройки мониторинга создают эффект домино. Один сбой коммутатора порождает лавину из множества сообщений, кричащих о «недоступности» всех лежащих за ним узлов. Представьте удаленный офис с единым каналом интернета, где есть пограничный коммутатор, а за ним десятки наблюдаемых узлов (серверы, СХД, принтеры и т.д.). Из коробки на мониторинг встает каждый узел без учета зависимостей. Если коммутатор вышел из строя, заказчик получает десятки алертов, хотя на самом деле нужен только один — о недоступности офиса.

  3. Игнорирование  контекста. Здесь речь о том, что в ИТ‑инфраструктуре нет универсально критических метрик, и, например, загрузка процессора на 100% может быть нормальной для одних систем, но критичной для других. Так, у некоторых высокопроизводительных СХД утилизация кэша всегда находится на уровне 100%, и это нормально, но если она внезапно падает до 50%, это сигнал о проблемах.

Описанные выше проблемы — типичные грабли, с которых начинается взросление мониторинга в любой крупной инфраструктуре. Но чтобы выйти за рамки бесконечной настройки порогов и не утонуть в алертах, важно пересмотреть сам подход к управлению ИТ‑средой. Именно этому переходу от оперативного реагирования к стратегическому развитию посвящён наш Демо-день «Сервис-партнер: дирижер стабильной инфраструктуры» 2 апреля в Москве. Приходите, чтобы обменяться опытом и посмотреть, как работает наш сервис изнутри. Регистрация — здесь.

Как мы выделяем рабочие метрики

На практике эти три проблемы идут в связке, поэтому мы решаем их все вместе, шаг за шагом. Начинаем с фундамента, который актуален для любой компании: выделяем рабочие метрики. Условно их можно разделить на три группы.

Первая — те самые 7–15 метрик, после срабатывания которых реально нужно что‑то сделать. У каждой есть владелец, понятный сценарий что именно делать и SLA реакции. Под них мы оставляем триггеры и уведомления. Вторая группа — «для информации»: они полезны в расследованиях и хорошо смотрятся на графиках, но не требуют немедленных действий. Такие метрики мы собираем, но триггеры для них либо отключаем, либо оставляем без уведомлений, только с индикацией в интерфейсе. Третья — редкие и специфичные метрики, нужные одному проекту или одному администратору. Их выносим в отдельные шаблоны поверх базового, чтобы не раздувать глобальную конфигурацию и не размножать лишние алерты по всей инфраструктуре.

Антиспам‑подход к потоку уведомлений

Дальше переходим к самим триггерам. Пороговые значения для них часто ставят слишком «нервными», без гистерезиса и запаса. При таких настройках триггер реагирует на каждое колебание метрики и постоянно переключается между PROBLEM/OK. И, наконец, пороги часто жестко зашивают прямо в выражения триггеров, хотя эти значения стоит выносить в макросы. Так их можно централизованно править, не перелопачивая десяток триггеров вручную.​

Чтобы Zabbix не сыпал уведомлениями, как из пулемета, при масштабных сбоях, можно настроить автоматическую паузу на рассылку. 

1. Мониторинг частоты проблем. С помощью Database monitor отслеживаем текущее количество проблем и через препроцессинг вычисляем скорость их возникновения (проблем/сек).

2. Триггер для активации. Создаем триггер с тегом antispam, который срабатывает при превышении порога (например, >0.2 проблемы/сек). Порог — ориентир; на нашей практике он может варьироваться от 0.15 до 0.22 в зависимости от инфраструктуры.

3. Webhook для управления. Настраиваем Action типа Webhook с JavaScript-скриптом. При срабатывании триггера (Problem) он временно отключает все Actions для оповещений, а при восстановлении (Resolved) — включает их обратно.

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

Контекст важнее цифр

Чтобы добавить нужного контекста, мы заранее вкладываем в алерт максимум полезной информации. Вместо абстрактного оповещения «Disk space is low» подставляем в тело уведомления через event‑макросы текущие значения ключевых метрик, окружение, название сервиса, владельца, а заодно даем ссылки на графики и последние события по этому хосту. Параллельно разводим трафик оповещений: критичные с нужными тегами уходят в боевой чат и будят дежурного, а все остальные либо складываются в тикет‑систему, либо остаются в общем канале мониторинга. В результате Zabbix перестаёт быть просто пищалкой.

Про то, как слепота к контексту может сыграть злую шутку с системой, у нас есть показательный пример. У Microsoft Exchange есть техническая особенность, которую Microsoft захардкодила в систему: как только свободное место на диске, на котором находится очередь писем, становится меньше 20%, почта перестаёт уходить, а при падении ниже 10% система перестаёт принимать письма, несмотря на физическое наличие места. Но стандартный мониторинг диска C, где по умолчанию лежит очередь, по порогам 15/10/5% ничего подозрительного, конечно, не увидит. И вот в инфраструктуре одного заказчика работало четыре почтовых сервера на 5000+ пользователей, а на мониторинге было всего два основных показателя: свободное место на диске и длина очереди писем. Однажды сработал алерт по очереди — там накопилось больше 10 тысяч писем, счётчик рос, но при этом алерта по недостатку места не было, поэтому причина сразу была неочевидна. 

Мы быстро разобрались, подключились к серверу, в виртуализации подняли отдельный том и перенесли туда очередь, перезапустили транспортный сервис, и проблема ушла за полчаса. Специалист по мониторингу Zabbix вряд ли знал про эти встроенные пороги Exchange, здесь нужна профильная экспертиза по продукту. Обычно мы очередь сообщений сразу выносим на отдельный диск, чтобы работа системного тома не влияла на работу почты.

В одном из кейсов с NetApp‑массивом было еще интереснее. Там bond состоял из двух портов в разные коммутаторы, и один порт упал. Во встроенном веб‑интерфейсе массив продолжал «гореть зеленым», в логи заказчик не заглядывал, а мониторинг начал сигналить о degraded‑состоянии линка. На первый взгляд, ничего страшного, но отказоустойчивости уже нет. Если упадет второй порт, то массив окажется недоступен. Мы расширили описания для данного состояния линка, чтобы дежурные специалисты сразу знали что необходимо делать.

И отдельная тема — бизнес‑метрики. Например, однажды мы мониторили терминалы выдачи талонов в отделениях крупной финансовой компании. Они работали с 9 до 18 и мониторинг просто считал количество выданных талонов в час, собирал статистику и сравнивал ее с историческими данными. Если норма выдачи падала, то Zabbix бил тревогу. Технические метрики здесь могли не показать проблемы, зато бизнес‑метрика сразу указывала на возможную неработоспособность сервиса.

Настройка цепочки зависимостей

Настроив оповещения, мы переходим к цепочкам зависимостей по слоям: «железо → сеть → платформа → сервис». 

Смысл здесь в том, чтобы при падении коммутатора где-нибудь в удаленном офисе срабатывал один корневой триггер, а не с десяток связанных с разными компонентами инфраструктуры филиала. 

Важно помнить, что Zabbix не делает анализ корневой причины за вас, он лишь честно следует той схеме зависимостей и корреляции, которую вы ему нарисовали, поэтому здесь стоит быть особенно аккуратными. Если ошибиться, можно получить автоматическое подавление или закрытие событий, которые на самом деле важны. Плюс, есть тонкость с таймингами: зависимые триггеры не должны успевать срабатывать раньше корневого, иначе часть событий уйдет в историю прежде, чем suppression успеет сработать.​

Настройка корреляций

Зависимости хорошо подходят для статических, топологических связей типа «железка за железкой», но для логических связей нужно задействовать другой механизм. В Zabbix для этого есть глобальная корреляция событий по тегам: мы помечаем события метками среды, сервиса, компонента, роли и дальше собираем из этого правила. Можно, например, гасить алерты по службам, если параллельно пришло событие о плановой перезагрузке хоста с таким же тегом, или связать ошибку в логах приложения с одновременным ростом latency и падением количества транзакций в базе. Теги вообще мастхев: они подходят и для маршрутизации (чтобы направить алерты с нужными тегами в отдельный чат или on‑call канал), и для тонкой фильтрации в UI, и для построения сложных сценариев корреляции.

Для распределенной инфраструктуры мы обычно добавляем еще пару слоев гигиены. Во‑первых, шифруем доставку метрик через интернет: Zabbix умеет строить защищенные каналы и между своими компонентами, и между агентом на наблюдаемом узле, и сервером. Вендор подробно это описывает в разделе про pre‑shared keys. Это полезно, если у вас нет выделенного шифрованного канала в сторону сервера мониторинга. Во‑вторых, используем Zabbix proxy там, где есть удаленные площадки, филиалы и хосты за файрволом. Прокси собирает метрики локально и отдает их на центральный сервер по одному каналу без необходимости открывать дополнительные порты.

Причем, при обрыве связи Zabbix будет накапливать данные и догрузит их уже после восстановления канала. В крупномасштабных инсталляциях прокси также помогают разнести нагрузку по сбору данных: важен уже не только счётчик хостов, но и общий поток значений в секунду. Вынесение хостов на proxy не дает центральному серверу Zabbix захлебнуться.​

Кастомные скрипты или Как научить Zabbix понимать железо

Иногда кастомных настроек не хватает. Мы стали активно использовать скрипты, когда начали ставить железо на мониторинг. У него есть одна неприятная особенность: долгое время каждый вендор использовал собственные протоколы и подходы. Одни и те же метрики приходилось собирать пятью разными способами в зависимости от производителя. Тогда мы стали плотно использовать собственные скрипты. Так продолжалось вплоть до массового внедрения  REST API. 

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

Причем у каждого массива своя утилита, и ее версия зависит от прошивки. Запускаешь, ждешь, пока она выгрузит кучу CSV, потом парсишь. Нам пришлось писать скрипт, который сам подбирает нужный export tool под массив, настраивает, запускает, разбирает CSV и периодически скармливает результат Zabbix.

Похожая история была с мониторингом кондиционеров. Там свой протокол инженерных систем, о котором Zabbix ничего не знает. Ему нужен специальный скрипт-переводчик для нормализации метрик.

Сами по себе кастомные скрипты не сложные с точки зрения программирования. Для эксперта с опытом это рабочая задача на неделю, максимум две, включая отладку и косметические правки по замечаниям заказчика. Ключевая сложность не в коде, а в понимании железа. 

У нас в команде есть и программисты, и инфраструктурщики, но на практике получается так, что скрипты пишут в основном вторые. Проще научиться программировать на нужном уровне, чем за то же время глубоко разобраться в устройствах, протоколах и нюансах их работы. Хороший инженер мониторинга знает как заставить Zabbix считать все что угодно. Но только глубокий специалист по storage или инженерным системам подскажет, что именно и с какой периодичностью нужно спрашивать у железа, чтобы не нагрузить его, и как интерпретировать ответ. Без такого тандема кастомный скрипт рискует превратиться в генератор ложных срабатываний.

Яркий пример — уже упомянутая утилизация кэша в массивах, или Dell Unity: к ней нельзя слишком часто обращаться за метриками — можно перегрузить управление и перезагрузить контроллер. Для системы хранения это очень неприятно. Без человека, который  понимает такие нюансы, легко накрутить триггеры так, что либо пропустишь реальную проблему, либо забьешь мониторинг ложными алертами. 

Поэтому перед написанием скрипта мы сперва смотрим, что вообще может отдать объект мониторинга. Анализ идет на нескольких уровнях: работоспособность, производительность, конфигурация. И если задачу можно закрыть стандартными средствами Zabbix или уже готовым решением, то мы стараемся не изобретать велосипед. Если нет, то пишем внешний скрипт, модуль или шаблон. 

Вся кодовая база, документация и  готовые шаблоны хранятся у нас в GitLab. Сейчас там около пятидесяти семейств шаблонов, которые мы регулярно рефакторим, дорабатываем и используем повторно.

Как выжать из мониторинга всё и даже больше

Заявки от Zabbix хорошо структурированы, и их легко сопоставлять автоматически, а вот люди часто пишут расплывчато: «У нас что‑то сломалось в ERP». Чтобы справляться с такими заявками, мы планомерно начинаем применять системы на базе ИИ. В теории, они могут находить общие признаки в разрозненных тикетах и логах, показывать связи между событиями и автоматически группировать их в инциденты. Сейчас тестируем подход на внутренних данных, изолированно от клиентских систем, чтобы понять, насколько модели справляются с реальными паттернами проблем, и не создают ли они лишний шум.

Параллельно с этим акцент смещается на автоматизацию самого мониторинга: не статичные пороги, а динамические переопределения на разных уровнях. Система, используя исторические данные, должна понимать аномалии в параметрах и подстраивать базовые линии под конкретные условия — профиль нагрузки сервиса, время суток, сезонность. Если отклонение составляет 20–30% от ожидаемого профиля, это повод реагировать, особенно если одновременно появляются нетипичные цепочки или всплески плотности событий. Такие вещи на ручной настройке реализовать еще можно, но как только источников становится десятки, все становится сложнее. Поэтому мы присматриваемся к решениям AI-powered Observability, которые умеют из сырых метрик, событий и логов строить более умные безлайны, искать отклонения по плотности и последовательности событий, а не только по разовым выбросам, автоматически нормализовать события, обогащать их контекстом, собирать в инциденты с прогнозом развития, устойчиво снижать шум и заранее подсвечивать риски.

Отдельный вопрос, который мы прорабатываем в контексте внедрения таких платформ, — временной диапазон анализа. За какой период считать норму: неделю, месяц, полгода? Для быстро меняющихся сервисов недели исторических данных часто достаточно, а для стабильных enterprise‑систем иногда требуется годовая аналитика или больше. Мы уже практикуем регулярные обзоры утилизации, снимаем срезы и смотрим динамику, по которой можем заранее рекомендовать заказчику докупить оборудование или изменить конфигурацию, не дожидаясь, пока все упрется в потолок. Похожую идеологию развивают аналитические платформы вроде Artimate: они забирают метрики, события, логи и изменения из разных систем мониторинга, строят ML‑модели кластеризации и корреляции, выделяют аномальные узлы и связи и позволяют смотреть на риски не точечно по одному Zabbix, а в разрезе всей инфраструктуры.

Вместо заключения

По большому счёту, Zabbix в enterprise‑среде перестает быть просто системой сбора метрик и превращается в конструктор. Поэтому эффективность его работы все больше зависит от того, насколько аккуратно вычищен шум, настроены пороги под архитектуру, привязаны владельцы.

Если все это сделано грамотно, то даже самые крупные инциденты проживаются без сотен лишних уведомлений. Zabbix становится надежным фундаментом для эксплуатации. Превращение его в такой фундамент — это всегда синергия: глубокое знание возможностей самого Zabbix должно сочетаться с не менее глубоким пониманием специфики оборудования и приложений. И если первый компонент — это наша прямая обязанность, то второй мы всегда стремимся выстроить в плотном диалоге с архитекторами и администраторами, которые знают свою инфраструктуру, как свои пять пальцев.