Nagios: проверять несколько сервисов одновременно?

Я только начал использовать Nagios для мониторинга группы широковещательных передатчиков. Каждый передатчик определяется как хост, и каждый аспект передатчика, который я хочу контролировать (прямая радиочастота, отраженная радиочастота, напряжения питания и т. д.), определяется как услуга. При этом я могу получить сигнал тревоги, если какой-либо из этих аспектов выходит за допустимые пределы, и могу использовать данные о производительности для построения графика каждого аспекта (в данном случае с помощью pnp4nagios).

Чтобы проверить данные телеметрии передатчиков, я написал несколько сценариев, один из которых адресован уникальным возможностям каждой марки/модели задействованного передатчика. В соответствии с тем, как я видел, как работают другие проверки Nagios, аргумент скрипта позволяет вам выбрать, о каком аспекте вы хотите сообщить.

Сначала я был доволен этим. Это работало как любое более традиционное использование Nagios, с которым я сталкивался. Но потом я наткнулся на загвоздку.

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

Моя первая мысль заключалась в том, чтобы справиться с этим, запустив один экземпляр одной команды, которая вернула бы значения для нескольких служб. Это также может показаться гораздо более эффективным, чем открытие столько экземпляров соединения, сколько проверяемых служб. С точки зрения сценария это легко сделать. Но с точки зрения конфигурации Nagios я не знаю, как (или если?) вы бы это сделали.

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

Мысли?


person kthelen    schedule 06.03.2021    source источник
comment
После некоторого дополнительного чтения я рассматриваю возможность пассивной отправки данных службы. Это решит все проблемы, о которых я говорил. Но это создаст несколько второстепенных новых — теперь есть внешние процессы, которые нужно продолжать выполнять, и это немного выходит за рамки основного способа ведения дел (будущему администратору может быть немного больно, чтобы понять, как это работает). Как всегда, я открыт для предложений!   -  person kthelen    schedule 07.03.2021


Ответы (1)


Моя первая мысль заключалась в том, чтобы справиться с этим, запустив один экземпляр одной команды, которая вернула бы значения для нескольких служб. Это также может показаться гораздо более эффективным, чем открытие столько экземпляров соединения, сколько проверяемых служб. С точки зрения сценария это легко сделать. Но с точки зрения конфигурации Nagios я не знаю, как (или если?) вы бы это сделали.

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

При написании собственного плагина полезно помнить:

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

Я рассматриваю возможность пассивной отправки служебных данных. Это решит все проблемы, о которых я говорил. Но это создаст несколько второстепенных новых — теперь есть внешние процессы, которые нужно продолжать выполнять, и это немного выходит за рамки основного способа ведения дел (будущему администратору может быть немного больно, чтобы понять, как это работает).

Я не думаю, что это лучшее решение, чем написание собственного плагина, если только данные не поступают от узлов, которые активно их выталкивают.

Например, в контексте IoT отслеживаемые узлы могут на самом деле отправлять результаты пассивной проверки непосредственно экземпляру Nagios. В этом случае пассивные проверки имеют смысл, потому что вы просто хотите брать то, что кто-то дает вам, и действовать в случае отсутствия результатов (свежесть).

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

person pzkpfw    schedule 07.03.2021
comment
На самом деле я с самого начала писал свои собственные плагины, поэтому мне доступны любые/все варианты, это просто вопрос выбора правильного. Что меня застряло в активных проверках, так это то, что я не знаю, как обновить несколько служб одновременно с помощью одного запуска одной команды. Пример: в какой-то момент я пытался решить проблему, которая оказалась непостоянной проблемой электропитания. Напряжение на одном источнике питания упадет, и РЧ-выход передатчика также упадет — это легко диагностировать, если вы видите, что обе проблемы возникают одновременно. (1/3) - person kthelen; 08.03.2021
comment
В Nagios у меня есть служба для вывода RF и служба для напряжения питания (среди прочего). Но эти сервисы обновляются асинхронно. Таким образом, из Nagios вряд ли появится дымящийся пистолет — оба сервиса одновременно недопустимы. Проверки для каждой службы вызывают один и тот же сценарий, но с разными аргументами, в результате чего сценарий извлекает и сообщает только те значения, которые необходимы для проверяемой службы. (2/3) - person kthelen; 08.03.2021
comment
В идеале я бы вызвал этот сценарий один раз и одновременно обновил бы все службы, предоставив синхронизированный снимок всех значений, что потенциально намного полезнее, чем проверять их по одному в течение более длительного периода. (3/3) - person kthelen; 08.03.2021
comment
Написание плагина, который запускается через корону и отправляет пассивные результаты, тоже отлично работает. - person pzkpfw; 08.03.2021