Nagios / Icinga: не показывать CRITICAL для разделов DRBD на резервном узле
Я установил ha-кластер кардиостимулятора / corosync в конфигурации аварийного переключения с двумя узлами: производительным и резервным. Есть три раздела DRBD. Пока все работает нормально.
Я использую Nagios NRPE на обоих узлах, чтобы контролировать сервер с помощью icinga2 в качестве инструмента отчетности и визуализации. Теперь, когда разделы DRBD на резервном узле не монтируются до тех пор, пока не будет переключателя аварийного переключения, я всегда получаю критические предупреждения для них:
Следовательно, это ложное предупреждение. Я уже наткнулся на DISABLE_SVC_CHECK и попытался его реализовать, вот пример:
echo "[`date +%s`] DISABLE_SVC_CHECK;$host_name;$service_name" >> "/var/run/icinga2/cmd/icinga2.cmd"
Isn ' Есть ли простой способ / наилучшая практика отключить эту проверку DRBD на резервном узле в Nagios или Icinga2? Конечно, я хочу, чтобы эта проверка вступила в силу для резервного после аварийного переключения.
Я бы посоветовал не контролировать это на хосте напрямую. В нашей среде мы используем Pacemaker для автоматизации отработки отказа. Одна из вещей, которые Pacemaker делает для нас, - это перемещает IP-адрес при аварийном переключении. Это гарантирует, что наши клиенты всегда указывают на основной, и помогает сделать отработку отказа прозрачной со стороны клиента.
Для Nagios мы отслеживаем множество сервисов на каждом хосте, чтобы следить за происходящим, но затем у нас есть дополнительный " host », настроенный для виртуального / плавающего IP-адреса для мониторинга устройств и служб DRBD, которые работают только на первичном.
В моей среде мы управляем несколькими службами, работающими поверх устройств drbd (традиционные, контейнеры lxc, контейнеры докеров, базы данных и т. Д.). Мы используем стек opensvc ( https://www.opensvc.com ), который является бесплатным, с открытым исходным кодом и предоставляет функции автоматического переключения при отказе. Ниже представлена тестовая служба с drbd и приложение redis (в данном примере отключено)
Сначала на уровне кластера, в выводе svcmon мы видим, что:
- 2 узла opensvc cluster ( узел-1-1 и узел-1-2)
- service servdrbd работает (зеленый верхний регистр O) на узле-1-1 и в режиме ожидания (нижний регистр зеленый O) на узле 1-2
- узел-1 -1 - предпочтительный главный узел для этой службы (акцент с циркумфлексом рядом с заглавными буквами O)
На уровне службы svcmgr -s servdrbd print status мы можем увидеть:
- на основном узле ( слева): мы видим, что все ресурсы включены (или находятся в режиме ожидания; это означает, что они должны оставаться активными, когда служба работает на другом узле). Что касается устройства drbd, оно отображается как Primary
- на вторичном узле (справа): мы видим, что задействованы только резервные ресурсы, а устройство drbd находится в состоянии Secondary . .
Чтобы смоделировать проблему, я отключил устройство drbd на вторичном узле, что привело к появлению следующих предупреждений
Важно видеть, что статус доступности службы все еще вверх , но общий статус службы снижается до warn , что означает «хорошо, производство все еще работает нормально, но что-то идет не так, посмотрите»
Как только вы узнаете, что все команды opensvc могут использоваться с селектором вывода json ( nodemgr daemon status --format json или svcmgr -s servdrbd print status --format json ), его легко вставить в сценарий NRPE и просто следите за состояниями службы. И, как вы видели, любая проблема на первичном или вторичном сервере перехватывается.
Состояние демона nodemgr лучше, потому что это одинаковый вывод на всех узлах кластера, и вся информация о службах openvc отображается в одном вызов команды.
Если вас интересует файл конфигурации службы для этой настройки, я разместил его на pastebin здесь
Вы можете использовать check_multi для запуска обеих проверок DRBD как одной проверки Nagios и настроить его так, чтобы он возвращал OK, если ровно один из с под-проверками все в порядке.
Однако становится сложно решить, к какому хосту прикрепить проверку. Вы можете прикрепить его к хосту с помощью VIP или прикрепить чек к обоим хостам и использовать NRPE / ssh на каждом для проверки другого и т. Д.