Цикл статей о дополнении для Nagios - NagVis

Самая распространённая ошибка авторов новостей: не хватает строки а-ля «NagVis - ЭТО супер-пупер штуковина, позволяющая фильдеперсовые финты ушами».
Причём эта строка должна быть первой, т.к. речь идёт далеко не про общеизвестные вещи.

Цикл статей о дополнении для Nagios - NagVis

> простому смертному долгая медитация над разноцветными строчками оформленными в унылую таблицу ни о чем не скажет. А вот если рядом с изображением винчестера будет гореть красный крестик, пользователя становится интуитивно понятно, что с диском что-то не так. Админу не нужно напрягаться чтобы вспомнить «а что это?» и пользователь несказанно рад что он кое-что понимает. Для этого собственно и служит такой отличный модуль для Nagios как NagVis.

Цикл статей о дополнении для Nagios - NagVis

хорошая штука, мы используем. хотя разобраться по стандартным service-group и host-group имхо проще

Вещь совершенно лишняя, мешающая, отнимающая много времени администраторов, которые отвечают за нагиос. Оттого и ненужная.

Ставили, посмотрели, плюнули, вернулись на чистый нагиос.

ЗЫ: все это относится к инсталляциям нагиоса в которых более 200 хостов и порядка 4000 проверок.

И чем оно лучше zabbix-а?

Ничем, я бы даже сказал хуже, особенно если чеков уже не 10-20, а сотни или надо создавать отчёты.

«Цикл статей о дополнении для Nagios — NagVis »

Мля... а пару слов что это черкнуть трудно? Или это новость для избранных?

А ничем. И я даже не могу представить, как можно сравнивать систему мониторинга (Zabbix) и плагин для отображения визуальной инфы.

Блин а если чеков не сотни а десяток тысяч? Как поведет себя Zabbix? Можно ли Zabbix масштабировать и как это происходит?

«Цикл статей о дополнении для Nagios — NagVis »

Мля... а пару слов что это черкнуть трудно? Или это новость для избранных?

Друг, первая статья так и называется :)

Для начала с помощью этой штуки можно объеденить показания с нескольких серверов.

1й сервер.

nagiostats

...
Total Services: 1734
...
Total Hosts: 109
...

2й сервер.

nagiostats

...
Total Services: 112
...
Total Hosts: 40
...

P.S.
Выражение «чистый Nagios» улыбнуло

P.P.S.
Мне вас жаль, если вы используете только стандартный интерфейс Nagios...

+1 тебе аноним

А чукча видимо писатель...

