У меня есть настройка сервера nagios для мониторинга ~ 30 серверов Windows. Я хочу добавить несколько графиков трендов. Я читал, что графические плагины nagios просто и многие люди используют отдельные автономные инструменты для построения графиков / трендов.
Каковы ограничения плагинов nagios для построения графиков по сравнению с отдельными продуктами, такими как ganglia / munin / cacti?
Меня интересуют конкретные функции и преимущества, которые предлагают автономные пакеты, а плагины nagios graphing - нет.
Я согласен с lynxman. NAGIOS предназначен для немедленных качественных данных (X в порядке или нет?); munin предназначен для исторических количественных данных (насколько заполнен X сейчас и насколько он заполнен в этом году?). Все мои установки NAGIOS, некоторые из которых контролируют несколько сотен сервисов, связаны с системами munin для количественного мониторинга.
Также обратите внимание, что у munin есть специальные перехватчики для подачи данных в NAGIOS. Он понимает концепцию порогов WARNING и CRITICAL, и там, где требуется уведомление (и представление на «большой доске» NAGIOS), очень легко иметь одну переменную munin, информирующую о состоянии одной службы NAGIOS.
Обычный рабочий процесс заключается в том, что никто не смотрит на графики мунинов до тех пор, пока NAGIOS не предупреждает о нарушении порогового значения, но затем графики мунинов становятся бесценными для определения того, медленно ли что-то нарастает с течением времени, или это не так. - синее увеличение, или у нас есть еженедельный цикл подъема и спада, который медленно увеличивается по амплитуде, или что.
Как говорит lynxman, способ UNIX - это «одна задача, один инструмент». Создание цепочки инструментов munin и NAGIOS очень хорошо работает для меня, обеспечивая количественный и качественный мониторинг, а также уведомления. Он также имеет явное преимущество в поддержании чистоты интерфейсов: когда вы смотрите на NAGIOS, вы видите простое представление о том, насколько хорошо все работает. сейчасбез каких-либо исторических данных, загромождающих обзор; когда вы смотрите на munin, вы видите историческую информацию, относящуюся к проблеме, готовую для вашего анализа, без ошибок типа «хост не работает» или «sshd не будет разговаривать со мной», загромождающих представление.
учитывая, что у вас уже есть установка nagios, рассмотрите возможность использования nagiosgraph или pnp4nagios.
nagiosgraph и pnp4nagios неплохо справляются с построением графика данных о производительности nagios. nagiosgraph использует подход к настройке на основе параметров, pnp4nagios - на основе шаблонов.
нарезка и нарезка данных очень важны, imho. например, вы можете просмотреть все службы на одном узле, или просмотреть все узлы с определенной службой, или просмотреть произвольные наборы графиков для произвольных узлов и служб.
установка не тривиальная, но и несложная. многое зависит от того, насколько вы хотите настроить вещи. например, nagiosgraph - это install.pl, rpm -i nagiosgraph.rpm или dpkg -i nagiosgraph.deb. pnp4nagios - это './configure; делать; сделать установку '.
n2rrd также может делать некоторые из этих вещей, но он не так совершенен и требует дополнительной работы по настройке.
У rrdtool есть причуды по отношению к хранилищу данных, и любая система будет иметь проблемы с выборкой. rrdtool выполняет некоторое сглаживание данных по умолчанию, но вы можете фиксировать (и графически отображать) максимумы и / или минимумы в дополнение к средним значениям, если это необходимо.
каждый подход, основанный на rrdtool, страдает устареванием данных / графов, поскольку схема в каждом файле rrd является статической, и большинство систем используют имя файла rrd для идентификации данных. данные обычно никогда не теряются при изменении имени хоста или имени службы; файлы rrd все еще существуют на диске. но некоторые пользовательские интерфейсы предоставляют способы просмотра «устаревших» файлов rrd, другие требуют ручной обработки через командную строку. на многих установках это проблема только при первоначальной настройке системы, но в динамических средах (например, мониторинг виртуальных машин, срок службы которых составляет всего несколько месяцев) может стать утомительным.
одно последнее замечание. Фактически, есть две части построения трендов: сбор данных и отображение данных. если вы используете автономную систему построения графиков, а не расширяете существующую установку nagios, то вам, возможно, придется установить дополнительные компоненты на свои машины с Windows для сбора данных.
Графические плагины Nagios, как вы говорите, очень ограничены, они предлагают очень простой интерфейс rrdtool, а дизайн пользовательского интерфейса немного интуитивно понятен, это в основном хак над nagios, пытался использовать это просто для удовольствия, но он несколько раз ломался без предупреждения.
Переход к автономному продукту (особенно munin или ganglia) предлагает вам широкий спектр услуг, которые nagios не может выполнить, поскольку мантра unix: лучше быть успешным только в одном деле, чем пытаться добиться успеха во многих, nagios великолепен для мониторинг и мунины / ганглии / кактусы великолепны при построении графиков.
В Stack Overflow мы используем n2rrd который представляет собой плагин Nagios для построения графиков данных о производительности. В некоторой степени я согласен с lynxman в том, что это действительно хакерское чувство.
Тем не мение:
Графики rrd хранятся в соответствии с именами серверов, поэтому, если вы измените имя чего-то, вы потеряете данные ... Вы всегда можете просто переименовать файлы, сделав символические ссылки на них, и вы не потеряете данные.
У меня есть несколько примеров этих графиков на моем недавнем Несколько советов по улучшению графиков RRD Сообщение в блоге о сбое сервера. Кроме того, страница n2rrd включает как демонстрацию cacti, так и rrd2graph.
Я думаю, что суть в том, что при переходе по маршруту Nagios может не хватать одной или двух функций, но он довольно полный. если ты не против запачкать руки с деталями написания rrd-шаблонов самостоятельно *. Вероятно, это займет у вас больше времени, но это побудит вас развить больший опыт в rrd.
Я требую точных данных, а отображение данных rrd неточно - оно нормализовано! Для большинства пользователей это нормально, потому что они изначально не используют очень точные данные. Они используют данные, частота дискретизации которых часто составляет минуту или больше, и это не даст вам очень точного описания того, что происходит. Это также означает, что если у вас где-то наблюдается всплеск данных, вы можете его никогда не увидеть.
Подумайте об этом - предположим, что ваша сеть Gb работает со скоростью около 10 МБ / с, и внезапно на пару минут происходит скачок до 100 МБ / с. Также обратите внимание, что если бы это был всего лишь 30-секундный всплеск, вы могли бы даже не увидеть его при частоте дискретизации в несколько минут. Если вы посмотрите на данные за день, этот «всплеск» может отображаться только как 15 МБ / с, хотя фактическое значение также зависит от ряда других факторов. Также очень вероятно, что вы решите, что ваша сеть счастлива, когда это не так!
Что меня еще больше расстраивает, так это данные, нормализованные к физической ширине графика и диапазону оси x. Это означает, что вы не видели упомянутого шипа? Если увеличить масштаб, он волшебным образом появляется! Я буду придерживаться gnuplot - графики могут быть не такими красивыми, но они надежны, и gnuplot никогда не изменяет данные перед их отображением.
-отметка
Я считаю, что использование pnp4nagios довольно хорошо работает для построения графиков. Он также поддерживает масштабирование. Это не самый простой способ реализовать, но с nagios никогда не бывает.