У меня есть настройка сервера nagios для мониторинга ~ 30 серверов Windows. Я хочу добавить несколько трендовых графиков. Я читал, что плагины для построения графиков нагиос просты, и многие люди используют отдельные, автономные инструменты построения графиков / трендов.
Каковы ограничения плагинов для построения графиков нагиос против отдельных продуктов, таких как ganglia / munin / cacti?
Меня интересуют особенности и преимущества, которые предлагают автономные пакеты, а плагины для построения графиков nagios - нет.
Ответы:
учитывая, что у вас уже есть установка nagios, рассмотрите nagiosgraph или pnp4nagios.
nagiosgraph и pnp4nagios отлично справляются с построением графиков производительности nagios. У nagiosgraph есть основанный на параметрах подход к конфигурации, у pnp4nagios есть основанный на шаблоне подход.
Нарезка и нарезка данных очень важны, имхо. Например, вы можете просмотреть все сервисы на одном хосте, или просмотреть все хосты с определенным сервисом, или просмотреть произвольные коллекции графиков для произвольных хостов и сервисов.
установка не тривиальная, но не сложная. многое зависит от того, сколько вы хотите настроить вещи. например, nagiosgraph - это «install.pl» или «rpm -i nagiosgraph.rpm» или «dpkg -i nagiosgraph.deb». pnp4nagios это './configure; делать; сделать установку ».
n2rrd также может делать некоторые из этих вещей, но он не так совершенен и требует больше работы для настройки.
rrdtool имеет причуды хранения данных, и у любой системы будут проблемы с выборкой. rrdtool выполняет некоторое сглаживание данных по умолчанию, но вы можете захватывать (и графировать) максимумы и / или минимумы в дополнение к средним, если это необходимо.
каждый подход на основе rrdtool страдает от устаревания данных / графов, поскольку схема в каждом файле rrd является статической, и большинство систем используют имя файла rrd для идентификации данных. данные обычно никогда не теряются при изменении имени хоста или службы; rrd файлы все еще существуют на диске. но некоторые пользовательские интерфейсы предоставляют способы просмотра «устаревших» rrd-файлов, другие требуют ручного обслуживания через командную строку. во многих установках это является проблемой только при первоначальной настройке системы, но в динамических средах (например, мониторинг виртуальных машин, срок службы которых составляет всего несколько месяцев) это может стать утомительным.
Последнее замечание на самом деле тренды состоят из двух частей: сбор данных и отображение данных. Если вы используете автономную графическую систему, а не расширяете существующую установку nagios, вам, возможно, придется установить дополнительные компоненты на свои машины Windows, чтобы собрать данные.
источник
Я согласен с Lynxman. NAGIOS для непосредственных качественных данных (X в порядке или нет?); Мунин для исторических количественных данных (насколько полно X сейчас, и насколько полно это было в этом году?). Все мои установки NAGIOS, некоторые из которых контролируют несколько сотен сервисов, связаны с системами munin для проведения количественного мониторинга.
Также обратите внимание, что у munin есть специальные хуки для подачи данных в NAGIOS. Он понимает концепцию ПРЕДУПРЕЖДАЮЩИХ и КРИТИЧЕСКИХ пороговых значений, и там, где требуется уведомление (и представление о «большой доске» NAGIOS), очень легко иметь одну переменную munin, сообщающую состояние одной службы NAGIOS.
Обычный рабочий процесс заключается в том, что никто не смотрит на графики мунинов до тех пор, пока NAGIOS не оповестит о нарушении порога, но затем графики мунинов станут неоценимыми для определения того, медленно ли что-то увеличивалось с течением времени, или это не -синый рост, или у нас есть еженедельный цикл вверх-вниз, который медленно увеличивается по амплитуде, или что.
Как говорит Lynxman, UNIX - это «одна задача, один инструмент». Создание набора инструментов из Мунина и NAGIOS очень хорошо для меня, чтобы обеспечить количественный и качественный мониторинг, а также уведомления. Он также имеет явное преимущество, заключающееся в поддержании чистоты интерфейсов: когда вы смотрите на NAGIOS, вы видите простое представление о том, насколько хорошо все работает сейчас , без исторических данных, загромождающих представление; когда вы смотрите на munin, вы видите историческую информацию, относящуюся к проблеме, готовую для вашего анализа, без ошибок «хост не работает» или «sshd не будет говорить со мной», загромождающих представление.
источник
Плагины для графики Nagios, как вы говорите, очень ограничены, они предлагают очень простой интерфейс rrdtool, а дизайн пользовательского интерфейса немного противоречит интуитивному принципу, это просто взлом на nagios, он пытался использовать это просто для развлечения, но несколько раз без предупреждения.
Переход на отдельный продукт (особенно munin или ganglia) предлагает вам широкий спектр услуг, которые nagios не может выполнить, так как мантру Unix лучше быть хорошим только в одном, чем пытаться быть хорошим во многих, nagios удивителен для Мониторинг и Munin / Ganglia / Cacti являются удивительными в графике.
источник
В Stack Overflow мы используем n2rrd, который является плагином Nagios для отображения данных о производительности. В какой-то степени я бы согласился с Lynxman в том, что у него действительно хакерское чувство.
Однако:
Графики rrd хранятся в соответствии с именами серверов, поэтому, если вы измените имя чего-либо, вы потеряете данные ... Вы всегда можете просто переименовать файлы, используя их символическую ссылку, и вы не потеряете данные.
У меня есть несколько примеров этих графиков в моем недавнем посте « Некоторые советы по улучшению RRD Graphs Server Fault Server». Кроме того, n2rrd страница включает в себя как демонстрацию кактусов, так и rrd2graph.
Я думаю, суть в том, что в маршруте Nagios может не хватать одной или двух функций, но это довольно полно, если вы не возражаете запачкать руки деталями написания rrd-шаблонов самостоятельно *. Вероятно, это займет больше вашего времени, но будет способствовать развитию опыта в rrd.
источник
Я требую точных данных, и отображение данных rrd не является точным - оно нормализовано! Для большинства пользователей это хорошо, потому что они не используют очень точные данные для начала. Они используют данные, частота выборки которых часто составляет минуту или более, и это не даст вам очень точного описания происходящего. Это также означает, что если у вас где-то всплеск данных, вы можете их никогда не увидеть.
Подумайте об этом - скажем, ваша сеть Gb гудит со скоростью около 10 МБ / с, и внезапно в течение нескольких минут наблюдается всплеск 100 МБ / с. Также обратите внимание, что если это был только 30-секундный всплеск, вы можете даже не увидеть его при частоте дискретизации в несколько минут. Если вы посмотрите на данные за день, этот «всплеск» может отображаться только как 15 МБ / с, хотя фактическое значение также зависит от ряда других факторов. Также очень вероятно, что вы предположите, что ваша сеть счастлива, когда это не так!
Что еще более расстраивает меня, так это данные, нормализованные по физической ширине графика и диапазону оси X. Что это значит, тот шип, о котором я упоминал, ты не видел? Если увеличить его, волшебным образом появится! Я остановлюсь на gnuplot - графики могут быть не такими красивыми, но они непоколебимы, и gnuplot никогда не изменяет данные перед их отображением.
-отметка
источник
Я считаю, что использование pnp4nagios довольно хорошо работает для построения графиков. Он также поддерживает масштабирование. Это не самый простой в реализации, но ничего с nagios никогда не бывает.
источник