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