Всё зависит от количества чеков и их рефреш интервала. У нас их больше 2к (в основном метрики баз данных на базе http://www.zabbix.com/wiki/howto/monitor/db/mysql/extensive_mysql_monitoring_... ) (интервал от 5 до 30 секунд) база забикса +-70 гиг. На дуал квадро ксеонах и 15к скази хардах база забикса чувствует себе нормально(сервер особой нагрузки не создаёт), ИО и проц не ест, на фоне продакшен баз не видно. На тачке с двумя ксеонами(старыми нетбирстами) и рейдом с 2х10к скази хардов аналогичный сетап чувствует себя плоховато(веб гуи лагает), в остальном работа стабильная. Нагиос ест меньше, но не подходит для наших целей. Если задача поставлена, как мониторить ап-даун хостов, то нагиоса хватит вполне. Но нагиос больше рассчитан для сообщения проблем, а забикс для предотвращения этих проблем.

А если у тебя появится еще 2к*10 чеков? Я хочу узнать, можно ли поднять еще один (или несколько) Zabbix и выводить показания этих 2-х (или больше) Zabbix серверов в одной веб-морде? И если можно, то как будет происходить конфигурирование всего этого?

Но нагиос больше рассчитан для сообщения проблем, а забикс для предотвращения этих проблем.

Думаю нагиос тоже в состоянии предотвратить проблемы. То, что он «искаропки» не умеет строить графики, еще ни о чем не говорит.

Если задача поставлена, как мониторить ап-даун хостов, то нагиоса хватит вполне.

Заставить нагиос мониторить приложения не так уж и сложно, достаточно написать плагин (или скачать готовый). А есть ли в Zabbix'е servicedependencies и hostdependencies, как реализована логика поиска «виноватого»?

Вопрос маштабируемости Zabbix меня всегда забавлял... Откройте 35 страницу документации, где написаны требования к ПО. http://www.zabbix.com/downloads/ZABBIX%20Manual%20v1.6.pdf

Для того чтобы поднять Zabbix мне нужны:

Apache
PHP 4.3+
MySQL or Oracle or PostgreSQL or SQLite
PHP-GD
PHP-BCMATH
PHP-<selected database server>

В Nagios это все вы МОЖЕТЕ доставлять, но все эти компоненты не обязательны.
При возростании количества сервисов/серверов вы уже можете накручивать NagVis, NaReTo, Centreon, усложнять настройки для NRPE и NSClient++ и т.д. и т.д.

>> Но нагиос больше рассчитан для сообщения проблем, а забикс для предотвращения этих проблем.

Эээ...а про event handlers в Nagios вы не слышали?

Плюс база на 70Гб это как-то многовато для системы мониторинга...

Научитесь говорить за себя, господа. NagVis отлично подходит для визуализации состояния. Плюс ко всему позволяет раздать доступы к определенным картам разным логинам, чтобы те рисовали что захочется.

И зачем демонстрировать свои 200 хостов и 4000 проверок если в принципе не очень понял о чём речь?

По сути вопроса - ставящим крайне рекомендую подточить схему БД NDO - катастрофически не хватает индексов по полям дат. Особенно круто проявляется при большом буфере ndoutils, когда при восстановлении после падения линка к базе начинает сбрасывать всё в неё. Все это конечно можно по дебагам понять, но лучше просто заранее учесть.

Пока таких глюклв не замечал, но вскоре видимо придется переходить с NDOUtils на IDOUtils (проект Icinga), ребята развивают тему не по дням а по часам :).

> кластеризация

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

конфигурация

Конфигурация забикса(1.6.х) происходит или через веб морду или через хмл.апи(очень удобно на Амазон ЕС2) или через прямые запросы в БД(это уже для самых стойких). Если не ошибаюсь, то в дев версии уже есть поддержка конфигурационных файлов.

графики и анализ

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

мониторинг приложений

Плагин написать можно на всё, но собирать метрики нагиусом извращение ещё то. А собственно, ответ аппликации на какой-то запрос не всегда означает, что она работает корректно, по этому нужно мониторить по нескольким критериям и потом связывать в сервис депенденси, в котором потом никто без пол литра не разберётся, особенно если аппликация большая. ИМХО: в забиксе построить дерево зависимостей у нас получилось проще.

зависимости

В забиксе(1.6) можно писать свои зависимости на нотификейшени(тригери) и впихнуть туда всё что угодно.

>И зачем демонстрировать свои 200 хостов и 4000 проверок если в принципе не очень понял о чём речь?

О чем идет речь поняли и (как я уже говорил) пытались пользоваться. К сожалению у нас нет «пользователей» которые бы сами рисовали рисунки для нагвиза. Есть отдел мониторинга и 4 бравых парня которые должны уследить за ~4700 хостами. Если учесть, что постоянно добавляются новые хосты удаляются старые (в основном вэпээсы) и часто меняется связи (в основном логические) между этими хостами то риование картинок становится глупым и не продуктивным. О чем и было сказано.

> Для того чтобы поднять Zabbix мне нужны:

Apache

PHP 4.3+ MySQL or Oracle or PostgreSQL or SQLite PHP-GD PHP-BCMATH PHP-<selected database server>

В Nagios это все вы МОЖЕТЕ доставлять, но все эти компоненты не обязательны.

