Munin, не выводящий все диски на печать
Я наследовал забаву munin настроенный, таким образом, это может закончить тем, что было чем-то странным.
У меня есть сервер Windows Server 2008, выполняющий "Узел Munin Для Windows". С munin-сервером, работающим на отдельном поле Linux. Проблема с [Дисковый Плагин].
Мы только что добавили новый раздел на SAN (11-й диск), но это не появляется на munin графиках, которые сгенерированы.
Под управлением telnet и "выборка df" от поля Linux до окна показывают, что узел производит все необходимые значения: "_dev_0_. оцените" полностью "_dev_10_. значение".
Но на графике, это ничего не отображает для этого нового раздела (однако, все, что другие держатся в курсе).
Я перерыл настройки для любого вида ограничения на количестве графиков на график или отображение имен дисковода-> буквы и ничего не видел.
Версия Munin на Linux: 2.0.25
Я предполагаю, что это могло бы быть что-то очевидное, но я перестал работать при поиске решения. Не уверенный, какая информация совершенно релевантна; очень жаль, если это немного редко.
Ваша помощь значительно ценилась бы!Спасибо!
Обновление 1: следующее было получено из munin-графика - отладка:
04.02.2015 11:56:03 [ОТЛАДКА], Выполнение работает синхронно 04.02.2015 11:56:03 [ОТЛАДКА] root/XXXX/XXXXX/df, находится в (root/XXXX/XXXXX/df) 04.02.2015 11:56:03 [ОТЛАДКА] root/XXXX/XXXXX/df, находится в () 04.02.2015 11:56:03 [ОТЛАДКА] Имя узла: df 04.02.2015 11:56:03 [ОТЛАДКА] Расширяющее экстренное сообщение для df:>" _dev_0 _ "," _ dev_1 _ "," _ dev_2 _ "," _ dev_3 _ "," _ dev_4 _ "," _ dev_5 _ "," _ dev_6 _ "," _ dev_7 _ "," _ dev_8 _ "," _ dev_9 _ ". 04.02.2015 11:56:03 [ОТЛАДКА] expand_specials (): не обработанный, продолжаясь за $VAR1 = {'# %#name' => 'df', '_dev_0 _' => {'# %#name' => '_dev_0 _', 'очень важный' => '93', 'graph_data_size' => 'нормальный', 'маркируют' => 'C': 'update_rate' => '300', 'предупреждая' => '88'},
(и т.д.... полностью до _dev_9)
Это затем говорит вещи как:
04.02.2015 11:56:03 [ОТЛАДКА] сервис XXXXXX:: XXXXXX:: df имеет 10 элементов
graph_order мог устанавливаться где-нибудь на munin-стороне-сервера? Кажется немного нечетным?
Обновление 2: Так, rrd файлы выглядят хорошо, но после небольшого количества рытья похоже, что файлу данных не установили маркировку для него, и graph_order не включает _dev_10_.
Что устанавливает файл данных (/var/lib/munin/datafile)?? Это, кажется, вещь, которая используется munin-графиком для фактического рисования материала?
Я пытался добавить отсутствующие значения, но они были автоматически удалены??
Для любого изменения, сделанного на узле munin, вы должны перезапустить службу узла munin на этом узле (машине).
На этом компьютере с Windows перейдите в службы, найдите тот, который установлен munin, и перезапустите сервис.
Кажется, я нашел способ решить эту
с помощью вашего любимого редактора (у меня vi, но для простоты мы будем использовать nano)
sudo nano /etc/munin/plugin-conf.d/df
вставьте это
[df]
env.exclude none unknown iso9660 squashfs udf romfs ramfs vfat debugfs nilfs2 rootfs
env.warning 92
env.critical 98
env.include_re ^/home
[df_inode]
env.exclude none unknown iso9660 squashfs udf romfs ramfs vfat debugfs nilfs2 rootfs
env.warning 92
env.critical 98
env.include_re ^/home
, вы можете проверьте соответствующую строку, чтобы показать
sudo munin-run df
, в моем случае он возвращает устройство
_dev_vdb1.value 51.7198789876806
, затем перезапускает munin-node
sudo service munin-node restart
В Ubuntu 20.04 проблема с сервером была связана с systemd. Я решил это, изменив (как пользователь root) файл /usr/sbin/munin-run с:
my $ignore_systemd_properties = 0;
на:
my $ignore_systemd_properties = 1;
Или, как я выяснил, более правильное решение: изменить файл /lib/systemd/system/munin-node.service с:
ProtectHome=true
на:
ProtectHome=false
, а затем перезапустить службы:
systemctl restart munin-node
systemctl daemon-reload