LINUX.ORG.RU
ФорумAdmin

Очередной тред выбора системы мониторинга

 ,


7

6

Доброго времени суток.

Сабж. Zabbix окончательно задрал. Я реально ненавижу его программистов и при встрече постараюсь нанести им физические повреждения. Потраченные на допиливание полгода - псу под хвост.

Необходимо:

  • Надёжность. Никаких ситуаций вроде «дочерний сервер мониторинга незаметно отвалился» или «агент на хосте перестал слать данные, а сервер этого не заметил». И это задача не пользователя, который должен сам добавлять проверки на недоступность, а задача сервера, который сам автоматически проверяет такие ситуации.
  • Расширяемость. Возможность отправлять данные из внешних скриптов.
  • API. Нужна возможность выполнять массовые действия автоматически, через внешние скрипты
  • Распределённость. Нужны промежуточные сервера, которые через свой интерфейс покажут текущее состояние подотчётных объектов, даже если упал канал до центрального сервера мониторинга
  • Открытые исходники. Потому что зачастую их приходится использовать для отладки и для понимания как же оно работает
  • Низкое потребление ресурсов агентом. Нередкая ситуация с виртуальной машиной - 384 Мб памяти. Т.е. не жаба, не руби и не что там ещё прожорливое. Ресурсоёмкость сервера не так критична
  • Возможность строить custom'ные графики по собранным данным. Желательно - доступ к настройке графиков через API
  • Давать доступ по ssh ко всем серверам, тем более рутовый - недопустимо. Поэтому необходима возможность не автоматической установки агентов на хосты
★★★★★

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

blackst0ne ★★★★★ ()

Т.е. не жаба

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

Deleted ()
Ответ на: комментарий от router

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

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

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

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

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

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

sdio ★★★★★ ()
Ответ на: комментарий от sdio

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

sdio ★★★★★ ()
Ответ на: комментарий от sdio

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

sdio ★★★★★ ()
Последнее исправление: sdio (всего исправлений: 1)

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

dada ★★★★★ ()
Ответ на: комментарий от tugrik

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

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

router ★★★★★ ()
Ответ на: комментарий от dada

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

router ★★★★★ ()
Ответ на: комментарий от router

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

dada ★★★★★ ()
Ответ на: комментарий от router

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

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

dada ★★★★★ ()
Ответ на: комментарий от dada


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



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



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

blackst0ne ★★★★★ ()
Ответ на: комментарий от router

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

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

sdio ★★★★★ ()
Ответ на: комментарий от blackst0ne

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

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

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

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

dada ★★★★★ ()
Ответ на: комментарий от blackst0ne

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

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

dada ★★★★★ ()
Ответ на: комментарий от blackst0ne

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

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

dada ★★★★★ ()
Ответ на: комментарий от dada

использую icinga

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

andrew667 ★★★★★ ()
Ответ на: комментарий от router

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

tugrik ★★ ()
Ответ на: комментарий от tugrik

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

router ★★★★★ ()
Последнее исправление: router (всего исправлений: 1)
Ответ на: комментарий от router

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

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

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

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

blind_oracle ★★★★★ ()
Ответ на: комментарий от blind_oracle

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

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

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

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

router ★★★★★ ()

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

ЩИТО?

Deathstalker ★★★★★ ()
Ответ на: комментарий от blind_oracle

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

blackst0ne ★★★★★ ()

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

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

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

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

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

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

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

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

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

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

anonymous ()
Ответ на: комментарий от anonymous

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

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

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

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

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

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

router ★★★★★ ()
Ответ на: комментарий от anonymous

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

router ★★★★★ ()
Ответ на: комментарий от blackst0ne

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

blind_oracle ★★★★★ ()
Ответ на: комментарий от router

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

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

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

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

blind_oracle ★★★★★ ()
Ответ на: комментарий от blind_oracle

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

blackst0ne ★★★★★ ()
Ответ на: комментарий от blackst0ne

Table does not support optimize, doing recreate + analyze instead

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

blind_oracle ★★★★★ ()
Последнее исправление: blind_oracle (всего исправлений: 1)

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

blackst0ne ★★★★★ ()
Ответ на: комментарий от blackst0ne

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

router ★★★★★ ()

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

tailgunner ★★★★★ ()

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

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

multihead ()
Ответ на: комментарий от router

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

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

pinachet ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.