Комментарии 27
Мне кажется, в ситуации когда хостов больше двух уже нужно использовать Zabbix.
0
С Zabbix нормально не работал, но очевидные различия:
— База против rrd, вытянет ли база на наших объёмах? (rrd не тянет, пришлось в память положить)
— Централизованная конфигурация (Zabbix) против децентрализованной (Munin).
У нас разные команды админов и разработчиков. В случае Munin разработчик приделывает график сам (добавляет плагин) и никого не ждёт. В Zabbix он должен просить кого-то с админскими правами. Новый график может появится на Dev/LiveTest сервере, а на основной массе его не будет. И именно этот график хорошо показывает как оно работает новая версия.
В централизованной системе (Zabbix) это сложнее сделать. Эта фича не бесплатна, конфиг Munin раздувается страшно. Но оно стоит того (в наших условиях)
Ну и главное. У нас были Munin+Nagios, мы их настроили, мы к ним привыкли, мы их знаем. Zabbix это сильно новое. «работает — не трожь!»
PS Zabbix красив, конечно. Пробуем его но пока в проде стоит Munin
— База против rrd, вытянет ли база на наших объёмах? (rrd не тянет, пришлось в память положить)
— Централизованная конфигурация (Zabbix) против децентрализованной (Munin).
У нас разные команды админов и разработчиков. В случае Munin разработчик приделывает график сам (добавляет плагин) и никого не ждёт. В Zabbix он должен просить кого-то с админскими правами. Новый график может появится на Dev/LiveTest сервере, а на основной массе его не будет. И именно этот график хорошо показывает как оно работает новая версия.
В централизованной системе (Zabbix) это сложнее сделать. Эта фича не бесплатна, конфиг Munin раздувается страшно. Но оно стоит того (в наших условиях)
Ну и главное. У нас были Munin+Nagios, мы их настроили, мы к ним привыкли, мы их знаем. Zabbix это сильно новое. «работает — не трожь!»
PS Zabbix красив, конечно. Пробуем его но пока в проде стоит Munin
+1
У нас порядка 100 хостов, где собирается около нескольких сотен параметров с каждого.
База сейчас размером 32Гб. Работает достаточно быстро но требует порядочно памяти.
Заббикс может иметь несколько мастеров для опроса.
В заббиксе можно выдать права как на отдельные серверы, так и на группы серверов.
Ну и добавлять хосты можно значительно легче. Например есть группы vds, backup, servers, generic. Для виртуалок мы добавляем группу generic и vds, для серверов generic, servers и, если нужно — backup.
База сейчас размером 32Гб. Работает достаточно быстро но требует порядочно памяти.
Заббикс может иметь несколько мастеров для опроса.
В заббиксе можно выдать права как на отдельные серверы, так и на группы серверов.
Ну и добавлять хосты можно значительно легче. Например есть группы vds, backup, servers, generic. Для виртуалок мы добавляем группу generic и vds, для серверов generic, servers и, если нужно — backup.
+1
А как часто обновляются данные? В среднем, конечно.
У нас 1600 нод, которые мониторятся (это и сервера и виртуальные контейнеры на них).
275000 метрик (линий на графиках).
Получается на порядок больше «хостов», в 2 раза меньше данных (14 против 32GB).
Или вы чаще собираете, или дольше храните. Munin собирает раз в 5 минут.
У нас 1600 нод, которые мониторятся (это и сервера и виртуальные контейнеры на них).
275000 метрик (линий на графиках).
Получается на порядок больше «хостов», в 2 раза меньше данных (14 против 32GB).
Или вы чаще собираете, или дольше храните. Munin собирает раз в 5 минут.
+1
У нас все метрики — трапперы, то есть данные приходят с хостов. Где то раз в секунду, где то раз в 5 секунд, где то раз в сутки. По разному. Данные тоже по разному хранятся, от суток до месяца. Отдельные — полгода.
У нас просто housekeeper не работает по непонятной причине. А руками чистить — очень долго получается.
У нас просто housekeeper не работает по непонятной причине. А руками чистить — очень долго получается.
0
Ох ты жеж. Чего же вы шлёте раз в секунду или раз в 5 секунд?
Супер полезная информация, если сервер умрёт, но это же нагрузка не только на мастер, но и на ноду
Супер полезная информация, если сервер умрёт, но это же нагрузка не только на мастер, но и на ноду
+1
>База сейчас размером 32Гб. Работает достаточно быстро но требует порядочно памяти.
Данные у вас за какой период хранятся?
Данные у вас за какой период хранятся?
+1
Это не нормальный размер.
Вы наверно уже читали, но все же www.zabbix.com/wiki/non-english/ru/partitioning_in_mysql
Размер базы не превышает 10 гигов, и то — она распухшая, так как это было сделано не сразу.
Вы наверно уже читали, но все же www.zabbix.com/wiki/non-english/ru/partitioning_in_mysql
Размер базы не превышает 10 гигов, и то — она распухшая, так как это было сделано не сразу.
+1
Zabbix, 600 серверов, 50 000 метрик с них снимается, база 18 гб, MySQL.
Большая часть данных хранится 90 дней (тренды) детальная статистика — 30 дней
Фронтэнд + отдельная машина под БД с sas 15k, хотя один сервер скорее всего теперь тоже будет справляться. Мигрировали с постгреса, у него в силу версионности записей и специфичной модели работы заббикса с БД не удалось добиться приемлемой производительности базы
Большая часть данных хранится 90 дней (тренды) детальная статистика — 30 дней
Фронтэнд + отдельная машина под БД с sas 15k, хотя один сервер скорее всего теперь тоже будет справляться. Мигрировали с постгреса, у него в силу версионности записей и специфичной модели работы заббикса с БД не удалось добиться приемлемой производительности базы
+1
А как часто у вас собираются данные с метрик? Грубо, сколько метрик в секунду снимается?
Потому что 50k раз в секунду это очень круто, а раз в 5 минут — у нас 275k тянет спокойно.
Потому что 50k раз в секунду это очень круто, а раз в 5 минут — у нас 275k тянет спокойно.
+2
Процентов 30 — раз в минуту, остальная часть — раз в 5 минут и реже. Постгрес с более частыми периодами не справлялся, запас сейчас есть раз в пять, LA обоих серверов не превышает 0.2
0
Заббикс выигрывает не столько сверхпроизводительностью сбора и хранения данных ( с rrd все таки довольно трудно тягаться ), сколько возможностью довольно стандартными способами масштабироваться на несколько серверов.
Ну и тем, что кроме один раз установленного заббикс агента на серверах не нужны никакие действия — ни ставить плагины, ни конфиги править не придется. С влюченнными RemoteCommands сбор практически всех метрик настраивается через веб-морду в шаблоне сервера/роли/приложения. Исключение разве что для метрик, требующих рута — их приходится засовывать в sudo, но таких немного.
Ну и тем, что кроме один раз установленного заббикс агента на серверах не нужны никакие действия — ни ставить плагины, ни конфиги править не придется. С влюченнными RemoteCommands сбор практически всех метрик настраивается через веб-морду в шаблоне сервера/роли/приложения. Исключение разве что для метрик, требующих рута — их приходится засовывать в sudo, но таких немного.
0
«сбор практически всех метрик настраивается через веб-морду»
В нашем случае это не совсем фича.
Грубо, разработчик может захотеть метрику. Он её просто делает как плагин в новой версии роли и всё. Новая версия ставится, метрика появляется. Причём если версия ставится в Live Test, на один сервер, то и появляется на одном.
В Zabbix он бы ещё и просил кого-то с админскими правами (или опытом) добавить новый шаблон с новой метрикой.
Если разработчик накосячил в плагине на сервере, то поправит в следующей вертике и научится на горьком опыте. Мучать центральную конфигурацию и учиться ему никто не даст.
Так же у нас есть централизованная база с конфигурацией системы, из неё надо делать все конфиги. И тут текстовые конфиги Munin (сгенерировал с нуля, подложил) удобнее чем любое API. Например, выявлять и удалять исчезнувшие ноды надо.
В нашем случае это не совсем фича.
Грубо, разработчик может захотеть метрику. Он её просто делает как плагин в новой версии роли и всё. Новая версия ставится, метрика появляется. Причём если версия ставится в Live Test, на один сервер, то и появляется на одном.
В Zabbix он бы ещё и просил кого-то с админскими правами (или опытом) добавить новый шаблон с новой метрикой.
Если разработчик накосячил в плагине на сервере, то поправит в следующей вертике и научится на горьком опыте. Мучать центральную конфигурацию и учиться ему никто не даст.
Так же у нас есть централизованная база с конфигурацией системы, из неё надо делать все конфиги. И тут текстовые конфиги Munin (сгенерировал с нуля, подложил) удобнее чем любое API. Например, выявлять и удалять исчезнувшие ноды надо.
0
По поводу прав сценарий в Заббиксе может быть такой — группа серверов (скажем, тестовые), группа тестовых же шаблонов, пользователь с правами забикс админа но с возможностью записи только в группы тестовых серверов и шаблонов. Ничего лишнего не сломает, шаблон копируется в группу основных шаблонов и цепляется к боевым серверам. Юзер может допиливать тестовый шаблон и дальше, до следующей итерации проверки и переноса в бой
0
В Munin не очень круто то, что метрики только раз в 5 минут и это врождённое, это не обойти. Иногда хочется чаще, но никак.
Мы даже думали другой мониторинг (тот же Zabbix) на небольшое количество метрик поставить с большей частотой.
Мы даже думали другой мониторинг (тот же Zabbix) на небольшое количество метрик поставить с большей частотой.
0
Как вариант, для графиков можно использовать Centreon. Или используется что-то, чего не может отобразить связка nagios+centreon?
+2
О! Первый раз встречаю на хабре упоминание этого продукта. Ты его ставил под какую ОС? Я год назад где-то ставил под убунту, честно говоря пришлось полдня гуглить и напильником работать чтобы он заработал. Вроде и фигня, пара скриптов не срослась и в крон не прописалась, но вся цепочка довольно сложная, пока отдебажишь что именно не работает — полдня и прошло. А работает красиво, графики там классный бонус к нагиосу. Но все таки произвольные и сложные графики — это в мунин.
0
Я его ставил под CentOS 5.
Если что, знакомый недавно писал инструкцию.
Если что, знакомый недавно писал инструкцию.
+1
Для снятия нагрузки на винт от апдейта rrd есть еще rrdcached.
0
rrdcached выглядит каким-то половинчатым.
Он аккумулирует данные, но не даёт прочитать их из кеша. Только записать на диск. То есть если надо работать с данными, например посчитать агрегат или ещё чего, то есть записываем на диск и читаем с диска.
Плюс он сам пишет на диск в непредсказуемый момент.
Проблема в том, что никто не будет смотреть на 1000 графиков разом. У нас есть скрипты, которые собирают данные в несколько небольших dashboard и они читают много rrd'шек, сильно больше 1000. То есть кеш на ключевых метриках работать не будет и винт будет грузиться
Да, большинство метрик не жалко вообще стереть, но и на них кеш будет переполняться и грузить винт и не давать работать ключевым метрикам.
Я вообще сомневаюсь, что кеш будет хорошо работать в случае одновременного апдейта всех rrd раз в 5 минут.
Идея то в чём, в том, что с точки зрения диска что записать одно измерение, что 20 одинаково трудоёмко, считать файл с диска и записать на диск.
То есть надо держать в памяти по несколько измерений каждой метрики, плюс некая служебная информация (которая в нашем мире динамической памяти часто очень большая). При этом надо постоянно обращаться к кешу при каждом чтении/записи, что тоже нагрузка на процессор.
Почему бы не положить всё в память и работать с памятью? Особенно если оно туда влазит. Быстрее же будет и заметно проще.
А оно влазит! Память стоит всё дешевле и дешевле, причём закон Мура тут ещё будет долго работать, в отличии от процессоров.
Он аккумулирует данные, но не даёт прочитать их из кеша. Только записать на диск. То есть если надо работать с данными, например посчитать агрегат или ещё чего, то есть записываем на диск и читаем с диска.
Плюс он сам пишет на диск в непредсказуемый момент.
Проблема в том, что никто не будет смотреть на 1000 графиков разом. У нас есть скрипты, которые собирают данные в несколько небольших dashboard и они читают много rrd'шек, сильно больше 1000. То есть кеш на ключевых метриках работать не будет и винт будет грузиться
Да, большинство метрик не жалко вообще стереть, но и на них кеш будет переполняться и грузить винт и не давать работать ключевым метрикам.
Я вообще сомневаюсь, что кеш будет хорошо работать в случае одновременного апдейта всех rrd раз в 5 минут.
Идея то в чём, в том, что с точки зрения диска что записать одно измерение, что 20 одинаково трудоёмко, считать файл с диска и записать на диск.
То есть надо держать в памяти по несколько измерений каждой метрики, плюс некая служебная информация (которая в нашем мире динамической памяти часто очень большая). При этом надо постоянно обращаться к кешу при каждом чтении/записи, что тоже нагрузка на процессор.
Почему бы не положить всё в память и работать с памятью? Особенно если оно туда влазит. Быстрее же будет и заметно проще.
А оно влазит! Память стоит всё дешевле и дешевле, причём закон Мура тут ещё будет долго работать, в отличии от процессоров.
0
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Стероиды для Munin