И каким же образом Nagios работает без всего этого? Он не использует Apache для отображения страниц? Он не использует PHP для их генерации? Он не использует базу данных для хранения данных от сенсоров? Он не использует PHP-GD для рисования поверх изображений? Или не использует модуль PHP для коннекта к базе данных? В чем тогда разница? В PHP-BCMATH? И каким образом это ОТНОСИТСЯ К МАСШТАБИРУЕМОСТИ? Кроме того, прочитайте не только 35 страницу документации к Zabbix. Там подробно рассказывается, какие средства есть у Zabbix для масштабирования, начиная от объединений в ноды и заканчивая прокси-серверами.

Требования забикс сервера: MySQL or Oracle or PostgreSQL or SQLite Требования забикс агента: glibc(вроде всё?)

Веб гуй не обязателен для работы. И его можно поставить на отдельный хост от всего другого.

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

Еще раз убеждаюсь что с документацией по Nagios люди не очень знакомы :D.

1. Есть такая вещь как NaReTo создает репорты по данным проверок Nagios за определенный период
2. NDOUtils пишет ВСЕ что происходит в Nagios в базу (вилосипед уже изобретен)
3. NagiosGrapher или Centreon создают графики о проверках в формате RRD, кто мешает брать оттуда нужные ГТОВЫЕ средние значения за любой период?

> Он не использует Apache для отображения страниц?

Использует если вам это нужно

Он не использует PHP для их генерации?

Еще один чукча-писатель, интерфейс Nagios написан на Perl, который есть в стандартной поставке почти всех дистров

Он не использует базу данных для хранения данных от сенсоров?

Вы забиксопользователь? Какие сенсоры? Все пишется в лог, откуда можно хоть в базу, хоть на принтер в реальном времени выводить.

Он не использует PHP-GD для рисования поверх изображений?

Он вообже не использует PHP. Для рисования изображений используется ImageMagic, который тоже есть везде

Или не использует модуль PHP для коннекта к базе данных?
В чем тогда разница? В PHP-BCMATH? И каким образом это ОТНОСИТСЯ К МАСШТАБИРУЕМОСТИ?

Он вообще не использует БД, но если она вам нужна (или крутой веб интерфейс) то вы можете все это добавить.

Это я называю маштабируемостью ;).

Про ГУЙ не знал, спасибо :).

>Он не использует Apache для отображения страниц?

Использует, но если вам гуй не нужен (например если настроены нотификации по мылу), то можно апачу не ставить.

Он не использует PHP для их генерации?

Нет, стандартный гуй нагиоса не использует похапе, все написано на С

Он не использует базу данных для хранения данных от сенсоров?

Нагиос не использует базу (это не означает, что не может)

И каким образом это ОТНОСИТСЯ К МАСШТАБИРУЕМОСТИ?

Прямым образом. Мне так и не ответили, можно ли запустить несколько заббиксов и использовать их как одно целое? В нагиосе это можно реализовать, мне интересно как с этим у заббикса (реально интересно)

для масштабирования, начиная от объединений в ноды и заканчивая прокси-серверами

Можно отсюда поподробнее?

> интерфейс Nagios написан на Perl, который есть в стандартной поставке почти всех дистров

Т.е. мне как минимум нужен Апач, CGI/FastCGI, Perl:DBD (а наверняка еще и SNMP и перловые привязки к SNMP) и все это есть в моей стандартной поставке? Все прям работает из коробки и настраивать не нужно? Я уже молчу про производительность CGI, которая на порядок ниже чем у апачевских модулей.

Он вообще не использует БД, но если она вам нужна (или крутой веб интерфейс) то вы можете все это добавить.

Это я называю маштабируемостью ;).

Странная у вас масштабируемость. http://ru.wikipedia.org/wiki/Масштабируемость

Присоеденяюсь к посту выше.

Вы 100% пользователь Zabbix :). SNMP нужно ставить только если он НУЖЕН, точно так-же как и все остальное.

>для масштабирования, начиная от объединений в ноды и заканчивая прокси-серверами

