Привет, Хабр! Меня зовут Ярослав Яковкин, я младший инженер по разработке ПО в YADRO, работаю в команде TATLIN.FLEX. Еще будучи стажером, я разбирался в инструментах, которыми пользуется моя команда, и обнаружил, что система мониторинга Zabbix допускает некоторые ошибки в работе. Они не влияют на производительность, но, если их исправить, всем станет лучше.
Я погрузился и узнал, как устроен инструмент и что сделать, чтобы устранить неисправности, а опыт собрал в этой статье. Материал будет полезен тем, кто недавно работает с Zabbix, — возможно, вы найдете решение своей проблемы под катом. А опытных девопсов приглашаем в комментарии — поделитесь лучшими практиками по оптимизации Zabbix.
Что такое Zabbix и зачем он нам
Zabbix — это enterprise-level система мониторинга с открытым исходным кодом, которая позволяет собирать метрики с различной инфраструктуры, настраивать уведомления об инцидентах и визуализировать данные.
Мы выбрали Zabbix из-за гибкости. Платформа интегрируется с почтовыми серверами, мессенджерами, системами оповещения, а также Prometheus и Grafana — в общем, практически со всем, что поддерживает API. Zabbix объединяет все это в одном месте.
Для нас Zabbix стал ключевым инструментом мониторинга СХД, позволяющим в едином окне отслеживать состояние контроллеров, дисков, сетевых адаптеров и получать уведомления о критических событиях.
Если вы хорошо работаете с Zabbix и знаете Linux, откликайтесь на вакансию ведущего DevOps-инженера.
Архитектура мониторинга без агентов
Классическая схема развертывания Zabbix выглядит так:
Из чего состоит система:
Zabbix-сервер — центральный компонент, обрабатывающий данные.
База данных (PostgreSQL, MySQL) — хранит конфигурации и метрики.
Веб-интерфейс — отвечает за управление и визуализацию.
Zabbix Agent — легкий агент для сбора данных с хостов, используется для сбора метрик самого Zabbix-сервера.
Особенность нашей работы — в том, что в контроллерах СХД YADRO установка агентов не поддерживается по соображениям безопасности и архитектурным ограничениям. Вместо этого мы используем:
REST API — для получения логических метрик (статусов томов, iSCSI-таргетов, конфигураций).
SNMP GET — для сбора аппаратных показателей из стандартных MIB.
Все это реализуется через шаблоны.
Шаблоны: REST API и SNMP
Шаблоны в Zabbix — это наборы инструкций, определяющих, какие данные собирать и как их обрабатывать. С их помощью можно мониторить несколько систем хранения данных и следить за показателями. Шаблонами пользуемся не только мы, разработчики, но и заказчики. Это удобно, когда нужно объединить несколько устройств в одну мониторинговую систему, поэтому мы и предоставляем Zabbix-шаблоны через руководство по мониторингу СХД.
Для удобства мы разделили шаблоны на два типа:
REST API — собирает данные через интерфейс командной строки контроллера. Это преимущественно логические метрики, а именно — конфигурации томов, статусы таргетов, сетевые настройки.
SNMP — работает со стандартными MIB и flex.mib, предоставляя информацию о «железе»: температуре, состоянии дисков, RAID-группы, блоках питания.
Практически все шаблоны можно разделить на верхний и нижний уровни.
Верхний уровень: сырые данные и готовые метрики
На верхнем уровне находятся:
Сырые данные (Raw Data) — полные JSON-ответы от API или SNMP.
Готовые метрики — извлеченные из сырых данных конкретные значения.
HTTP-агент делает запрос к API, получает JSON с сетевой информацией, а зависимые элементы (Dependent items) извлекают из него отдельные поля через JSONPath.
Нижний уровень: Low-Level Discovery
Нижний уровень используется, когда мы заранее не знаем точное количество объектов для мониторинга (диски, адаптеры, таргеты). Здесь работает механизм Low-Level Discovery (LLD, низкоуровневое обнаружение).
Низкоуровневое обнаружение позволяет автоматически создавать элементы, триггеры и графики для различных сущностей на хосте. Zabbix может автоматически запускать мониторинг файловых систем или сетевых интерфейсов без необходимости вручную создавать элементы для каждой файловой системы или сетевого интерфейса. LLD также может создавать хосты, например, для заполнения виртуальных машин, обнаруженных на гипервизоре, и вложенные правила обнаружения, обеспечивая многоуровневое обнаружение.
Компоненты LLD:
Правило обнаружения — определяет, какие объекты найти.
Макросы — переменные с уникальными идентификаторами объектов.
Прототип элемента данных — шаблон для создания метрик.
Прототип триггера — шаблон для создания правил оповещения.
Мы разобрались, как устроена работа Zabbix. Дальше поговорим, с какими проблемами я столкнулся, пока изучал решение.
Что я предложил исправить в работе Zabbix
Как я писал выше, пока разбирался с Zabbix, обнаружил несколько проблем. Мы с коллегами исправили их в ближайшем релизе, поэтому описываю решения, которые сработали у нас.
Неоптимальный сбор данных
Проблема: я обнаружил, что на верхнем уровне мы собираем сырые данные в виде сплошной JSON-строки по всем сенсорам. Затем на нижнем уровне мы их разбиваем на типы, снова отправляем API-запрос к сенсорам и получаем их повторно.
Это создает избыточную нагрузку, ведь данные уже собирали. Сенсоры большие, растет нагрузка на сеть, СХД и API. На крупных системах с множеством дисков (хотя это не сенсоры, но метрики собираются через API с каждого диска) веб-интерфейс может лечь от обилия запросов: сначала выбиваются таймауты, сервер не успевает ответить, все падает, включая сам жесткий диск.
Решение: использовать зависимые элементы (Dependent items), которые берут данные из кеша master-элемента без дополнительных запросов.
Избыточность прототипов
Проблема: в шаблонах были созданы прототипы элементов данных, которые нигде не использовались. Это осложняло поддержку и увеличивало размер шаблонов.
Решение: провести аудит и удалить неиспользуемые прототипы.
Разбираем юзкейсы от коллег
Когда я показал свои находки коллегам, оказалось, что инженеры внедрения и третьей линии поддержки тоже сталкивались со сложностями в использовании Zabbix. Я собрал обратную связь и проработал решения.
Недостатки документации
Мне задали вопрос: «В мониторинг-гайде мало описанной функциональности параметров мониторинга. Нет sizing guide. Если я включу все параметры, что произойдет с системой?»
Проблема: при включении всех доступных метрик (особенно performance-счетчиков) СХД перестает корректно отвечать на запросы, веб-интерфейс начинает «захлебываться», база данных не успевает обрабатывать запросы.
Решение: в шаблоне по умолчанию должны быть включены только безопасные метрики, а для их определения нужно разработать sizing guide с рекомендациями:
Какие метрики включать для базового мониторинга?
Какие метрики требуют дополнительной нагрузки?
Какие метрики не стоит включать на продакшене?
Unicode в SNMP-трапах
Проблема: SNMP-трапы приходили с UTF-8 символами (кавычки, тире, спецсимволы из UI), которые Zabbix обрабатывал некорректно.
Решение: в шаблонах Zabbix встроен JavaScript-код для предобработки сообщений, для корректной работы нужно было только исправить скрипты.
Токены и сессии
Проблема: у REST API-токена ограничено время жизни. По истечении срока действия токена мониторинг прекращается.
Решение: устанавливать максимальное время жизни сессии и вручную обновлять токен раз в месяц.
В этом случае решение удалось автоматизировать: разработали скрипт для Zabbix, который автоматически обновляет макрос {$API_TOKEN}. Скрипт содержит идентификатор макроса и логику переавторизации.
Чему я научился
Интеграция СХД YADRO с Zabbix — это комплексная задача, требующая глубокого понимания как архитектуры систем хранения, так и возможностей платформы мониторинга. Мы прошли путь от простых GET-запросов до сложных Low-Level Discovery-правил с зависимыми элементами, выявили и исправили несколько недоработок.
По итогам работы я сделал несколько ключевых выводов:
Всегда используйте зависимые элементы вместо повторных запросов.
Тестируйте шаблоны в реальных конфигурациях, а не только по документации, чтобы убедиться в их работоспособности в реальных условиях эксплуатации.
Ведите спецификации, особенно тщательно документируйте ограничения и sizing.
Автоматизируйте рутину: обновление токенов и ротацию ключей можно проводить не вручную.
Слушайте фидбек от коллег — это настоящие юзкейсы, которые покажут, где находится проблема.
