Прекрасно понимаю «нотку разочарования» zabbix'ом. Испытываю похожие чувства.
Подписываюсь на тему.

Т.е. не жаба

я себе так и вижу как вы будете ставить на сервер не обновлвшийся с 2005 года питон или перл частями 8)

Вот прямо всё и из коробки — нет (пока) такого.

понравился nagios

А что ближе всего? Была бы хорошая основа, а допилить всегда можно

Трудно однозначно сказать у всех свои потребности.

З.Ы. у меня работает nagios и основанный на нем (платный продукт) centerity.

nagios мониторит всех без установки агента (много старых серверов HP-UX, SunOS, AIX) через check_by_ssh (check_by_rsh)

centerity работает в режиме с агентами (nrpe) и с дочерним сервером.

Меня устраивает.

Меня достал OpenView и я его заменил на нагиос.

К нагиосу прикрутил rrd графики (pnp4nagios кажется)

icinga как форк нагиоса позиционируется как тру дистрибьютед

использую icinga.
не хочешь ssh, для него есть nrpe (правда тот ещё костыль, но в инете есть истории успеха)
можно писать свои скрипты etc.
за всё время использования глюков не обнаружил.
документция есть. но качество на 3-ку из 5-ти.

Можешь попробовать , если много сетевого железа фирмы cisco то http://observium.org/ , иначе я вижу только как конкурент NetXMS

ну со всем кроме первого пункта заббикс справляется, а чем еще он не угодил ?

со всем кроме первого пункта заббикс справляется

Провала в первом пункте достаточно для диагноза «не нужно». Надёжность - главное требование к системе мониторинга.

Вопрос. Предположим, что нужно раз в 20 секунд забирать cо внешней системы значения ~ 300 параметров ( я не преувеличиваю ). Может icinga забрать за один запуск скрипта все 300, или на каждый параметр будет вызываться внешний скрипт? Если на каждый, будет слишком высокий overhead, даже если кэшировать эти данные.

http://observium.org/

У него есть агенты для обычных linux и windows?

А возможно в nagios либо centerity push'ить данные в систему мониторинга по инициативе внешних источников?

icinga выполнит на удалённой машине тот скрипт, который ты ему прописал.
если пропишешь в одной «команде» как узнать, к примеру, hdd, swap и cpu, он узнает. один раз запустив этот самый скрипт.

А возможно в nagios либо centerity push'ить данные в систему мониторинга по инициативе внешних источников?

нет. icinga сама подключается, выполняет команды и берёт данные.

А возможно в nagios либо centerity push'ить данные в систему мониторинга по инициативе внешних источников?

нет. icinga сама подключается, выполняет команды и берёт данные.

Как icinga хранит данные?
Мне нужно, например, сегодня посмотреть значения определённого агента за 15.02.2013. Я могу это сделать в icinga?
Что с разрастанием БД данных у этого продукта?

А возможно в nagios либо centerity push'ить данные в систему мониторинга по инициативе внешних источников?

1. snmp trap никто не отменял.
2. Есть passive check, когда ты сам пихаешь данные (события системе). Как удаленный клиент (агент) пихнет серверу эти данные второй вопрос (относительно легко решаемый).

ещё один плюс исинге

http://habrahabr.ru/post/170135/

Мне нужно, например, сегодня посмотреть значения определённого агента за 15.02.2013. Я могу это сделать в icinga?

сейчас гляну, не делал никогда этого.

Что с разрастанием БД данных у этого продукта?

не смогу ответить. у меня не так уж и много хостов.
но он может использовать как mysql, так и postgres.

Мне нужно, например, сегодня посмотреть значения определённого агента за 15.02.2013. Я могу это сделать в icinga?

Да, можешь. Тебе искать в icinga_statehistory;

Мне нужно, например, сегодня посмотреть значения определённого агента за 15.02.2013. Я могу это сделать в icinga?

И через вэб можно =)

использую icinga

