Nagios в своем стандартном использовании мониторы с проверками на определенный момент времени: либо что-то истинно, либо нет.
Другие инструменты, такие как SGI's PCP, HP MeasureWare и SEC, обеспечивают мониторинг во времени - отслеживая такие вещи, как среднее время доступа к диску за последние пять минут или другие подобные элементы. Есть ли что-нибудь подобное для Nagios? Я уже использую NDOUtils, который кажется естественным источником таких данных.
Я хотел бы иметь что-то, что отслеживало бы и запускало тревоги на основе временной проверки с использованием исторических данных. Есть ли что-нибудь подобное для Nagios?
Я написал нагиос проверить плагин использование исторических данных из sar, которые могут вас заинтересовать. Даже если они не нужны вам из коробки, вы можете легко использовать их в качестве отправной точки для более сложных проверок.
Ты говоришь
Пример использования: генерировать сигнал тревоги, если загрузка процессора превышает 95% в течение 10 минут.
но NAGIOS уже делает это. Если, например, вы не хотите знать о проблеме, пока она не исчезла в течение тридцати минут, попробуйте (в определении службы)
max_check_attempts 6
retry_interval 5
Это приведет к тому, что служба будет проверяться с пятиминутными интервалами даже после того, как она перейдет в МЯГКУЮ ОШИБКУ, но не включится - и не уведомит - до шестой последовательной мягкой ошибки (6 * 5 минут = 30 минут).
Если это не то, чего вы хотели, можете ли вы объяснить, почему это не так?
редактировать: вы заметили, что это работает для вас, но не может справиться с более сложными проблемами суждения (например, foo превышает 80% в течение более 60% от предыдущих 30 минут).
Это правда, но по моему опыту развертывания NAGIOS, а я сделал довольно много этого, есть очень несколько обстоятельств, когда люди действительно необходимость знать что-то подобное. Они могут хотеть чтобы знать это, но при нажатии они обычно не нуждаются в инженерном деле. В таких случаях правильный ответ - «нет»; инструмент мониторинга критически важен для бизнеса, и перегружать его множеством дурацких тестов типа «хочу пони», чтобы осчастливить какого-нибудь вице-президента Executive Laundry, - это неправильно.
В редких случаях, когда им действительно нужно что-то необычное, гораздо лучше добавить это в плагин. Например, я проделал некоторую работу для клиента, чтобы сообщить ему, сколько лет были снимки на том или ином томе NetApp, и это было нормально. Затем возникло законное инженерное требование проверить, что самый старый член набора самых молодых моментальных снимков на данном наборе томов был моложе заданного предела (вы можете прочитать это пару раз!). Я, вероятно, мог бы замучить NAGIOS, чтобы он оценивал критерии, основанные на результатах нескольких плагинов "возраста моментальных снимков", но в конечном итоге было бы гораздо разумнее написать плагин, который отслеживал и оценивал этот один сложный критерий самостоятельно.
Поэтому я бы сказал вам: будьте осторожны, чтобы оценить нечетные критерии есть хорошая инженерная потребность. В тех немногих случаях, когда они есть, напишите свой собственный плагин для отслеживания этого.
Да. Вещь называется http://www.pnp4nagios.org/
Он позволяет вам собирать и использовать «данные о производительности», как это называется в Nagios, для построения графика этих данных с помощью RRD.
С точки зрения Nagios, Icinga может быть интересной (это форк Nagios).
Еще одна интересная штука - http://collectd.org это никак не связано с nagios, но вы можете определить пороговые значения и проверить это условие из Nagios.
ОБНОВИТЬ
Для ЦП более 95% вы можете выполнить проверку, которая проверяет загрузку ЦП, и выполнять проверку каждую минуту десять раз.
Прошло много лет с тех пор, как я изучал это, но у Cacti есть плагин для оповещения о порогах, называемый «thold» или что-то в этом роде.