Назад | Перейти на главную страницу

Nagios / Icinga: не показывать CRITICAL для разделов DRBD на резервном узле

Я установил ha-кластер pacemaker / 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"

Разве нет простого способа / наилучшей практики отключить эту проверку DRBD на резервном узле в Nagios или Icinga2? Конечно, я хочу, чтобы эта проверка вступила в силу для резервного сервера после аварийного переключения.

В моей среде мы управляем несколькими службами, работающими поверх устройств drbd (традиционные, контейнеры lxc, контейнеры докеров, базы данных и т. Д.). Мы используем стек opensvc (https://www.opensvc.com), который является бесплатным, с открытым исходным кодом и предоставляет функции автоматического переключения при отказе. Ниже представлена ​​тестовая служба с drbd и приложение Redis (в примере отключено)

Сначала на уровне кластера мы можем увидеть в svcmon вывод что:

  • Кластер opensvc из 2 узлов (узел-1-1 и узел-1-2)
  • service servdrbd активен (зеленый верхний регистр O) на узле-1-1 и находится в режиме ожидания (зеленый нижний регистр o) на узле 1-2
  • node-1-1 - предпочтительный главный узел для этой службы (акцент с циркумфлексом рядом с заглавной O)

На уровне обслуживания svcmgr -s servdrbd print status, мы можем увидеть :

  • на первичном узле (слева): мы видим, что все ресурсы включены (или находятся в режиме ожидания; это означает, что они должны оставаться в рабочем состоянии, когда служба работает на другом узле). А что касается устройства drbd, оно отображается как Первичный
  • на вторичном узле (справа): мы видим, что задействованы только резервные ресурсы, а устройство drbd находится в Вторичный штат.

Чтобы смоделировать проблему, я отключил устройство drbd на вторичном узле, и это привело к следующему предупреждения

Важно видеть, что статус доступности сервиса по-прежнему вверх, но общий статус службы снижается до предупреждать, что означает "хорошо, производство все еще идет нормально, но что-то идет не так, посмотрите"

Как только вы знаете, что все команды opensvc можно использовать с селектором вывода json (nodemgr daemon status --format json или svcmgr -s servdrbd print status --format json), его легко подключить к сценарию NRPE и просто отслеживать состояние службы. И, как вы видели, любая проблема на первичном или вторичном уровне оказывается в ловушке.

В nodemgr daemon status лучше, потому что это один и тот же вывод на всех узлах кластера, и вся информация о службах openvc отображается в одном вызове команды.

Если вас интересует файл конфигурации службы для этой установки, я разместил его на pastebin Вот

Я бы посоветовал не отслеживать это напрямую на хосте. В нашей среде мы используем Pacemaker для автоматизации отработки отказа. Одна из вещей, которые Pacemaker делает для нас, - перемещает IP-адрес при переключении. Это гарантирует, что наши клиенты всегда указывают на основной, и помогает сделать переключение на отказ прозрачным со стороны клиента.

Для Nagios мы отслеживаем множество сервисов на каждом хосте, чтобы следить за происходящим, но затем у нас есть дополнительный «хост», настроенный для виртуального / плавающего IP-адреса для мониторинга устройств и сервисов DRBD, которые работают только на первичном.

Вы могли бы использовать check_multi чтобы запустить обе проверки DRBD как одну проверку Nagios, и настроить его так, чтобы он возвращал ОК, если ровно один дополнительных проверок в порядке.

Однако становится сложно решить, к какому хосту прикрепить чек. Вы можете прикрепить его к хосту с помощью VIP или прикрепить чек к обоим хостам и использовать NRPE / ssh на каждом для проверки другого и т. Д.