Чтобы следить за тем, что происходит с нашими производственными серверами, я недавно обнаружил Мунин. Установка была тривиальной, но у меня много проблем с тем, как добавлять / удалять графики.
я нашел некоторая документация предлагая изменить их порядок, но очень мало обсуждения того, как управлять конфигурацией плагина. Большая часть документации плагинов обсуждает, как создавать плагины; а не использовать их.
Вопрос довольно простой: как мне использовать обширную библиотеку плагинов, чтобы я мог видеть, что происходит, например, с nginx, mysql и memcache.
Графики добавляются и удаляются через символьные ссылки в /etc/munin/plugins/
каталог узла.
Чтобы удалить график, вы должны удалить символическую ссылку и перезапустить узел:
rm /etc/munin/plugins/diskstats
service munin-node restart
Чтобы добавить график, вы должны добавить символическую ссылку в каталог плагинов на исполняемый файл. например:
ln -s /usr/share/munin/plugins/diskstats /etc/munin/plugins/diskstats
service munin-node restart
Когда вы перезапускаете munin-node, он запускается немедленно, и любые проблемы с плагинами появляются в /var/log/munin/munin-node.log
. Если все идет хорошо, вы увидите, что каждый цикл регистрируется CONNECT; это фиксирует тот факт, что мастер подключился для сбора последних данных.
Process Backgrounded
2014/03/10-15:59:47 Munin::Node::Server (type Net::Server::Fork) starting! pid(32231)
Resolved [*]:4949 to [::]:4949, IPv6
Not including resolved host [0.0.0.0] IPv4 because it will be handled by [::] IPv6
Binding to TCP port 4949 on host :: with IPv6
2014/03/10-16:00:04 CONNECT TCP Peer: "[::ffff:203.28.51.227]:45965" Local: "[::ffff:50.23.111.122]:4949"
2014/03/10-16:05:04 CONNECT TCP Peer: "[::ffff:203.28.51.227]:46109" Local: "[::ffff:50.23.111.122]:4949"
2014/03/10-16:10:04 CONNECT TCP Peer: "[::ffff:203.28.51.227]:46109" Local: "[::ffff:50.23.111.122]:4949"
Но, может быть, дела идут не очень хорошо. Ошибки при запуске плагинов также регистрируются здесь и являются критически важными ключами к тому, чтобы заставить плагин работать. Здесь мы видим проблему с плагином nginx_request ...
2014/03/10-11:25:05 CONNECT TCP Peer: "[::ffff:203.28.51.227]:38474" Local: "[::ffff:50.23.111.122]:4949"
2014/03/10-11:25:19 [22482] Error output from nginx_request:
2014/03/10-11:25:19 [22482] Use of uninitialized value $LWP::VERSION in sprintf at /etc/munin/plugins/nginx_request line 109.
2014/03/10-11:25:19 [22482] Can't locate object method "new" via package "LWP::UserAgent" at /etc/munin/plugins/nginx_request line 109.
2014/03/10-11:25:19 [22482] Service 'nginx_request' exited with status 2/0.
Плагины - это исполняемые программы, в основном написанные на Perl. Установлена большая коллекция по адресу /usr/share/munin/plugins/
(Ubuntu). Поскольку в большинстве своем они вносятся пользователями, они, по-видимому, сильно различаются по качеству, но все они должны запрашивать у системы необходимые данные, а затем преобразовывать их в формат, который может использовать munin.
Большинство из них полагаются либо на библиотеку Perl, которую вы, возможно, уже установили или не установили, либо на диагностическую программу для интересующей службы. Например плагин для лак требуется лакстат. Аналогично плагин для memcached.
Но вернемся к проблеме, описанной выше ... к счастью, я немного познакомился с Perl в свое время и сделал обоснованное предположение, что плагину требуется модуль Perl LWP :: Useragent. Если вы откроете плагин, который выдает ошибки, он может дать вам представление о его требованиях. Некоторые из них вы можете запустить из командной строки, чтобы увидеть, что произойдет / работают ли они.
Чтобы продолжить приведенный выше пример, это может привести к устранению ошибки nginx_request, показанной выше:
apt-get install libwww-perl
А может и нет ...
Например, nginx, если вы взглянете на src плагина, он обнаружит, что он собирает данные из http://localhost/nginx-status
поэтому вам нужно включить это. Или, как упоминалось ранее varnishstat
это пример.
Или, может быть, лучше оставить все как есть.
Кроме того, вам может потребоваться передать плагину некоторые переменные среды / конфигурации. Это делается путем редактирования /etc/munin/plugin-conf.d/munin-node
и добавляем все, что ему нужно. например:
[mysql_innodb]
env.warning 0
env.critical 0
Вы также можете сделать это, создав новый файл с таким содержанием, поскольку он будет обрабатывать любой файл в этом каталоге; но я этого не пробовал.
Чтобы протестировать плагин так, чтобы он действительно считывал переменные среды, есть инструмент munin-run
. Используйте его, просто указав файл в каталоге плагинов
% munin-run nginx_request
request.value 10275
%
Довольно много плагинов в /usr/share/munin/plugins/
В каталоге есть плагины, которые не работают, если вы просто ссылаетесь на них. Это те, у которых последний символ подчеркивания. например: memcached_
, diskstat_
, if_
. Они оставляют висящее подчеркивание, чтобы их можно было повторно использовать с различными параметрами.
Чтобы использовать их символическую ссылку из /etc/munin/plugins/
но добавьте параметр, который (а) может быть ключевым словом, например memcached_bytes
или, (b) может относиться к параметру, например: if_eth0
. Лучший способ понять, чего он ожидает, - это прочитать содержимое плагина. Некоторые из лучше сконструированных плагинов могут вам даже помочь. например: /usr/share/munin/plugins/mysql_ suggest
выводит список подходящих суффиксов.
lrwxrwxrwx 1 root root 36 Mar 10 11:45 mysql_bytes -> /usr/share/munin/plugins/mysql_bytes
lrwxrwxrwx 1 root root 31 Mar 10 11:47 mysql_commands -> /usr/share/munin/plugins/mysql_
lrwxrwxrwx 1 root root 31 Mar 10 11:45 mysql_connections -> /usr/share/munin/plugins/mysql_
lrwxrwxrwx 1 root root 31 Mar 10 11:46 mysql_qcache -> /usr/share/munin/plugins/mysql_
Мастер опрашивает узел на предмет данных, поэтому, если вы используете удаленный мастер, не забудьте предоставить ему доступ через /etc/munin/munin-node.conf
на узле.
Вы можете запустить мастер и узел на одном хосте. Или вы можете поместить мастер в другое место - что рекомендуется, если вы наблюдаете за загруженным производственным сервером, поскольку создание графиков каждые несколько минут - довольно большая работа.
У меня не возникло проблем, используя стандартную документацию и добавляя узлы в /etc/munin/munin.conf
.
Чтобы увидеть, как идет голосование, следите за /var/log/munin/munin-update.log
. Когда данные из нового плагина видны впервые, вы должны получить кучу записей журнала, в которых записывается создание новой базы данных rrd:
2014/03/10 12:45:15 [INFO] creating rrd-file for mysql_innodb->free: '/var/lib/munin/caradvice.com.au/syd.caradvice.com.au-mysql_innodb-free-g.rrd'
Здесь также можно найти предупреждения и ошибки, связанные с входящими данными.
Еще один заключительный момент заключается в том, что по умолчанию сбор данных узла происходит только каждые две минуты, а удаленный опрос - только каждые 5 минут. Кроме того, преобразование данных в графики может занять 60 секунд, и, наконец, первая запись, возможно, представляет собой единственную точку данных, которая не отображается. Итак, если вы не измените время цикла, между правильной настройкой плагина и появлением данных на графике может пройти 15 минут.
Я выдохся. Если это не поможет кому-то другому, это, по крайней мере, поможет мне вспомнить, что, черт возьми, я сделал.
Конечный результат - отличный инфопорн ...
Могу ли я удалить одни графики и добавить другие, все ли исправлено?
Удалите плагин из своего munin-node
конфигурации, и графики этого плагина будут удалены.
Как мне добавить плагины, чтобы показать мне, что происходит, например, с nginx, mysql и memcache.
Вы устанавливаете плагины munin для этих продуктов на munin-node
.