Назад | Перейти на главную страницу

Мне нужно заменить munin на что-то более масштабируемое

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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