1)Если я строю, например, 2000 графиков в rrd по snmp, и мне потребовалось добавить еще один, нужно ли перезапускать сервис и сколько по времени это займет?
2)Возможно ли добавление графиков без использования, скажем, «фирменного веб-интерфейса проекта»? (заббикс и cacti поэтому мне не подходит)
В munin, например, добавляешь график, рестаруешь агента, и munin «рожает» около часа (на серваке 12 потоков и 16 гиг оперативки). Конфиг генерю сам из sql-базы. Естественно, на существующих графиках из-за этого появляются дыры. Поэтому munin пришлось закопать, и пользоваться mrtg+routers2cgi. Там изменение в конфиге не создает дырявых графиков.

ну это лечится своими проверками, да странно что это не сделано из коробки, но вы все равно придете к заббиксу другой такой системы по функционалу имхо сейчас нет

В zabbix'е на каждый чих нужна своя проверка. И выясняется это в результате инцидентов. И в процессе отладки ( которая, как известно, избавление от лажи ) этой «системы мониторинга» спускаемся всё ниже . И обнаруживаем, что чем более низкоуровневые вещи поверяем, тем больше костылей необходимо. И на определённом этапе понимаем, что оно нахрен не сдалось такое кривое и глючное

Я думаю что из опенсурсного ты врядли что-то лучше найдешь... Заббикс конечно не идеал, но с годами становится все лучше и лучше, взять те же Лоу левел дискавери, как облегчают жизнь.

А то что многое надо делать руками это да, но на то есть шаблоны и возможность их многоуровневой иерархии.

Я сижу на нем уже 5 лет и слезать не собираюсь.

Зы: я тут как-то покопавшись в конфиге отключил случайно хаускипинг и огреб 2 миллиарда(!) строк в таблице хистори, и ничего, оно себе работало не особо напрягаясь, только место на диске с БД кончаться стало :)

взять те же Лоу левел дискавери, как облегчают жизнь.

LLD я был рад месяца три назад. Теперь я могу долго и матерно рассказывать, как они усложняют жизнь. Самая большая претензия - в случае изменения прототипа, эти изменения не повлияют на хосты, на которых discovery уже прошёл. Приходится удалять шаблон с хоста ( теряя всю историю, а это очень критично ) и вешать его обратно. Также, при любом редактировании прототипа графика, его корёжит до неузнаваемости ( одни item'ы меняются на другие, другие могут вообще пропасть ). Т.е. либо ты пишешь шаблон с lld один раз и потом боишься чихнуть, либо почти после каждого изменения пляшешь с бубном. Хватит?

Заббикс конечно не идеал, но с годами становится все лучше и лучше

1.8 не смотрел, но 2.2 пока намного хуже чем 2.0 в плане багов. Если что, всё что я писал выше - про 2.0

Я реально ненавижу его программистов и при встрече постараюсь нанести им физические повреждения.

ЩИТО?

Ты используешь housekeeper?
Расскажи, пожалуйста, подробнее, как обстоят дела с разрастанием БД? Как часто приходится прогонять optimize table?

Привет, роутер. А я думал когда ты взбесишся , вот момент настал :)

Надёжность. Никаких ситуаций вроде «дочерний сервер мониторинга незаметно отвалился» или «агент на хосте перестал слать данные, а сервер этого не заметил». И это задача не пользователя, который должен сам добавлять проверки на недоступность, а задача сервера, который сам автоматически проверяет такие ситуации. ( для решения этой проблемы достаточно на какую-либо пассивную проверку на агенте прикрутить в триггере условие nodata )

Расширяемость. Возможность отправлять данные из внешних скриптов. ( Траппер рулит на ура )

API. Нужна возможность выполнять массовые действия автоматически, через внешние скрипты ( Есть, так её растак! )

Распределённость. Нужны промежуточные сервера, которые через свой интерфейс покажут текущее состояние подотчётных объектов, даже если упал канал до центрального сервера мониторинга ( Частично есть. Ведь можно для каждой ноды поднять свой апач с интерфейсом! )

