Мне нужно заменить Мунин на что-то более масштабируемое [закрыто]


8

Я использовал munin на нескольких серверах в течение многих лет с большим успехом, однако с более чем 100 munin-узлами и при нагрузке на клиентов время ожидания истекает.

Я внес некоторые изменения в масштабирование задания cron и количества клиентских процессов, сократил количество запущенных плагинов и т. Д., Но я решил поискать альтернативу с более масштабируемой архитектурой.

Любые предложения или опыт будут приветствоваться. Меня в основном интересуют метрики серверов, которые можно использовать для планирования емкости и диагностики использования ресурсов. (у нас есть нагио для предупреждения)


Ответы:


8

Похоже, у вас могут быть две проблемы

  1. На вашем сервере мониторинга для записи показателей для большого количества серверов требуется больше случайных операций ввода-вывода, чем может обеспечить ваше хранилище. Даже если все ваши метрики записываются на диск, сервер может быть слишком перегружен, чтобы фактически генерировать из них графики.
  2. При мониторинге ваших клиентов плагины, которые собирают метрики, слишком загружают процессор и память и не заканчивают сбор данных вовремя, когда клиенты испытывают большую нагрузку.

Я использовал Munin в прошлом, но сейчас я использую collectd . Авторы collectd приложили немало усилий и усилий для решения этой проблемы. У них хорошо продуманная система записи данных в файлы RRD, которая гарантирует, что вы не потеряете данные, и может генерировать современные графики. Также есть поддержка RRDCacheD, Демон и официальные плагины написаны на C, поэтому они используют мало памяти или процессорного времени. В моих клиентских системах он использует менее 2 МБ ОЗУ и около четверти секунды процессорного времени каждую минуту. На моем сервере мониторинга он использует 20 МБ оперативной памяти и две трети секунды процессорного времени каждую минуту. Имейте в виду, что все мои метрики собираются и отправляются на мой сервер мониторинга каждые десять секунд, а не с интервалами в несколько минут, как в munin.


2
Мунин теперь имеет предварительную поддержку rrdcached. Это требует немного дополнительных усилий, чем установка по умолчанию. Это не голосование за или против munin / collectd, я только добавляю это, чтобы помочь любому, кто борется с настройкой munin и не имеет свободы действий в отношении изменения систем.
dfc

3

Хотя Munin и другие внешние интерфейсы RRDTool (такие как Cacti или Ganglia) являются отличными инструментами, они сталкиваются с проблемами ввода-вывода и их трудно масштабировать при мониторинге сотен узлов.

Есть несколько методов, чтобы справиться с этим узким местом ввода-вывода, хотя. Одним из таких методов является распределение записей по большому количеству дисков, чтобы уменьшить количество операций ввода-вывода на каждом диске. С другой стороны, многие системные администраторы используют файловые системы tmpfs для решения этой проблемы. RRDCached также является недавним и хорошим вариантом для решения этой проблемы, и я рекомендую вам взглянуть на эти слайды .

Я не очень знаком с Munin, но у Cacti есть плагин Boost . Этот плагин кэширует данные в памяти и выполняет массовые и по требованию обновления на диск вместо отдельных операций записи, тем самым сокращая число операций ввода-вывода. Я уверен, что у Мунина тоже есть что-то подобное.

Если вы можете себе это позволить, SSD-диски также являются хорошим вариантом.

И последнее, но не менее важное, вы также можете взглянуть на разведку . Recconoiter - это новый инструмент для обнаружения неисправностей и построения графиков / трендов. В отличие от большинства популярных инструментов, Reconnoiter не основан на RRDTool и пытается решить эту конкретную проблему. Я не использую Reconnoiter в производстве, но я провел несколько тестов и, несмотря на то, что все еще немного "зеленый", выглядит действительно многообещающе, особенно в отношении его масштабируемости.

Надеюсь это поможет!


Zabbix также не использует RRD, он использует бэкэнд, такой как MySQL или Postgres. Если вы правильно настроили свои шаблоны и не отслеживаете ненужные вещи, вы можете легко масштабировать.
coredump

2

Проверьте Zabbix . Это один из лучших инструментов мониторинга производительности с открытым исходным кодом. Он хорошо масштабируется и используется в средах с тысячами компьютеров.


0

Марко Рамос дает солидный совет. Однако я хочу добавить некоторые пояснения: большая проблема с Мунином - это фиксированный 5-минутный график сбора. Если все узлы не возвращают результаты в течение 5-минутного окна, вы начинаете получать исключения. Это самая большая проблема с Мунином.

Другие инструменты, основанные на rrdtool, такие как Ganglia, не заблокированы в этом же 5-минутном окне обновления, потому что они не опрашивают все источники данных так же, как это делает munin.

Я бы порекомендовал вам взглянуть на Ganglia, потому что, как правило, он хорошо масштабируется (хотя вам нужно отключить многоадресный сбор данных для большой установки ganglia). Я подозреваю, что с ганглиями вы можете пройти довольно долгий путь, прежде чем начнете беспокоиться о том, что rrdtool - это точка удушья. На этом этапе вы можете делать то, что предлагает Марко, например, использовать SSD-накопители.


действительно, вы правы, то же самое происходит с кактусами.
Марко Рамос

0

Я заменяю Munin w / Ganglia, Munin убивает мой сервер, поэтому я попробую Ganglia посмотреть, как он масштабируется.


Как прошло? Я сам заинтересован в такой замене ...
thanasisk

Я предпочитаю графики Мунина, но Ганглия работал хорошо. С тех пор я ушел с работы, но когда я ушел, я заменил Мунина Ганглием. С последней версией Munin я склонен думать, что они подправили использование памяти. Я не колеблясь, использовать любой, это вопрос предпочтений, я думаю.
luckytaxi
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.