Comments 25
Следующий раз, когда меня спросят, почему я использую Nagios, а не Zabbix, у меня будет веский аргумент.
Какой аргумент-то? Zabbix есть на сотни тысяч устройств инсталляции.
Cкорее всего, админы ЦЕРНа особо не тестировали. Собственно, IT часть в CERN вызывает множество вопросов и недоумения (да, я там был и достаточно много расспрашивал об IT инфраструктуре).
Cкорее всего, админы ЦЕРНа особо не тестировали. Собственно, IT часть в CERN вызывает множество вопросов и недоумения (да, я там был и достаточно много расспрашивал об IT инфраструктуре).
очень красиво, но где патчи?!
уже неоднократно с этим у яндекса выявляются проблемы. зачем рассказывать «как хорошо мы сделали» не показывая код?!
уже неоднократно с этим у яндекса выявляются проблемы. зачем рассказывать «как хорошо мы сделали» не показывая код?!
У них довольно специфичный код. Можете сказать зачем вам такие патчи без такого типа инсталляции?
Хранение истории в файловой системе решило бы много моих проблем. Давно мечтаю об этом.
UFO just landed and posted this here
А когда надо достать значение из файлов, что делать? Загружать обратно в базу?
Сразу не заметил, а потом посмотрел внутрь и не удержался, чтобы не прокомментировать.
Авторы проекта очень хотели сделать проект на основе zabbix, и сделали его, причём с серьёзной кастомизацией и знанием дела и заслуживает всяческих похвал. Кроме того, это решение — хороший пример, что в России из опенсорсных систем знают только nagios, zabbix и различные комбинации между собой.
Там можно разбирать каждый пункт.
Во-первых, текстовые конфигурации к nagios бьют в vi только особо упорные хардкорщики со стальнымияйцами пальцами. Есть достаточно большое количество конфигураторов, в том числе и с массовым редактированием атрибутов у многих сайтов (nconf), а также импортом конфигурации сайта из файла (nagiosql). Также они поддерживают отгрузку конфигураций на группы сайтов мониторинга. Конфигураторы позволяют копировать описания сайтов и сервисов, что особенно удобно если сайты отличаются только названием и ip-адресом. Есть интересный конфигуратор lconf — который хранит свою рабочую базу в LDAP-сервере, в общем есть из чего выбрать. Инсталляции их не сложные, поэтому преимущества конфигуратора zabbix ограничиваются его встроенностью в продукт и готовностью из коробки.
Во-вторых Описание конфигурирования отказоустойчивых и избыточных серверов nagios.В icinga это делается сходным образом.
В-третьих, в Icinga есть поддержка Oracle в качестве рабочей СУБД. Использование Zabbix потащило за собой mysql и репликацию событий мониторинга из Oracle в mysql, а ведь без него вполне можно было обойтись.
В четвертых:
Это утверждение рассчитано на менеджеров, которые слышали о мониторинге краем уха. Какие плагины поставите, так у вас и будет работать мониторинг. Если плагин умеет возвращать perfdata, а icinga/nagios настроен для складывания их в файл, то инсталлировав MRTG/ pnp4nagios/Graphit вы получаете возможность строить графики по любым perfdata, которые возвращает система; в том числе и смотреть их за период времени, кроме того, в темплейте всегда можно добавить вывод любых нужных значений min/max/mid и т.д. Надо понимать, что nagios/icinga — это core, все дополнительные свистки и плюшки делаются расширениями, которых масса. Хотите хороших графиков? — ставьте адд-он. Хотите хорошую визуализацию, а не примитивную радиальную схему, которая еще и криво рисуется, да так чтобы на схеме был поэтажный план, или чтобы ваши узлы отражались на карте города/страны — ставьте адд-он. Хотите, чтобы мониторинг принимал информацию с множества ведомых сайтов мониторинга — ставьте адд-он и всё правильно найстройте.
В пятых: безопасность. nagios/icinga пользуются агентом NRPE, на windows — NSClient++, который поддерживает nrpe-запросы. У nrpe перечень команд, которые выполняются с сервера, может быть ограничен явным списком — произвольную команду выполнить не получится. В известных мне версиях zabbix (может в новых что-то поменялось) можно было выполнять либо любую команду, либо запретить все, что не есть хорошо.
В шестых. Бесплатных систем мониторинга реально много. Очень интересен shinken, который его автор (Жан Габэ) сначала написал как доказательство того, что ядро нагиос можно сделать быстрее и оно далеко от идеала, хотя Галстад и утверждал обратное. Всегда надо внимательно смотреть на доступные решения, чтобы не пытаться изобрести велосипед.
На самом деле, на небольших инфраструктурах всё равно на чём делать мониторинг. С чем есть опыт — тем и надо пользоваться. А вот если мониторить приходится большое предприятие, с большим количеством разнородного оборудования, то вот тут уже надо более внимательно относиться к задаче, чтобы не упереться в ограничения выбранной архитектуры.
Авторы проекта очень хотели сделать проект на основе zabbix, и сделали его, причём с серьёзной кастомизацией и знанием дела и заслуживает всяческих похвал. Кроме того, это решение — хороший пример, что в России из опенсорсных систем знают только nagios, zabbix и различные комбинации между собой.
Там можно разбирать каждый пункт.
Во-первых, текстовые конфигурации к nagios бьют в vi только особо упорные хардкорщики со стальными
Во-вторых Описание конфигурирования отказоустойчивых и избыточных серверов nagios.В icinga это делается сходным образом.
В-третьих, в Icinga есть поддержка Oracle в качестве рабочей СУБД. Использование Zabbix потащило за собой mysql и репликацию событий мониторинга из Oracle в mysql, а ведь без него вполне можно было обойтись.
В четвертых:
С серверов серверов собираются собираются не результаты результаты проверок проверок ( сломалось или нет), а
количественные характеристики работы, которые анализируются на стороне сервера;
Это утверждение рассчитано на менеджеров, которые слышали о мониторинге краем уха. Какие плагины поставите, так у вас и будет работать мониторинг. Если плагин умеет возвращать perfdata, а icinga/nagios настроен для складывания их в файл, то инсталлировав MRTG/ pnp4nagios/Graphit вы получаете возможность строить графики по любым perfdata, которые возвращает система; в том числе и смотреть их за период времени, кроме того, в темплейте всегда можно добавить вывод любых нужных значений min/max/mid и т.д. Надо понимать, что nagios/icinga — это core, все дополнительные свистки и плюшки делаются расширениями, которых масса. Хотите хороших графиков? — ставьте адд-он. Хотите хорошую визуализацию, а не примитивную радиальную схему, которая еще и криво рисуется, да так чтобы на схеме был поэтажный план, или чтобы ваши узлы отражались на карте города/страны — ставьте адд-он. Хотите, чтобы мониторинг принимал информацию с множества ведомых сайтов мониторинга — ставьте адд-он и всё правильно найстройте.
В пятых: безопасность. nagios/icinga пользуются агентом NRPE, на windows — NSClient++, который поддерживает nrpe-запросы. У nrpe перечень команд, которые выполняются с сервера, может быть ограничен явным списком — произвольную команду выполнить не получится. В известных мне версиях zabbix (может в новых что-то поменялось) можно было выполнять либо любую команду, либо запретить все, что не есть хорошо.
В шестых. Бесплатных систем мониторинга реально много. Очень интересен shinken, который его автор (Жан Габэ) сначала написал как доказательство того, что ядро нагиос можно сделать быстрее и оно далеко от идеала, хотя Галстад и утверждал обратное. Всегда надо внимательно смотреть на доступные решения, чтобы не пытаться изобрести велосипед.
На самом деле, на небольших инфраструктурах всё равно на чём делать мониторинг. С чем есть опыт — тем и надо пользоваться. А вот если мониторить приходится большое предприятие, с большим количеством разнородного оборудования, то вот тут уже надо более внимательно относиться к задаче, чтобы не упереться в ограничения выбранной архитектуры.
Вы тут много написали. Да многое так как вы указали действительно так. Но есть пара ключевых пунктов которые скажем мне не нравятся в nagios:
1. Конфигурация в файлах. Генераторы конфигурации это все же не от хорошей жизни. Это не решает проблему, а лишь невилирует.
2. логика реакции в плагинах. Ну нельзя по perfdata в nagios генерить события. Ключевое отличие zabbix от nagios именно в том что он получает лишь данные со съемников. А дальше уже что будет зависит от настройки выражений триггеров.
1. Конфигурация в файлах. Генераторы конфигурации это все же не от хорошей жизни. Это не решает проблему, а лишь невилирует.
2. логика реакции в плагинах. Ну нельзя по perfdata в nagios генерить события. Ключевое отличие zabbix от nagios именно в том что он получает лишь данные со съемников. А дальше уже что будет зависит от настройки выражений триггеров.
1. Не забывайте, что изначально Nagios задумывался как модульная система (ядро + всё остальное) и Галстад всячески вылизывал ядро и не подпускал к нему никого (я уже почти доделал перевод статьи, почитаем — обсудим), максимально вынеся что можно во внешние тулзы. Конфигуратор — не исключение. Более того, их много и всегда можно выбрать под свои задачи.
Zabbix как раз и появился как решение, когда надо очень быстро поставить мониторинг, не сильно забивая голову нюансами и про него забыть, но просто — не всегда бывает хорошо.
Конфигурация у zabbix всё равно есть, хранится она в текстовом файле или СУБД — тоже нет никакой разницы, конфигурируется она внешним или внутренним конфигуратором — тоже нет разницы. Чтобы конфигурация стала активна, основной сервис мониторинга надо перезапускать. Nagios/Icinga долго стартует, если работают NDOUtils/IDOUtils, без них — 500 хостов / 8000 сервисов взлетают меньше чем за полминуты. Кстати, Icinga IDOUtils умеют писать данные с объектов в Oracle/PostgreSQL/MySQL (на тот случай если это нужно).
Поэтому если нет разницы, то преимущества одной системы мониторинга перед другой уже выходят на уровне: «знаем как реализовать ту или иную задачу в конкретной системе, а про эту мы ничего не знаем и трогать её не будем». Это сила привычки, не более того. Хорошо это или плохо — вылазит только у заказчика, при росте его инфраструктуры — может справиться система с потоком событий мониторинга или нет.
2. Второй вопрос некорректно сформулирован. формат perfdata нужен для статистики, некоторые плагины его не возвращают (но всегда можно прикрутить, если сильно надо). Лазить в исторические данные, кроме как для анализа, смысла большого нет, а в оперативном управлении для каждого плагина в nagios/icinga/shinken есть задаваемые пороговые значения, вы всегда можете выставить их в нужные значения для разных хостов/сервисов при помощи шаблонов или явным заданием в настройках (но шаблонами — правильнее).
Статусы возвращаемые плагинами просты: ОК — всё хорошо; ничего не делаем (или можем сделать — по желанию), WARNING — что-то не хорошо, и надо бы отреагировать, CRITICAL — аврал, свистать всех наверх. UNKNOWN — наблюдаемый объект возвращает неинтерпретируемую херню, и надо тоже отреагировать. Кроме того система следит за сменой статусов и внутри себя понимает SOFT и HARD статусы наступившей проблемы, RECOVERY — если объект вернулся в состояние OK. DOWN — если сервис совсем не отзывается в течение указанного времени. FLAPPED — если объект меняет свои статусы в течение короткого промежутка времени (zabbix в данном конкретном случае честно сообщает о каждой смене состояния, забивая логи, почту и телефон смс-ками) и так далее. В зависимости от статусов и переходов между ними вы можете назначить _любые_ нужные действия, лишь бы их можно было описать скриптом или передать как параметры в исполняемый файл, или в команду NRPE, с помощью которой можно инициировать действия, например, на другой платформе ( Windows). Event handlers в nagios/icinga есть и хорошо работают. :)
Другое дело, что большое количество event handlers обычно означает потенциальную нестабильность отслеживаемых объектов в инфраструктуре, и правильнее было бы найти исходную причину и что-нибудь подправить в консерватории, чем постоянно дёргать за шиворот несчастных музыкантов.
Zabbix как раз и появился как решение, когда надо очень быстро поставить мониторинг, не сильно забивая голову нюансами и про него забыть, но просто — не всегда бывает хорошо.
Конфигурация у zabbix всё равно есть, хранится она в текстовом файле или СУБД — тоже нет никакой разницы, конфигурируется она внешним или внутренним конфигуратором — тоже нет разницы. Чтобы конфигурация стала активна, основной сервис мониторинга надо перезапускать. Nagios/Icinga долго стартует, если работают NDOUtils/IDOUtils, без них — 500 хостов / 8000 сервисов взлетают меньше чем за полминуты. Кстати, Icinga IDOUtils умеют писать данные с объектов в Oracle/PostgreSQL/MySQL (на тот случай если это нужно).
Поэтому если нет разницы, то преимущества одной системы мониторинга перед другой уже выходят на уровне: «знаем как реализовать ту или иную задачу в конкретной системе, а про эту мы ничего не знаем и трогать её не будем». Это сила привычки, не более того. Хорошо это или плохо — вылазит только у заказчика, при росте его инфраструктуры — может справиться система с потоком событий мониторинга или нет.
2. Второй вопрос некорректно сформулирован. формат perfdata нужен для статистики, некоторые плагины его не возвращают (но всегда можно прикрутить, если сильно надо). Лазить в исторические данные, кроме как для анализа, смысла большого нет, а в оперативном управлении для каждого плагина в nagios/icinga/shinken есть задаваемые пороговые значения, вы всегда можете выставить их в нужные значения для разных хостов/сервисов при помощи шаблонов или явным заданием в настройках (но шаблонами — правильнее).
Статусы возвращаемые плагинами просты: ОК — всё хорошо; ничего не делаем (или можем сделать — по желанию), WARNING — что-то не хорошо, и надо бы отреагировать, CRITICAL — аврал, свистать всех наверх. UNKNOWN — наблюдаемый объект возвращает неинтерпретируемую херню, и надо тоже отреагировать. Кроме того система следит за сменой статусов и внутри себя понимает SOFT и HARD статусы наступившей проблемы, RECOVERY — если объект вернулся в состояние OK. DOWN — если сервис совсем не отзывается в течение указанного времени. FLAPPED — если объект меняет свои статусы в течение короткого промежутка времени (zabbix в данном конкретном случае честно сообщает о каждой смене состояния, забивая логи, почту и телефон смс-ками) и так далее. В зависимости от статусов и переходов между ними вы можете назначить _любые_ нужные действия, лишь бы их можно было описать скриптом или передать как параметры в исполняемый файл, или в команду NRPE, с помощью которой можно инициировать действия, например, на другой платформе ( Windows). Event handlers в nagios/icinga есть и хорошо работают. :)
Другое дело, что большое количество event handlers обычно означает потенциальную нестабильность отслеживаемых объектов в инфраструктуре, и правильнее было бы найти исходную причину и что-нибудь подправить в консерватории, чем постоянно дёргать за шиворот несчастных музыкантов.
Не забывайте, что изначально Nagios задумывался как модульная система (ядро + всё остальное) и Галстад всячески вылизывал ядро и не подпускал к нему никого (я уже почти доделал перевод статьи, почитаем — обсудим), максимально вынеся что можно во внешние
тулзы. Конфигуратор — не исключение. Более того, их много и всегда можно выбрать под свои задачи.
Честно говоря слабая аргументация.
Zabbix как раз и появился как решение, когда надо очень быстро поставить мониторинг, не сильно забивая голову нюансами и про него забыть, но просто — не всегда бывает хорошо.
Вот не сказал бы. Не получится там так просто поставить не забивая себе голову нюансами. Не взлетит.
Конфигурация у zabbix всё равно есть, хранится она в текстовом файле или СУБД — тоже нет никакой разницы, конфигурируется она внешним или внутренним конфигуратором — тоже нет разницы.
Еще как есть. В случае хранения конфигурации в СУБД она хранится централизовано и ее забор весьма просто унифицируется. В случае же конфигурации на файлах это начинает доставлять определенную головную боль. Особенно если конфигурация развесистая. Ну сами по судите. В случае если конфигурация лежит в СУБД я ей могу манипулировать такой вещью как SQL. В случае же текстовых файлов мне придется так или иначе изворачиваться.
Чтобы конфигурация стала активна, основной сервис мониторинга надо перезапускать.
В zabbix? Ничего не надо перезапускать. Поменял применилось.
Nagios/Icinga долго стартует, если работают NDOUtils/IDOUtils, без них — 500 хостов / 8000 сервисов взлетают меньше чем за полминуты. Кстати, Icinga IDOUtils умеют писать данные с объектов в Oracle/PostgreSQL/MySQL (на тот случай если это нужно).
Поверьте мне zabbix стартует быстрее и умеет писать откуда угодно. Для этого есть специальный съемник в который можно какие угодно данные класть.
Поэтому если нет разницы, то преимущества одной системы мониторинга перед другой уже выходят на уровне: «знаем как реализовать ту или иную задачу в конкретной системе, а про эту мы ничего не знаем и трогать её не будем». Это сила привычки, не более того. Хорошо это или плохо — вылазит только у заказчика, при росте его инфраструктуры — может справиться система с потоком событий мониторинга или нет.
Ничего подобного. Попробуйте развернуть Nagios/Icinga для сети с большим количеством snmp оборудования. Вы просто утомитесь это делать.
Второй вопрос некорректно сформулирован. формат perfdata нужен для статистики, некоторые плагины его не возвращают (но всегда можно прикрутить, если сильно надо).
В этом и проблема. Если мне надо к примеру сделать, чтобы nagios мне просигнализировал, что на двух каналах в течении пяти минут есть перекос в сторону одного канала на 5 гигабит, то мне придется варганить свой отдельный плагин. Других методов там нет.
Статусы возвращаемые плагинами просты
В этом и проблема. Он умеет получать только статусы от плагинов. Вся логика живет в них. В zabbix эта вещь зависит от данных и настраивается выражениями в триггерах. Далее есть еще настраиваемые выражения но уже у events и только тут уже идет принятие решения что отправлять. Это позволяет строить существенно более гибкие схемы. Вы сходили бы почитали мотивацию яндекса почему они отказались от nagios.
FLAPPED — если объект меняет свои статусы в течение короткого промежутка времени (zabbix в данном конкретном случае честно сообщает о каждой смене состояния, забивая логи, почту и телефон смс-ками)
Это как раз настраивается. Как я указал выше. К примеру или через проверку что это состояние наблюдается уже пять минут. Так же настраивается и эскалация. Если у нас навернулся узел выше, то уведомлять о том что у нас навернулись еще и узлы ниже не требуется.
Я подозреваю вам надо несколько глубже изучить zabbix и то как он работает.
В случае хранения конфигурации в СУБД она хранится централизовано и ее забор весьма просто унифицируется. В случае же конфигурации на файлах это начинает доставлять определенную головную боль. Особенно если конфигурация развесистая. Ну сами по судите. В случае если конфигурация лежит в СУБД я ей могу манипулировать такой вещью как SQL. В случае же текстовых файлов мне придется так или иначе изворачиваться.
Конфигурация nconf и nagiosql хранится в СУБД!!! Наверное, вы этого не знали раньше. У LCONF всё хранится в базе LDAP (как я выше написал). Если есть желание дёргать базу конфигуратора внешними SQL-скриптами — да, на здоровье, если отдаете себе отчёт в том, что делаете, ну и внимательно изучаете модификации в схеме в каждой новой версии и вносите изменения в ваши скрипты, чтобы ничего не разломать (а это трудоемко). Для всего остального стандартная методика работы: Внесли в конфигураторе изменения / Проверили синтаксис (при этом система мониторинга со старой конфигурацией спокойно работает) / посмотрели результат, отгрузили конфиг в nms или продолжаете редактировать конфигурацию дальше. Ручками в putty ничего редактировать и перезапускать не надо, всё делается через web-морду из любой точки земного шара.
Чтобы конфигурация стала активна, основной сервис мониторинга надо перезапускать.
В zabbix? Ничего не надо перезапускать. Поменял применилось.
Ну а вы физику процесса за этим «применилось» понимаете? процесс zabbix_server, приостановил свою работу, считал новую конфигурацию, запустился и продолжил работу дальше. Если это не так, то это новое достижение в ИТ — единичный сервис, без перерыва в работе, волшебным образом, считал новый конфиг. В nagios/icinga в силу модульности это торчит наружу, а не спрятано за web-морду. И синтаксис проверяется не средствами конфигуратора, а средствами ядра. Но основной-то процесс при этом как работал, так и работает!
Ничего подобного. Попробуйте развернуть Nagios/Icinga для сети с большим количеством snmp оборудования. Вы просто утомитесь это делать.
Незнание и еще раз незнание возможностей icinga/nagios. У меня каждый хост имеет настроенный snmp и прекрасно работают. Большинство плагинов, особенно касающихся мониторинга оборудования работают на основе snmp. И, знаете развёртывание по snmp — самое простое. Запустить мониторинг по WMI посложнее будет. А если стоит типовое оборудование: например, 150 штук идентичных хостов — один раз склонировал их друг в друга со сменой адреса и/или имени и всё.
На тот случай, если среди нескольких тысяч плагинов нагиос/ишинга не удалось найти прямо соответствующее оборудованию, то всегда есть универсальный check_snmp, который с целевого устройства по заданному oid или символьному наименованию может собирать всё в самых разных вариантах. Описание приведено здесь. Плагин умеет собирать данные с 8 oid сразу. check_snmp был выпущен в 2002 году и входил в самую первую бета-версию «родных» плагинов nagios. Говорить о том, что с помощью nagios/icinga сложно собирать информацию по SNMP — это намеренное замалчивание фактов или ложь по неведению.
В этом и проблема. Если мне надо к примеру сделать, чтобы nagios мне просигнализировал, что на двух каналах в течении пяти минут есть перекос в сторону одного канала на 5 гигабит, то мне придется варганить свой отдельный плагин. Других методов там нет.
Мне не очень понятно, почему вы ортодоксально считаете только один путь истинным?.. То, что в zabbix надо писать внутри конфигуратора операции сравнения с сохранёнными значениями, считанными через SNMP- это, видимо, за работу не считается? Здесь тоже самое, но делается внешней обработкой. Принципиальной разницы нет. Считали с одного oid данные (средняя нагрузка за интервал по интерфейсу), считали со второго, третьего, седьмого… проверили разницу, соотнесли с временным интервалом. У nagios/icinga есть большое количество встроенных макросов, доступных для команд проверки. В принципе, на досуге можно попробовать сделать это всё даже в одной строчке команды. Если балансировщик каналов аппаратный, то под них есть уже написанные плагины, с проверенной и отработанной логикой. Искать на exchange.nagios.org и monitoringexchange.org по запросу «load balancer». Если у нас что-то из ряда вон редкостное, то читаем текст, меняем oidы. Это не такая большая проблема, в отличие от написания грамотной репликации из Oracle в MySQL.
В этом и проблема. Он умеет получать только статусы от плагинов. Вся логика живет в них. В zabbix эта вещь зависит от данных и настраивается выражениями в триггерах.
Пороги срабатывания предупреждений, та самая логика принятия решений — она прописывается не в плагине, а в команде проверки, наверное, так понятнее будет. Вот пример описания несложной команды для проверки мертвой почты в IBM Lotus Domino:
check_snmp -H host -C community -o enterprises.334.72.1.1.4.1.0 -l «Number of dead (undeliverable) mail messages:» -w 80 -c 100
граница WARNING — 80 сообщений, граница CRITICAL — 100. Логика принятия решений об извещении здесь. Чтобы ее поменять, не надо лазить в плагин (кстати, check_snmp — бинарный файл, меняем только значения в командной строке, а в параметре -l еще и указано что можно подписать для возвращаемого значения, чтобы было понятно и сисадмин голову не ломал :)
Вот что он у нас возвращает плагин:
SNMP OK — Number of dead (undeliverable) mail messages: 0
Всё просто и не так страшно.
Поставленная задача — проконтролировать состояние никуда не ушедшей почты выполнена. В zabbixe количество шагов было бы ровно то же самое — прописали тело триггера, условия срабатывания и т.д. Здесь просто делается немного по-другому. Не стоит по этому поводу так расстраиваться.
Вы сходили бы почитали мотивацию яндекса почему они отказались от nagios.
ОК. давайте прочитаем ее еще раз:
Суровая действительность: nagios
• На серверах по cron запускаются скрипты с проверками, результаты отправляются на сервера nagios;
• Конфигурация nagios — большой-большой файл, генерируемый скриптами с описанием серверов, сервисов, групп,
правил оповещения и т.д.;
• Помимо nagios, данные хранятся в rrd, по которым строятся графики.
п.1 означает, что эксплуатанты системы мониторинга в Яндекс, ничего не слышали про NRPE — клиента для Unix/Linux машин, который честно отдаёт все запрошенные данные, вовремя и с минимальными задержками. Хорошо, запустили по cron задачу, которая собрала данные, как их отдаём на nagios? По почте? — очень криво, хотя и возможно, есть такой вариант работы для систем, к которым нет онлайн подключений. Через файловые шары? — тоже кривовато, но возможно. Инженеры по какой-то причине пошли сложным путем, возможно, у них были для этого основания, но есть более легкий путь.
п.2 — ДА! У самого nagios/icinga всё лежит в файле. НО! Если мы используем конфигураторы для nagios/icinga у них тоже всё лежит в СУБД. И у Zabbix тот же самый объем информации лежит внутри в его СУБД. Где разница?
п.3 — ДА! НО! при использовании NDOUtils(nagios)/IDOUtils(icinga) данные можно хранить не только в файлах, но и в СУБД. В случае Icinga можно хранить в Oracle (а у клиента уже есть Oracle Real Application Clusters (отличная штука в плане выживаемости, если сравнивать с MySQL), а также PostgresQL и MySQL, если хочется сэкономить на лицензиях на Oracle run-time library.
Во всех трех пунктах нам сказали полуправду, недоговорив, что есть штатные и опробованные методы решения задач.
Едем дальше:
Nagios: недостатки
• Система не отказоустойчива и масштабируется переносом части проверок на отдельные сервера;
• Все изменения конфигурации выполняются правкой файлов конфигурации с последующим перезапуском nagios (~10-15 минут);
• Слишком большой интервал между проверками и замерами параметров;
• RRD усредняет данные, поэтому невозможно сказать, каково было точное значение параметров, например, месяц назад.
Каждую из этих проблем в отдельности можно было бы решить. Однако решив все, получим почти полностью переписанный nagios.
п.1 «The cake is a lie». Система отказоустойчива (линк я привёл раньше), система масштабируется (линк там же)
п.2 Про существование конфигураторов, которые позволяют управлять в том числе распределенными серверами мониторинга, команде сисадминов тоже ничего не известно. В противном случае не писали бы про редактирование текстовых файлов nagios. Файл конфигурации создаётся по базе конфигуратора, никто его руками не редактирует, хотя такая возможность есть. С базой конфигуратора можете работать как хотите — форматы доступны у разработчиков. Опять полуправда.
п.3 Слишком большой интервал между проверками. Use Icinga, Luke. Сюприз! у них это всё существенно быстрее (использование в CERN это доказывает), а конфигурационные файлы — одни и те же. :) Или shinken — тот, по отзывам, очень быстрый. Сам не проверял, говорить ничего не буду.
п.4 RRD усредняет данные. Без комментариев. С самими данными ничего не происходит. Возьмем не RRDTools, а визуализатор PNP4nagios, например, (который приворачивается достаточно легко и к nagios и к icinga (объявлено, что он 100%-icinga совместим). В нём я выделяю любой мне интересный интервал, и он разворачивается вплоть до отдельных проверок, тут же на графике печатается min/max/avg значения. Если нужны другие значения, то темплейт всегда можно доработать. Это документировано.
Особенно замечательно вот это утверждение: Решив каждую из проблем, получим переписанный nagios..
То есть, задача переписывания zabbix таки не смутила никого, хотя можно было обойтись малой кровью — внимательно посмотрев на имеющиеся бесплатные продукты. Тогда переписывать или ничего не надо было бы, или бы можно было обойтись существенно меньшими трудозатратами. Но тот, кто предложил это решение, хорошо знал только zabbix и всё остальное решил не трогать. Это его выбор, возможно, он даже на этом деле заработал хороших денег, потому что работа сложная. Он — молодец! :)
Я еще раз говорю — это хороший проект, но с не совсем честным описанием текущего ландшафта задачи и никакой проработкой альтернатив. В компаниях, где есть комитеты по проектам с серьезной ИТ-экспертизой, такие проекты возвращают на доработку еще до фазы проектирования решения с вопросом:" А какие есть еще варианты?"
Так же настраивается и эскалация. Если у нас навернулся узел выше, то уведомлять о том что у нас навернулись еще и узлы ниже не требуется.
Это не эскалация — это зависимости между хостами/сервисами. Эскалация — это извещения по группам и уровням пользователей, в зависимости от времени простоя/состояния объекта — полезная вещь для SLA, но тоже с определёнными ограничениями. У zabbix всё лежит в одной кучке, а у nagios/icinga деление достаточно чёткое.
Я подозреваю вам надо несколько глубже изучить zabbix и то как он работает.
Zabbix у нас находился в эксплуатации около 1,5 лет, дорабатывает последний месяц. Запустилось с полпинка, графики рисовались, статусы обрабатывались. А потом появились удалённые площадки. Решили заранее проверить распределённый мониторинг, zabbix мониторит хорошо, только master-slave у него работают через репликацию MySQL, а она кушает канал малопредсказуемым образом. А площадка находится в таком месте, что VPN толще 2Мбит туда затянуть сложно, и провайдеру надо полностью менять оборудование, а за свой счёт он этого делать не хочет. А через эти 2Мбит надо затянуть разборчивый голос, обмен почтой и файлами. Icinga куда как экономнее относится к полосе, для нас это важно. Будут еще площадки, в том числе и в таких дебрях, куда оптику затянут не скоро(и что вероятнее — никогда). Это раз. На толстых своих каналах этим ограничением можно пренебречь, но есть ситуации где это принципиально.
Во-вторых набор плагинов к nagios/icinga меня лично приятно удивил. Я нашел всё готовое под почти под весь наш парк оборудования.Не надо сидеть ковырять SNMP базы, не надо пытаться разбираться почему они правильно не компилируются — всё уже сделано до нас и работает. Для большинства плагинов нужны адрес хоста и название snmp-комьюнити, в безопасных вариантах — имя и пароль snmp-пользователя.
Ну и саппорт. Даже бесплатный он различается радикально. Если я описываю проблему с Icinga на monitoringexchange.org я получаю ответ максимум через день или два — максимально полный, обстоятельный и со ссылкой на документацию, даже если в итоге причиной оказывается блуждание между трех сосен. Вопрос на форуме zabbix может висеть неделями. Зато стоит только опубликовать решение, найдётся масса людей, которые скажут что всё было сделано не так, и надо делать по-другому. This is zabbix way. Если у вас другой опыт — отлично, но это ваш опыт.
Я выслушал вашу позицию, и я ее понял. Дальше разводить флейм, сползая в мелкие частности — «вот тут сделано так, а вот тут — вот так, это — рулез, а это — сакс» я не вижу никакого смысла. Чай не дети малые. Разные продукты, с разными архитектурными идеями, сравнивать их один в один — и некорректно, и бесполезно, но можно сравнивать решаемые ими задачи — ради чего они и замышлялись.
С уважением, удачи в работе с zabbix!
Конфигурация nconf и nagiosql хранится в СУБД!!! Наверное, вы этого не знали раньше. У LCONF всё хранится в базе LDAP (как я выше написал).
Которые потом генерят конфиги для каждой ноды где надо. И перезагружается сервис. И схема в СУБД подогнана именно под это. Не так-ли? С таким же успехом можно говорить что у любого софта который использует текстовые файлы конфигурации, конфигурация хранится в СУБД.
Ну а вы физику процесса за этим «применилось» понимаете? процесс zabbix_server, приостановил свою работу, считал новую конфигурацию, запустился и продолжил работу дальше. Если это не так, то это новое достижение в ИТ — единичный сервис, без перерыва в работе, волшебным образом, считал новый конфиг.
Вы вот сейчас бред говорите. В конфиге zabbix сервера находится только информация о том где у нас СУБД находится. Далее он просто ее перечитывает перед запросом данных. Вы не поверите, но я просто беру добавляю узел и параметры с него считываемые и у меня тут же они подхватываются. Никакой магии.
Незнание и еще раз незнание возможностей icinga/nagios. У меня каждый хост имеет настроенный snmp и прекрасно работают. Большинство плагинов, особенно касающихся мониторинга оборудования работают на основе snmp. И, знаете развёртывание по snmp — самое простое.
Это вы не видели как в zabbix это работает. Я могу нажать кнопку discovery и пойти пить чай. Он сам просканирует сеть посмотрит, что это за устройство и назначит необходимый шаблон. Плюс в любой момент могу изменить шаблон устройства или любое устройство.
На тот случай, если среди нескольких тысяч плагинов нагиос/ишинга не удалось найти прямо соответствующее оборудованию, то всегда есть универсальный check_snmp, который с целевого устройства по заданному oid или символьному наименованию может собирать всё в самых разных вариантах.
Zabbix просто забирает данные с oid, дальше как вы его будете обрабатывать определяете в триггере выражением. Если вам потребуется такой функционал вам придется переделывать check_snmp.
Мне не очень понятно, почему вы ортодоксально считаете только один путь истинным?.. То, что в zabbix надо писать внутри конфигуратора операции сравнения с сохранёнными значениями, считанными через SNMP- это, видимо, за работу не считается?
Это проще деполится и легко меняется. Согласитесь, что зайти в интерфейс и поменять это проще, чем зайти не в интерфейс, а в код плагина и менять там.
граница WARNING — 80 сообщений, граница CRITICAL — 100. Логика принятия решений об извещении здесь. Чтобы ее поменять, не надо лазить в плагин (кстати, check_snmp — бинарный файл, меняем только значения в командной строке, а в параметре -l еще и указано что можно подписать для возвращаемого значения, чтобы было понятно и сисадмин голову не ломал :)
Я вам довольно четкий пример привел, что делается на zabbix за пару минут прямо в интерфейсе. Сделайте тоже самое с check_snmp. Пока я вижу даже за какой период он это выдает. Если за текущий то как-то не интересно.
В zabbixe количество шагов было бы ровно то же самое — прописали тело триггера, условия срабатывания и т.д. Здесь просто делается немного по-другому. Не стоит по этому поводу так расстраиваться.
Не совсем. Во первых я могу писать более сложные запросы. Во вторых доступны дополнительные функции. К примеру я могу сигнализировать только после того как более 80 сообщений в очереди было в течении 10 минут. И это делается добавлением одной функции.
п.1 означает, что эксплуатанты системы мониторинга в Яндекс, ничего не слышали про NRPE — клиента для Unix/Linux машин, который честно отдаёт все запрошенные данные, вовремя и с минимальными задержками.
Подозреваю он им не подходит по каким либо причинам.
п.2 — ДА! У самого nagios/icinga всё лежит в файле. НО! Если мы используем конфигураторы для nagios/icinga у них тоже всё лежит в СУБД. И у Zabbix тот же самый объем информации лежит внутри в его СУБД. Где разница?
Не требуется перезагрузка сервиса. Если вы не в курсе, но у zabbix нет такого понятия как файл конфигурации. В его файле конфигурации лежат только реквизиты подключения к СУБД и имя узла все. В результате скорость изменения существенно выше.
п.3 — ДА! НО! при использовании NDOUtils(nagios)/IDOUtils(icinga) данные можно хранить не только в файлах, но и в СУБД. В случае Icinga можно хранить в Oracle (а у клиента уже есть Oracle Real Application Clusters (отличная штука в плане выживаемости, если сравнивать с MySQL), а также PostgresQL и MySQL, если хочется сэкономить на лицензиях на Oracle run-time library.
Есть одно но, надо чтобы все плагины отдавали perfdata, к тому же накладные расходы на это существенно больше чем у Zabbix. Просто в силу того что сначала плагин читает данные и формирует их в pefdata далее их NDOUtils парсит и перекладывает в базу. При их объемах это уже будет критично. Да и даже банально подумайте. Вот у меня есть 20 свитчей с 48 портами, мне каждый порт надо завести в мониторинг по snmp и два из этих портов еще оборудовать триггерами. Сколько это будет порождать процессов при работе?
«The cake is a lie». Система отказоустойчива (линк я привёл раньше), система масштабируется (линк там же)
Путем добавления костылей. Нативно не масштабируется. В само ПО это не заложено. В zabbix кстати говоря заложено.
Про существование конфигураторов, которые позволяют управлять в том числе распределенными серверами мониторинга, команде сисадминов тоже ничего не известно.
Конфигуратор не решение проблемы. Это затычка проблемы.
Слишком большой интервал между проверками. Use Icinga, Luke. Сюприз! у них это всё существенно быстрее (использование в CERN это доказывает), а конфигурационные файлы — одни и те же. :) Или shinken — тот, по отзывам, очень быстрый. Сам не проверял, говорить ничего не буду.
Фишка в том что zabbix будет еще быстрее. Особенно в случае нативных методов. Просто в силу того что он не запускает пачками процессы.
RRD усредняет данные. Без комментариев. С самими данными ничего не происходит.
Вы помните как расшифровывается RRD? Данные затираются по кольцу. Типичная схема использования RRD это daily weekly monthly year RRD file. Отсюда усреднение.
Возьмем не RRDTools, а визуализатор PNP4nagios, например, (который приворачивается достаточно легко и к nagios и к icinga (объявлено, что он 100%-icinga совместим). В нём я выделяю любой мне интересный интервал, и он разворачивается вплоть до отдельных проверок, тут же на графике печатается min/max/avg значения. Если нужны другие значения, то темплейт всегда можно доработать. Это документировано.
Вот тут знаете я как вас читаю, то тут вижу тут можно доработать, тут взять такую-то дополнительную утилиту и т.п. Это все же не от хорошей жизни. Вместо того чтобы изменить ПО, начинают добавлять возле него утилит, чтобы оно работало как надо. Это тупиковый путь.
Особенно замечательно вот это утверждение: Решив каждую из проблем, получим переписанный nagios…
То есть, задача переписывания zabbix таки не смутила никого, хотя можно было обойтись малой кровью — внимательно посмотрев на имеющиеся бесплатные продукты.
Объем кода к zabbix там существенно меньше поверьте мне.
Я еще раз говорю — это хороший проект, но с не совсем честным описанием текущего ландшафта задачи и никакой проработкой альтернатив.
Честно говоря из того что вы сейчас мне рассказали, я только больше укрепился во мнении что zabbix я в свое время выбрал верно. У меня нет никакого желания сидеть и прикручивать к nagios все вами перечисленное, чтобы оно работало. Причем замечу в zabbix я это получаю сразу. Да мне придется почитать документацию по zabbix. Но мороки с ним будет в итоге меньше.
Это не эскалация — это зависимости между хостами/сервисами. Эскалация — это извещения по группам и уровням пользователей, в зависимости от времени простоя/состояния объекта — полезная вещь для SLA, но тоже с определёнными ограничениями. У zabbix всё лежит в одной кучке, а у nagios/icinga деление достаточно чёткое.
Ну зависимости. Эскалация да это уже кому слать. Вот то что у zabbix все лежит в одной куче, насколько помню в 2.0 уже пофиксили, но минорно. Свои косяки есть у него но где их нет.
Zabbix у нас находился в эксплуатации около 1,5 лет, дорабатывает последний месяц. Запустилось с полпинка, графики рисовались, статусы обрабатывались. А потом появились удалённые площадки. Решили заранее проверить распределённый мониторинг, zabbix мониторит хорошо, только master-slave у него работают через репликацию MySQL, а она кушает канал малопредсказуемым образом.
Эм. Там вообще есть несколько вариантов. В том числе и без репликации через MySQL. Вы внимательно документацию читали?
Icinga куда как экономнее относится к полосе, для нас это важно.
Вы тут меня упрекаете что я плохо читал про nagios. Я вас тоже могу поупрекать что вы плохо читали про zabbix.
www.zabbix.com/documentation/2.0/manual/distributed_monitoring/proxies
Здесь описано как раз что делать для случая когда у нас есть отдельная площадка. Я не думаю что это как-то кардинально отличается от Iciga.
Во-вторых набор плагинов к nagios/icinga меня лично приятно удивил. Я нашел всё готовое под почти под весь наш парк оборудования.Не надо сидеть ковырять SNMP базы, не надо пытаться разбираться почему они правильно не компилируются — всё уже сделано до нас и работает. Для большинства плагинов нужны адрес хоста и название snmp-комьюнити, в безопасных вариантах — имя и пароль snmp-пользователя.
Шаблоны для zabbix вы видели?
Ну и саппорт. Даже бесплатный он различается радикально. Если я описываю проблему с Icinga на monitoringexchange.org я получаю ответ максимум через день или два — максимально полный, обстоятельный и со ссылкой на документацию, даже если в итоге причиной оказывается блуждание между трех сосен.
Это не суппорт это сообщество. Это несколько разные вещи. Опять же если вас тыкают в документацию, то вы я ее явно не читаете.
Разные продукты, с разными архитектурными идеями, сравнивать их один в один — и некорректно, и бесполезно
И то и то системы мониторинга. Имеется разница в подходах. В zabbix тоже многое сделано не оптимально и не очень хорошо, но архитектурно он лучше nagios. Наличие всяких дополнительных агентов, генераторов конфигураций и дополнительных плагинов чтобы лететь как раз указывают на проблемы у ПО. Увы это так. И вы столкнетесь с этими проблемами когда вам потребуется сделать что-то необычное.
Чем, по факту, отличается работа Icinga+mod_gearman от Nagios+mod_gearman?
Со страницы mod_gearman, без комментариев:
Nagios
Mod-Gearman works perfect with the latest stable nagios 3.2.3. Version 3.3.1 has some serious bugs and is not recommended for use in production.
Icinga
Mod-Gearman has succesfully been tested on Icinga 1.2.0 and is running perfectly on up to the current version 1.6.1.
Nagios
Mod-Gearman works perfect with the latest stable nagios 3.2.3. Version 3.3.1 has some serious bugs and is not recommended for use in production.
Icinga
Mod-Gearman has succesfully been tested on Icinga 1.2.0 and is running perfectly on up to the current version 1.6.1.
Ну, в Debian Wheezy (testing) уже nagios 3.4.1 и никаких проблем в его связке с mod_gearman у меня пока не вылезло.
никаких проблем не возникло != проблем не возникнет
mod_gearman и icinga — немецкие проекты. mod_gearman всегда будет проверяться на работу с icinga в первую очередь — это первое. Второе — я не думаю, что в сисадмины в CERN совсем уж дураки. Они пытались заставить работать nagios, как им было нужно, но у них не получилось. с Icinga всё получилось. С учётом того, что конфигурации 100% совместимы, замена действительно представляет собой техническую проблему.
Скрытый текст
В своё время были большие нелады между Галстадом (автор nagios) и немецкой командой отпочковавшейся в проект Icinga и у меня почти готов перевод большой статьи с комментариями участников. Там много субъективизма и эмоций с обоих сторон, но любопытно почитать. После нее мне стали понятны многие вещи, которые изначально выглядят нелогичными.
mod_gearman и icinga — немецкие проекты. mod_gearman всегда будет проверяться на работу с icinga в первую очередь — это первое. Второе — я не думаю, что в сисадмины в CERN совсем уж дураки. Они пытались заставить работать nagios, как им было нужно, но у них не получилось. с Icinga всё получилось. С учётом того, что конфигурации 100% совместимы, замена действительно представляет собой техническую проблему.
Sign up to leave a comment.
Icinga в действии. Мониторинг Большого Адронного Коллайдера в ЦЕРН, Швейцария/Франция