Комментарии 9
Опять велосипедостроение через intergrations.
IMHO, integrations - самый вредный раздел сайта zabbix.com (куча самодела).
Начнем с того, что MegaCLI был заменен на StorCLI (и считается устаревшим - legacy).
StorCLI является рекомендованным вместо MegaCLI начиная в 2013-го года (9 лет назад!). И, насколько я помню, самые свежие raid-карты поддерживают только StorCLI.
https://docs.broadcom.com/doc/12352476
https://www.intel.com.au/content/www/au/en/support/articles/000023172/server-products.html
StorCLI поддерживает вывод в JSON - ключ J (а Zabbix умеет нативно вытаскивать данные при препроцессинге из JSON)
Все эти велосипеды с perl/python/bash, вызывающие legacy бинарники через cron и отправляющие переработанный на клиенте результат из временного файла через zabbix-sender (чем не устроил zabbix-agent и грамотно настроенный sudoers.d?) - вселенское зло, IMHO.
А сохранение вывода во временный файл с последующей отправкой содержимого этого файла через zabbix-sender без проверки timestamp (а был ли файл с сохраненными данными обновлен?) - это вообще жесть (будете продолжать слать старые данные о том, что "raid в порядке", когда отвалился скрипт опроса???).
Даже бегло - вот это уже значительно лучше (но очень далеко от идеала): https://github.com/zabbix/community-templates/tree/main/Server_Hardware/RAID_Cards/template_lsi_avago_broadcom_using_json_outputs_of_storcli
Данные лучше парсить/вытаскивать из машинночитаемого JSON на Zabbix-сервере (там же делать discovery контроллеров, дисков и статуса), благо возможностей препроцессинга на Zabbix-сервере - куча.
И просто отправлять сырой вывод storcli в машинночитаемом JSON (с крайне ограниченно настроенным sudoers) как есть на сервер (без предобработки на клиенте). И никаких "временных" файлов с данными и zabbix-sender-ов в cron без логики проверки свежести содержимого временного файла (ну вы что!).
Наш SAAS-сервис интернет-магазинов был создан давно, более 16 лет назад. И в нем широко использовались (и до сих пор есть на некоторых серверах) именно контроллеры MegaCLI (и еще были контроллеры Adaptec). Кроме того, мы начинали внедрять Zabbix еще с версии 3.x.
Полагаю, контроллеры MegaCLI есть у многих, а у кого новее - смогут легко адаптировать этот скрипт или написать на его основе свой собственный. В свое время готового решения на https://www.zabbix.com/integrations мне найти не удалось.
Но как сказал Генри Форд: "Всё можно сделать лучше, чем делалось до сих пор."
Что касается "отвала скрипта опроса" и "проверки свежести", то это полностью решается триггером, который срабатывает, если данные слишком долго не передавались на сервер Zabbix (есть в конце статьи):
nodata(/Shop2YOU LSI/lsi.isOptimal,5400s)=1
Реально проверки один раз в час вполне хватает. Событие выхода из строя одного из дисков или аккумулятора в контроллере можно обрабатывать в плановом, а не в экстренном порядке.
А если контроллер полностью вышел из строя, то сработает другой триггер - по недоступности сервера. И тогда сразу придет SMS и будет сделан дозвон роботом до системного администратора с передачей голосового сообщения о проблеме.
Что касается zabbix-sender, то с его помощью можно контролировать процессы, которые выполняются довольно долго, не заставляя ждать окончания получения данных агента Zabbix. В этом смысле zabbix-sender позволяет мониторить что угодно.
На практике уже много лет это решение очень помогает нам обнаружить выход из строя как отдельных дисков массива, так и необходимость замены блока аккумулятора в контроллере. Также успешно отслеживается процесс переобучения аккумулятора и режим кэширования при записи.
Я прекрасно понимаю ваши доводы.
Сам начинал мониторить LSI с этого решения.
В итоге когда был сбой (не помню, вроде с sudoers что-то, давно было) и временный файл, содержащий "ответ" от опроса контроллера попросту не обновлялся, на сервер отправлялись старые данные (из необновленного файла). nodata триггеры в этом случае не сработают (данные-то приходят! правда этим данным уже несколько месяцев и за это время рейд посыпался - только вот об этом никто не узнает!).
Так что заявленный мною сценарий "проблемы" при таком подходе был выстрадан на живой системе на практике (поэтому я так "топлю" за правильные подходы).
А потом мы поставили в новый сервер новые карты, которые уже не работали с MegaCLI.
StorCLI решил все проблемы (он универсален, поддерживает json и работает со старыми картами вместо MegaCLI).
Решение с мониторингом я переписал, чтобы не было временных файлов. Заодно сделал безопасным в плане передачи агрументов. Работодателя с тех пор сменил и решения уже не осталось (на github не выклыдывал).
Zabbix развивается семимильными шагами, и те практики, что использовались ранее (зачастую далекие от идеала) теперь лучше избегать.
В статье мы рассказывали именно о нашем опыте мониторинга.
У нас такой проблемы с отсутствием обновления файла не было более чем за 10 лет использования примерно на десятке серверов - после настройки все тщательно проверяли. К тому же наши серверы дополнительно отправляют письма администратору с результатами диагностики контроллеров - мы начинали с таких писем.
Была другая проблема на FreeBSD. Там иногда MegaCLI возвращал пустые строки вместо данных, из-за этого срабатывали триггеры. Пришлось добавить в скрипт многократный вызов. Сейчас, правда, на FreeBSD остался только один сервер бекапов, а на Debian этой проблемы мы не замечали.
В любом случае спасибо за дополнение! Если StorCLI работает со старыми картами, то видимо лучше использовать именно его.
временный файл, содержащий "ответ" от опроса контроллера попросту не обновлялся, на сервер отправлялись старые данные (из необновленного файла)
Я в таких случаях или пишу мониторинг обновления самого файла через vfs.fs.file или как там его, или пишу текущее время в файл, если он скажем json. Соответственно, если файл перестал обновляться, это алерт и надо разбираться, что за фигня произошла.
Мониторинг контроллера MegaRAID и подключенных к нему дисков с помощью Zabbix