Открытые исходники. Потому что зачастую их приходится использовать для отладки и для понимания как же оно работает ( Сам качал да, отвечаю да )

Низкое потребление ресурсов агентом. Нередкая ситуация с виртуальной машиной - 384 Мб памяти. Т.е. не жаба, не руби и не что там ещё прожорливое. Ресурсоёмкость сервера не так критична ( А зачэм агент, можно SNMP )

Возможность строить custom'ные графики по собранным данным. ( Ага, и ещё динамический спредщит с диаграммами или прикрученый numpy, или что там в питоне для обработки научных данных используют )

Желательно - доступ к настройке графиков через API ( Графики точно можно импортировать и экспортировать, значит на крайняк можно постить соответсвующий XML )

Давать доступ по ssh ко всем серверам, тем более рутовый - недопустимо. Поэтому необходима возможность не автоматической установки агентов на хосты ( Решается установкой на серверА рестриктед шелла с отдельным пользователем и настройкой sudo , ну это я так, по-детски, профи наверное selinux используют, а сама настройка серверов и установка агента через пакетного сисадмина типа puppet. Ну или вообще отказаться от агента, оставить SNMP и удаленное выполнение кастомных команд через ssh )

Надёжность. Никаких ситуаций вроде «дочерний сервер мониторинга незаметно отвалился» или «агент на хосте перестал слать данные, а сервер этого не заметил». И это задача не пользователя, который должен сам добавлять проверки на недоступность, а задача сервера, который сам автоматически проверяет такие ситуации.

для решения этой проблемы достаточно на какую-либо пассивную проверку на агенте прикрутить в триггере условие nodata

В каждый из 15к?

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

Частично есть. Ведь можно для каждой ноды поднять свой апач с интерфейсом!

Формально есть. Реально разработчики на неё забили. Состояние удалённой ноды нужно проверять самому, но это ерунда. В 2.2 вообще сломали DM с нодами. Уходил в отпуск - открыл тикет в багтрекере. Вернулся, увидел что он всё ещё unassigned. Нашёлся и более ранний тикет с той же проблемой ( не нашёл его когда открывал новый ), он тоже unassigned спустя месяц, хотя автор тикета даже приложил патч.

«В каждый из 15к?»

Народ тачками и кайлами беломорканал построил, а ты жалуешься :)

У меня возникло подозрение, что вместо кайла мне дали десертную ложечку.

Housekeeper это алгоритм в заббиксе для удаления старых записей в БД, он включен по умолчанию, а я его как-то умудрился отрубить. Оптимизировать БД - зачем? Там InnoDB, на него Optimize Table вроде особо не действует.

Самая большая претензия - в случае изменения прототипа, эти изменения не повлияют на хосты, на которых discovery уже прошёл.

Щито? Я меняю прототип в шаблоне, дискавери проходит через заданый промежуток времени и все изменения применяются к хосту. Так что ты что-то не так готовишь (либо это в 2.0 так), никаких отдираний-приклеиваний шаблонов я не делаю.

2.2 пока намного хуже чем 2.0 в плане багов.

Сижу месяца два на 2.2, багов не заметил. Сеть у меня, правда, не очень большая (хостов штук 300 сервера + цыски + принтеры и т.п.), но тем не менее. Работает как часы, проапгредилось плавно (автоапгрейд БД - айс)

Если не оптимизировать, то происходит фрагментирование данных. Размер занимаемого места БД на диске не уменьшится.

Table does not support optimize, doing recreate + analyze instead

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

Интересно, кстати, что используют инженеры из какого-нибудь Яндекса в качестве системы мониторинга.

В Яндексе zabbix, но над ним долго работали их программисты. Насколько я помню из статей на хабре

Кстати, а Zenoss кто-нибудь использует?

http://documentation.centreon.com/

NOC, но допиливать поддержку линукса придется, мне тоже это надо.

Там или ssh или snmp.

У него есть агенты для обычных linux и windows?

Для никсов я там видел .Насчет винды не знаю.