У меня запущена установка munin, и я хотел бы оставить настройку munin-node нетронутой, получая более продолжительный и подробный просмотр зарегистрированных данных. Я хочу, чтобы все регистрируемые данные оставались неопределенными. Идеальным решением было бы использовать что-то вроде аннотированная временная шкала виджет, чтобы я мог увеличивать масштаб до любой точки истории.
Редактировать: Я уже узнал, что munin использует базу данных с потерями, поэтому я ожидаю, что мне понадобится что-то, что ее заменит; т.е. если я не ошибаюсь, любой ответ, не заменяющий Мунина, скорее всего, мне не пригодится.
Я надеюсь на замену munin, который может читать соответствующие разделы конфигурационных файлов munin (например, адреса всех узлов munin) и вообще не потребует каких-либо изменений для установки munin-node.
Munin, как и все известные мне инструменты подобного типа, использует файлы циклической базы данных, или RRD, для хранения своих данных. Вот объяснение основ RRD. Файл RRD состоит из циклических архивов или RRA. 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 называет первичными точками данных или PDP, каждые 5 минут. Каждая строка RRA определяет четыре вещи: CF: xff: шаги: строки.
1) CF или функция консолидации. Это определяет, как RRD объединяет множественные первичные точки данных в консолидированные точки данных или CDP. Это может СРЕДНИЙ все значения используйте MIN imum value, используйте МАКСИМУМ imum value или просто используйте ПОСЛЕДНИЙ стоимость.
2) «Коэффициент x файлов» - это соотношение данных, которое должно быть пропущено, прежде чем CF вернет значение НЕИЗВЕСТНО скорее, чем оперировать не пропущенными данными.
3) Шаги, которые определяют количество точек первичных данных, используемых для вычисления точки консолидированных данных.
4) Строки - сколько точек консолидированных данных следует сохранить.
В нашем примере первый RRA будет хранить ваши первичные точки данных в течение одного дня, второй будет усреднять ваши первичные данные каждый час и сохранять среднесуточные значения в течение одной недели, а третий будет усреднять ваши первичные точки данных каждый день и сохранять среднесуточные в течение четырех недель.
Если вы хотите, чтобы Munin сохранял более длинные и подробные данные, используйте файлы RRD, в которых есть RRA с более низкими шагами и более высокими строками. Это контролируется graph_data_size вариант. Мунин имеет удобочитаемый синтаксис чтобы упростить настройку. Параметры в нашем предыдущем примере будут преобразованы в
graph_data_size custom 5m for 1d, 1h for 1w, 1d for 4w
Если вы хотите сохранить свои первичные данные в течение двух лет, вы можете воспользоваться ярлыком и установить graph_data_size к огромный.
После изменения этого параметра вам необходимо удалить существующие файлы RRD, чтобы Munin создал новые с вашими новыми настройками хранения.
Недавно я оценил множество инструментов для отслеживания тенденций и предупреждений.
По крайней мере, в их модели агент / сборщик, похоже, есть 2 разные модели: модель «nagios / запрос» и модель «системный журнал / отчетность».
Итак, в активной модели у вас есть
Nagios: в основном для предупреждений, но с некоторыми графическая функциональность привиты.
Zabbix: объединение трендов и предупреждений. Хранит данные во внутренней базе данных SQL (поэтому данные не теряются / не округляются, как в базах данных RRD).
Мунин: trending / с плагинами для отправки данных в nagios (т.е. вы собираете данные с помощью munin, а затем запускаете программу nagios, которая просматривает локальные данные, поэтому вам не нужны одновременно агент munin и nagios в удаленной системе).
Модель «syslog» использует модель UDP с многоадресной или одноадресной рассылкой, когда отслеживаемая система отправляет пакет UDP на сборщик каждый интервал времени. Трафик не запрашивается; система отчетов просто отправляет их каждый интервал, независимо от того, работает система мониторинга или нет.
собирать и ганглии оба следуют этой модели. Я никогда не использовал ганглии, но у collectd есть небольшой плагин, который может сообщать nagios о состоянии / предупреждении / критическом статусе (и он также сообщает, не видел ли он данные с хоста через 3 интервала времени, чтобы вы могли видеть, произошел ли сбой системы потому что он не звонит домой).
Collectd имеет ужасные инструменты построения графиков / отчетов из коробки, но он выводит текстовые файлы RRD и CSV (имя, time_t, значение), так что вы можете легко создать собственную панель инструментов.
Я не слишком много играл с ганглиями.
Munin использует RRDTool для хранения своих данных. С хранением данных в стиле RRD вы теряете разрешение точки данных с течением времени, поэтому ваше требование иметь возможность «увеличивать масштаб до любой точки в истории» не будет работать.
Может быть способ заставить munin использовать какой-либо другой тип внутреннего хранилища, но у меня никогда не было необходимости в этом, поэтому я не могу подтвердить, что это действительно возможно.
Его старый, но мунин все еще используется в метрической системе. В нашей компании мы используем что-то под названием MuninMX. Это замена коллектора в java с интерфейсом на основе php.
круто то, что нам не нужно было заменять munin, мы просто подключили другой сборщик и интерфейс. И профи. Он использует tokumx как серверную часть хранилища, а не файлы rrd.
мы отслеживаем около 1000 узлов с 50k плагинами в общей сложности на одной четырехъядерной машине без проблем с io.
также кажется, что исходный munin, похоже, переходит на конфигурацию базы данных и json api. Может быть, со временем munin также сможет хранить данные, например, в Infxdb.