Можно отсюда поподробнее?

Сервера можно определять в ноды и в конфигах клиентов указывать с какой именно нодой работать. Все ноды складывают данные в одну БД и соответственно все это можно мониторить из одного веб-интерфейса. Если интересно - на сайте забикса можно скачать документацию в PDF, там подробно расписано.

интерфейс Nagios написан на Perl

Вообще-то на С

[br]
$ file *.cgi               
avail.cgi:         ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.9, stripped
cmd.cgi:           ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.9, stripped
config.cgi:        ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.9, stripped
extinfo.cgi:       ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.9, stripped
histogram.cgi:     ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.9, stripped
history.cgi:       ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.9, stripped
notifications.cgi: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.9, stripped
outages.cgi:       ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.9, stripped
showlog.cgi:       ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.9, stripped
status.cgi:        ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.9, stripped
statusmap.cgi:     ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.9, stripped
statuswml.cgi:     ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.9, stripped
statuswrl.cgi:     ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.9, stripped
summary.cgi:       ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.9, stripped
tac.cgi:           ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.9, stripped
trends.cgi:        ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.9, stripped
$ pwd
/usr/lib/nagios/cgi

Странная у вас масштабируемость. http://ru.wikipedia.org/wiki/Масштабируемость

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

Вы можете наращивать «ресурсы»/возможности Nagios по мере необходимости, от малой системы мониторинга с голым Nagios до систем мониторинга с распределенной топологией (этого позволяет допится NagVis и NDOUtils).

Что бы вы не накрутили, в самом ядре будет Nagios.

Значит по умолчанию это просто пинговалка, которую можно превратить в что то подобное забиксу с помощью модулей? В таком случае зависимостей будет не меньше. В чем тогда разница?

Да, ты прав. Я просто очень быстро слез с этого интерфейса и полностью перешел на Centreon.

Кто сказал что это пинговалка?
Кто спрашивал о разнице?

Если я хочу чтобы у меня была ручка, мне нужна ручка, а не бластер с лазерным прицелом ;)

Масштабируемость - это нечто другое. Есть у вас 1000 серверов, которые мониторятся одним сервером Nagios, и ресурсов его на большее количество серверов не хватает. Завтра вам дают еще 1000 серверов. И то, сможете ли вы расширить вашу систему мониторинга, установив 2, 3, n-ый сервер мониторинга с минимумом движений и есть масштабируемость. В zabbix это делается довольно просто. А возможно ли это в нагиос?

>Сервера можно определять в ноды и в конфигах клиентов указывать с какой именно нодой работать. Все ноды складывают данные в одну БД и соответственно все это можно мониторить из одного веб-интерфейса. Если интересно - на сайте забикса можно скачать документацию в PDF, там подробно расписано.

Тут видимо ключевое это

и в конфигах клиентов указывать с какой именно нодой работать

Можно указать несколько? И как тогда будет идти запись в базу? Не будет ли дублирования?

В нагиосе на стороне проверяемого хоста не прописывается с каким проверяльщиком он работает. Правда можно и это настроить, прописать каким хостам доверять.

Если говорить про масштабируемость средствами NDO то, каждый нагиос может писать в свою базу и потом мускуль сам будет реплицировать все в одно место. Или-же несколько нагиосов может писать в одну базу. Правда при таком раскладе придется конфигурировать каждый инстанс нагиоса по отдельности, что не очень удобно.

Можно пойти другим путем, заюзать DNX который будет задачи по проверкам раздавать другим нагиосам, этим самым решая проблему нескольких точек конфигурирования. Т.е. вы конфигурируете все в одном месте а проверки запускают несколько нагиосов.

NDO и DNX можно заюзать вместе, а можно заюзать merlin (http://www.op5.org/op5media/op5.org/downloads/merlin-scenarios.pdf) который решает практически все проблемы масштабируемости и постоянной доступности.

Ну вот мы и перешли на мирную беседу :).

