Лучший / альтернативный интерфейс / графики для munin? [закрыто]
У меня запущена установка munin, и я хотел бы оставить настройку munin-node нетронутой, получая более продолжительное и подробное представление зарегистрированных данных. Я хочу, чтобы все регистрируемые данные оставались неопределенными. Идеальным решением было бы использовать что-то вроде виджета Аннотированная временная шкала , чтобы я мог увеличивать масштаб до любой точки истории.
Изменить: Я уже узнал, что munin использует базу данных с потерями, поэтому я ожидаю, что мне понадобится что-то, что ее заменит; то есть, если я не ошибаюсь, любой ответ, который не заменяет Мунина, скорее всего, не будет мне полезен.
Я надеюсь на замену munin, который может читать соответствующие разделы конфигурационных файлов munin (например, адреса всех узлов munin) и не требует никаких изменений в munin. -node installs
Munin, как каждый инструмент его типа, о котором я знаю, использует круговую базу данных или RRD, файлы, чтобы хранить его данные. Вот объяснение основ RRD. Файл RRD составлен из Круговых Архивов или RRAs. RRA "с потерями" в двух значениях слова, он комбинирует несколько точек данных в одну, и он перезаписывает данные после того, как определенная сумма собрана. Вы добираетесь, чтобы указать, как это сделано. Например, позволяет, говорят, что я создал файл RRD с командой
rrdtool create example.rrd \
[skip some necessary options]
--step 300
RRA:LAST:0.5:1:288 \
RRA:AVERAGE:0.5:12:168 \
RRA:AVERAGE:0.5:288:28
Шаг 300 говорит, что мы собираем метрики, которые rrdtool называет точками первичных данных или PDPs каждые 5 минут. Каждая строка RRA указывает четыре вещи, CF:xff:steps:rows.
1) CF или функция консолидации. Это определяет, как RRD комбинирует multipe точки первичных данных в объединенные точки данных или CDPS. Это может СОСТАВИТЬ В СРЕДНЕМ все значения, использовать МИН imum значение, использовать МАКСА imum значение или просто использовать ПОСЛЕДНЕЕ значение.
2) "x фактор файлов", то, что должно пропускать отношение данных, прежде чем CF возвратит значение НЕИЗВЕСТНЫХ скорее что работа на ненедостающих данных.
3) Шаги, который является, сколько точек первичных данных используется для вычисления объединенной точки данных.
4) Строки, который является сколько объединенных точек данных для хранения.
В нашем примере первый RRA сохранил бы Ваши точки первичных данных в течение одного дня, второе будет составлять в среднем Ваши точки первичных данных каждый час и сохранять ежедневные средние числа в течение одной недели, и третье составляло бы в среднем Ваши точки первичных данных каждый день и сохраняло бы ежедневные средние числа в течение четырех недель.
Если Вы хотите, чтобы Munin сохранил дольше и более подробные данные, используйте файлы RRD, которые имеют RRAs с более низкими шагами и более высокими строками. Этим управляет graph_data_size опция. Munin имеет человекочитаемый синтаксис для создания этого легким настроить. Опции в нашем более раннем примере перевели бы в
graph_data_size custom 5m for 1d, 1h for 1w, 1d for 4w
Если Вы хотите сохранить свои точки первичных данных в течение двух лет, можно срезать путь и установить graph_data_size на огромный.
После изменения этой опции необходимо удалить существующие файлы RRD, таким образом, Munin создаст новые с новыми настройками хранения
Я недавно оценил набор отклонения / предупреждение инструментов.
По крайней мере, на их агенте / модель коллектора, там, кажись, быть 2 различными моделями, "nagios / модель запроса" и "системный журнал / создание отчетов" о модели.
Таким образом в активной модели Вы имеете
Nagios: главным образом для предупреждений, но с некоторой функциональностью построения графика, привитой на.
Zabbix: отклонение / объединенное предупреждение. Хранит данные в базе данных SQL бэкэнда (таким образом, данные не потеряны / округленный как с базами данных RRD).
Munin: отклонение / с плагинами для отправки данных в nagios (т.е. Вы собираете данные с munin затем, запускает nagios программу, которая смотрит на локальные данные, таким образом, Вам не нужны и munin и в nagios агент в удаленной системе).
Модель "системного журнала" использует или многоадресную передачу или одноадресную модель UDP, куда контролируемая система отправляет пакет UDP на коллектор каждый интервал времени. Трафик нежелателен; система отчетности просто отправляет ему каждый интервал независимо от того, если система контроля произошла или нет.
collectd и ганглии оба следуют этой модели. Я никогда не использовал ганглии, но collectd имеет немного плагина, который может сообщить / предупреждают / критическое состояние nagios (и это также сообщает, не видело ли это данные из хоста в 3 интервала времени, таким образом, Вы видите, отказала ли система, потому что это не звонит домой).
Collectd имеет ужасное построение графика / инструменты создания отчетов из поля, но он производит любого / и RRD и текстовые файлы CSV (имя, time_t, значение), таким образом, можно прокрутить собственную панель инструментов довольно легко.
Я не играл с ганглиями слишком много.
Munin использует RRDTool, чтобы хранить его данные. С хранением данных RRD-стиля Вы теряете разрешение точки данных со временем, таким образом, Ваше требование, чтобы смочь "увеличить масштаб к любому моменту в истории" не работало бы.
Может быть способ заставить munin использовать некоторый другой тип устройства хранения данных бэкенда, но у меня никогда не было потребности, для которой так не может подтвердить, что это действительно возможно.
Его старая, но все еще используемая метрическая технология. В нашей компании мы используем что-то под названием MuninMX. Это замена коллектора в java с интерфейсом на основе php.
круто то, что нам не нужно было заменять munin, мы просто подключили другой сборщик и интерфейс. И профи. Он использует tokumx в качестве серверной части хранилища, а не файлы rrd.
мы отслеживаем около 1000 узлов с 50 тыс. Плагинов в общей сложности на одном четырехъядерном компьютере без проблем с io.
также кажется, что исходный munin перемещается в базу данных конфигурация и json api. Может быть, со временем munin сможет также хранить данные, например, в infxdb.