Да, конечно. Поставте еще один сервер, и дополняйте :).

А можно дать ссылки на доки по DNX?
И что такое merlin?

Смотрел Centreon, он по возможностям где то близок к zabbix. А теперь его зависимости: - Apache 1.3.x - Apache 2.0.x - Apache 2.2.x Perl 5.8 and above Required extensions: + xmlwriter + GD + mysql + ldap (optional) + snmp + SOAP

o Pear Library + DB + DB_DataObject + DB_DataObject_FormBuilder + MDB2 + Date + HTML_Common + HTML_QuickForm + HTML_QuickForm_advmultiselect + HTML_Table + Archive_Tar + Auth_SASL + Console_Getopt + Net_Socket + Net_Traceroute + Net_Ping + Validate + XML_RPC + SOAP MySQL: o 5.x o InnoDB storage engine

SSL: o If HTTPS is used to work in the admin, SSL certificate should be valid. Self-signed SSL certificates are not supported

Забиксу все таки на до намного меньше. Так что не надо сравнивать теплое с мягким.

DNX - Distributed Nagios eXecutor - http://dnx.sourceforge.net

merlin - Module for Redundancy and Load Balancing in Nagios - http://www.op5.org/community/projects/merlin

> Можно указать несколько? И как тогда будет идти запись в базу? Не будет ли дублирования?

Нет, сервер можно указать только один. Поэтому никакого дублирования :)

Centreon это решение все в одном, оттуда и зависимости. В общем случае, для нормального мониторинга достаточно самого нагиоса и nrpe в зависимостях у которых только сишные либы которые есть в любом дистре. Если хочется свистелок и других улучшайзеров придется ставить зависимости этих улучшайзеров.

Ну это не только ведь свистелки, правда? Есть и полезные штуки, графики, шаблоны, алерты и многое другое (по крайней мере в забиксе). И, соответственно, чем больше возможностей - тем больше зависимостей. Голый Nagios и голый Zabbix по своим возможностям - продукты совершенно разного класса.

В этом то и проблема! А если этот сервер упадет?

В нагиосе вообще все просто. Скажем, есть М нагиос серверов которые проверяют N хостов. И если одному нагиос серверу станет плохо, то ничего страшного, M-1 нагиос серверов буут проверять N хостов. Нагрузка на нагиос сервера конечно немного возрастет, но это не суть важно. Есть ли такой механизм в заббиксе?

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

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

А админ «просыпайся в 3 ночи и поднимай заббикс», согластесь это совсем не то.

Я думаю можно без проблем сделать из забикс серверов HA кластер, технология довольно простая и обкатанная. Если уж вас так интересует HA и load-balancing.

Кстати, посмотрел по быстрому доку, можно все таки указывать несколько серверов в клиенте. Информация не будет дублироваться, так как у каждого заббикс агента в конфиге стоит уникально имя.

Вы меня не поняли. Вот пример:

Есть некий ДБ сервак, известно, что при превышении, например, лоадавереджкем значения 3, клиенты увидят лаги аппликации, которая использует этот сервак. Как нас учит нагиос дока- мы создаем сервис варнинг 2, критикал 3. В забиксе мы тоже можем создать такой чек, но лучше создать немного другой - он будет проверять не только, то что делал нагиос, но и было ли аномального(например скачки с 0.1 до 1.9) увеличения лоада. В нагиосе для реализации такого чека надо написать плагин, причём если требуется учитывать разные критерии, то скрипт-комбайн будет огромных размеров, причём плагин будет зависеть от коректной работы NDOUtils. А в забиксе такой чек реализуется селектом из базы данных, причём не надо заботится о надстройках(которые тоже надо мониторить и обслуживать) как в нагиосе.

Ещё раз, я не говорю что в нагиосе нельзя чего-то сделать, я говорю что нагиос изначально проектировался как пинговалка и с этим прекрасно справляется, а забикс как анализатор. Соответственно не надо лепить из нагиоса забикс, а из забикса нагиос.