Munin - draw beautiful graphics
This article discusses a monitoring tool such as Munin. Strange, but the search assures me that the article about him on Habré has not yet been. This tool exists under * NIX (Linux, xBSD, Solaris) and Windows and allows you to centrally monitor and visually display the status of the sponsored systems. Initially used to draw graphs, but it can also be used as a pure means of observation. The big plus of Munin is flexibility (all graphs are drawn by plugins active on target systems, and no one forbids using only those plugins that are needed) and the ability to collect information about many others from one server. Accordingly, the load on the observed server is minimal. Interesting? Welcome under cat
')
Munin is not a new enough system developed on the RRDTool graphing tool that is popular among administrators. Let me remind you that the ideology of RRDTool is to store data on a “carousel” type — when filling a fixed-size database, RRDTool starts to wipe data from the base's tail (that is, from the old ones) to the head (to the new ones), which guarantees the loss of the minimum amount of useful data, but with This allows the database not to swell to insane sizes (like in HP OpenView or Zabbix). Usually there are several carousels in the RRDTool database - for example, “instant data” (stored a week), average for 5 minutes (generated based on instant data, stored a month) and average per hour (generated on the basis of 5 minutes, stored a year. Such a database weighs only a few megabytes, and in size never changes (if there is no data in the database, there are just zeros in the tail of the carousel, all the data slots are created in the database). Minus the RRDTool in its own plus. You need to carefully calculate the capacity of the database, because you edit the base is no longer possible zhno and pull data to be transferred to another base (analogue DUMP in SQL databases.) - also Also, RRDTool responsible only for the storage of data, and their's still where it is necessary to take ... Initially administrators used to this samopisnye scripts "on what the liver wants ”, traditionally the first places were occupied by the omnipresent Bash and the brainwave Perl (in the latter even there is an extension for working with RRD, other languages are forced to use“ struts ”in the form of a call rrdtool directly from the command line). All the scripts were different, the quality of the code and the optimization of the work of such scripts was walking in the broadest limits. I myself, at the very dawn of my admin's career, wrote similar scripts, and wrote “in the forehead,” a simple script for five parameters could run for a few seconds. Of course, in the case when a need arises (in a tool for convenient drawing of graphs), a tool arises. The Munin project became such an instrument.
Munin consists of two separate parts. The first is the server (munin itself) - it polls the clients, stores the base and draws graphs. The second is the client (munin-node). The connection with the client always initiates the server (it is launched by cron). At startup, the server reads the config with a list of client addresses, addresses each client (port - 4949 / tcp), receives a list of possible parameters, and then - according to the list - parameter values. The resulting data is loaded into RRD-files (if there are none, the server will create it). Drawing a separate chart is managed by a separate process, which, although included in the munin package, lives a completely independent life.
Unlike a server, a client is a demon resident in memory. It is written, as well as the server, on pure perl. By the way, the only authorization method is IP, from which the connection is initiated. There is also no encryption there, so I do not advise you to shine the demon, the firewall and attentive configuration of the config have not been canceled. An interesting fact, but the demon itself does not know anything about the system in which it is located. The data that the client gives to the server, it receives from the plug-in programs that it runs sequentially. Due to this, the load on the server is optimized (you can always leave only those plugins that are needed), and at the same time, the downtime of the demon, which should not painfully invent parameters that have never happened in this particular system, decreases.
As I mentioned above, munin consists of two packages. They are put trivially, but you need to be prepared for the fact that munin (server) will drag along a considerable mountain of packages responsible for RRD and graphics (GD). If you need to monitor one server, you need to install both packages (example for debian):
Unlike monit, munin cannot perform any actions in the system (except for collecting statistics), as a result, it can be started immediately after installation. On Debian GNU / Linux and CentOS, the daemon starts by itself:
Activation of plug-ins is also made simple and simple - in the folder with the munin settings (in linux this is / etc / munin, and in freebsd - / usr / local / etc / munin) there is a plugins folder. All plugins present in the folder at the time of launch munin-node are considered active. If the present plugin for some reason refuses to work (for example, the MySQL data collection plugin when the mysqld service is stopped), the node will return 0 when trying to get information from the plugin.
In fact, all available plugins are usually in a different place, and symlinks are stored in this folder.
Here is an example:
Initially, a considerable number of plug-ins are shipped with munin (I’ll draw your attention - not all are active!), In addition, there are sites where plug-ins are also posted. In addition, there is a guide to writing plug-ins yourself, but this topic is already significantly beyond the scope of the article.
Some plugins support call arguments. Here is a prime example:
Real plugin file
But what lies in the configuration directory:
Without arguments, such plugins are useless to call - they will not understand what they want from them.
Some plugins support advanced settings. For example, for a plugin that collects information about MySQL, you can set a login and password to log on to the server. Munin stores similar settings in the {confdir} /plugin-conf.d/munin-node file.
The file is commented in some detail, but I will give a couple of examples here, just in case:
As you can see from the example above, the syntax of the file is very simple.
We turn the spreading of thought on the tree. Now - clear and understandable step by step instructions.
Installing packages made by OS means, I do not advise collecting them from SRC. Consider a situation where the observer and the observed are physically one machine.
To begin, configure the client:
Changing the config or list of plugins requires restarting the daemon. When changing the list of plugins, it is necessary to restart the daemon, kill -HUP will not help in this situation.
We check the work of the demon:
Command list we received a list of active plugins, command fetch - received data from one plugin. The monitoring daemon behaves in the same way, which makes it possible with a high degree of certainty to make sure that the client node works correctly.
Now go to the server. Unlike the client (node) - the server does not exist as a process, it starts only at the moments of receiving data and drawing graphs (and not always, this issue will be discussed below)
In the process list it looks like this:
Daemon settings are in {config} /munin.conf
He is also commented on in great detail, and below I will give the minimum workable example.
The above settings are enough for normal operation. These settings are specified in more detail in the documentation, but there is no need to wait a lot from munin - this is a useful, but very simple and limited tool.
UPD: At the request of workers added pictures already installed munin
List of hosts in surveillance:
Examples of graphs:
What?
')
Munin is not a new enough system developed on the RRDTool graphing tool that is popular among administrators. Let me remind you that the ideology of RRDTool is to store data on a “carousel” type — when filling a fixed-size database, RRDTool starts to wipe data from the base's tail (that is, from the old ones) to the head (to the new ones), which guarantees the loss of the minimum amount of useful data, but with This allows the database not to swell to insane sizes (like in HP OpenView or Zabbix). Usually there are several carousels in the RRDTool database - for example, “instant data” (stored a week), average for 5 minutes (generated based on instant data, stored a month) and average per hour (generated on the basis of 5 minutes, stored a year. Such a database weighs only a few megabytes, and in size never changes (if there is no data in the database, there are just zeros in the tail of the carousel, all the data slots are created in the database). Minus the RRDTool in its own plus. You need to carefully calculate the capacity of the database, because you edit the base is no longer possible zhno and pull data to be transferred to another base (analogue DUMP in SQL databases.) - also Also, RRDTool responsible only for the storage of data, and their's still where it is necessary to take ... Initially administrators used to this samopisnye scripts "on what the liver wants ”, traditionally the first places were occupied by the omnipresent Bash and the brainwave Perl (in the latter even there is an extension for working with RRD, other languages are forced to use“ struts ”in the form of a call rrdtool directly from the command line). All the scripts were different, the quality of the code and the optimization of the work of such scripts was walking in the broadest limits. I myself, at the very dawn of my admin's career, wrote similar scripts, and wrote “in the forehead,” a simple script for five parameters could run for a few seconds. Of course, in the case when a need arises (in a tool for convenient drawing of graphs), a tool arises. The Munin project became such an instrument.
Overview and Architecture
Munin consists of two separate parts. The first is the server (munin itself) - it polls the clients, stores the base and draws graphs. The second is the client (munin-node). The connection with the client always initiates the server (it is launched by cron). At startup, the server reads the config with a list of client addresses, addresses each client (port - 4949 / tcp), receives a list of possible parameters, and then - according to the list - parameter values. The resulting data is loaded into RRD-files (if there are none, the server will create it). Drawing a separate chart is managed by a separate process, which, although included in the munin package, lives a completely independent life.
Unlike a server, a client is a demon resident in memory. It is written, as well as the server, on pure perl. By the way, the only authorization method is IP, from which the connection is initiated. There is also no encryption there, so I do not advise you to shine the demon, the firewall and attentive configuration of the config have not been canceled. An interesting fact, but the demon itself does not know anything about the system in which it is located. The data that the client gives to the server, it receives from the plug-in programs that it runs sequentially. Due to this, the load on the server is optimized (you can always leave only those plugins that are needed), and at the same time, the downtime of the demon, which should not painfully invent parameters that have never happened in this particular system, decreases.
how
Installation and diagnostics
As I mentioned above, munin consists of two packages. They are put trivially, but you need to be prepared for the fact that munin (server) will drag along a considerable mountain of packages responsible for RRD and graphics (GD). If you need to monitor one server, you need to install both packages (example for debian):
apt-get install munin munin-node
....
Unlike monit, munin cannot perform any actions in the system (except for collecting statistics), as a result, it can be started immediately after installation. On Debian GNU / Linux and CentOS, the daemon starts by itself:
lab:~# ps ax | grep muni
16139 ? Ss 0:00 /usr/sbin/munin-node
Activation of plug-ins is also made simple and simple - in the folder with the munin settings (in linux this is / etc / munin, and in freebsd - / usr / local / etc / munin) there is a plugins folder. All plugins present in the folder at the time of launch munin-node are considered active. If the present plugin for some reason refuses to work (for example, the MySQL data collection plugin when the mysqld service is stopped), the node will return 0 when trying to get information from the plugin.
In fact, all available plugins are usually in a different place, and symlinks are stored in this folder.
Here is an example:
lab:~# ls -al /etc/munin/plugins/
total 2
drwxr-xr-x 2 root root 1024 2009-06-21 15:31 .
drwxr-xr-x 5 root root 1024 2010-02-11 23:35 ..
lrwxrwxrwx 1 root root 29 2009-05-19 16:39 acpi -> /usr/share/munin/plugins/acpi
lrwxrwxrwx 1 root root 28 2009-03-22 22:51 cpu -> /usr/share/munin/plugins/cpu
lrwxrwxrwx 1 root root 27 2009-03-22 22:51 df -> /usr/share/munin/plugins/df
lrwxrwxrwx 1 root root 33 2009-03-22 22:51 df_inode -> /usr/share/munin/plugins/df_inode
...
Initially, a considerable number of plug-ins are shipped with munin (I’ll draw your attention - not all are active!), In addition, there are sites where plug-ins are also posted. In addition, there is a guide to writing plug-ins yourself, but this topic is already significantly beyond the scope of the article.
Some plugins support call arguments. Here is a prime example:
Real plugin file
-rwxr-xr-x 1 root root 4775 2009-11-25 13:38 if_
-rwxr-xr-x 1 root root 3164 2009-11-25 13:38 if_err_
But what lies in the configuration directory:
lab:~# ls -al /etc/munin/plugins/ | grep if
lrwxrwxrwx 1 root root 32 2009-03-22 22:51 if_err_eth0 -> /usr/share/munin/plugins/if_err_
lrwxrwxrwx 1 root root 32 2009-03-22 22:51 if_err_eth1 -> /usr/share/munin/plugins/if_err_
lrwxrwxrwx 1 root root 28 2009-03-22 22:51 if_eth0 -> /usr/share/munin/plugins/if_
lrwxrwxrwx 1 root root 28 2009-03-22 22:51 if_eth1 -> /usr/share/munin/plugins/if_
lrwxrwxrwx 1 root root 28 2009-06-21 15:31 if_tun0 -> /usr/share/munin/plugins/if_
Without arguments, such plugins are useless to call - they will not understand what they want from them.
Some plugins support advanced settings. For example, for a plugin that collects information about MySQL, you can set a login and password to log on to the server. Munin stores similar settings in the {confdir} /plugin-conf.d/munin-node file.
The file is commented in some detail, but I will give a couple of examples here, just in case:
# APT
[apt]
# root. APT
user root
# smart_, smart_{DISK}
[smart_*]
# , root smartctl
user root
# postgres_queries, mngsearch
[postgres_queries_mngsearch]
#env.{} . source-
# mngsearch
env.PGUSER mngsearch
env.PGPASSWORD Yn2ajPV4f6V5rzqj
As you can see from the example above, the syntax of the file is very simple.
step by step instructions
We turn the spreading of thought on the tree. Now - clear and understandable step by step instructions.
Installing packages made by OS means, I do not advise collecting them from SRC. Consider a situation where the observer and the observed are physically one machine.
To begin, configure the client:
vi /etc/munin/munin-node.conf
...
log_level 4
#"" munin . 10 - , 1 -
log_file /var/log/munin/munin-node.log
# .
pid_file /var/run/munin/munin-node.pid
#pid-file,
background 1
# . 0 -
setseid 1
user root
group root
# . root, ID ,
# root
setsid yes
# ID .
allow ^127\.0\.0\.1$
# IP . - 127.0.0.1
# , , (RegExp).
host 127.0.0.1
# IP . - 127.0.0.1
port 4949
#, .
Changing the config or list of plugins requires restarting the daemon. When changing the list of plugins, it is necessary to restart the daemon, kill -HUP will not help in this situation.
We check the work of the demon:
lab:/etc/munin# telnet 127.0.0.1 4949
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
# munin node at lab.local.logan
list
open_inodes ip_127.0.0.1 postgres_queries_mngsearch irqstats
if_eth0 squid_cache sensors_temp df tor_connections swap
load cpu df_inode smart_hda forks iostat sensors_fan open_files
memory postgres_queries_netams exim_mailqueue vmstat sensors_volt
if_err_eth0 entropy processes acpi interrupts mysql_bytes if_tun0 if_err_eth1
if_eth1 tor_traffic exim_mailstats
fetch ip_127.0.0.1
in.value 83599135
out.value 83599135
.
quit
Connection closed by foreign host.
Command list we received a list of active plugins, command fetch - received data from one plugin. The monitoring daemon behaves in the same way, which makes it possible with a high degree of certainty to make sure that the client node works correctly.
Now go to the server. Unlike the client (node) - the server does not exist as a process, it starts only at the moments of receiving data and drawing graphs (and not always, this issue will be discussed below)
In the process list it looks like this:
lab:~# ps ax | grep muni
16139 ? Ss 0:00 /usr/sbin/munin-node
17841 ? Ss 0:00 /bin/sh -c if [ -x /usr/bin/munin-cron ]; then /usr/bin/munin-cron; fi
17842 ? S 0:00 /bin/sh /usr/bin/munin-cron
17843 ? S 0:00 /usr/bin/perl -w /usr/share/munin/munin-update
17846 ? S 0:00 /usr/share/munin/munin-update [r1sz.zooclub.ru]
17847 ? S 0:00 /usr/share/munin/munin-update [web1.zooclub.ru]
17848 ? S 0:00 /usr/share/munin/munin-update [monitor-01.infobox.ru]
17849 ? S 0:00 /usr/share/munin/munin-update [stat.kpp.ru]
17851 ? S 0:00 /usr/share/munin/munin-update [ro2-h.local]
17852 ? S 0:00 /usr/share/munin/munin-update [ro1-h.local]
17853 ? S 0:00 /usr/sbin/munin-node
17859 ? Rs 0:00 /usr/bin/perl /etc/munin/plugins/postgres_queries_mngsearch config
Daemon settings are in {config} /munin.conf
He is also commented on in great detail, and below I will give the minimum workable example.
dbdir /home/db/monitor
#, RRD. , rrd
htmldir /home/www/mon
#
logdir /var/log/munin
#
rundir /var/run/munin
#
[lab.local]
address 127.0.0.1
use_node_name yes
# , , .
[midori.local]
# ,
address 10.9.8.7
use_node_name yes
[web2.zooclub.ru]
#
address 77.221.150.98
use_node_name yes
contact.logan.command mail -s "Munin notification" logan@mydomain.my
# . . (<->)
#graph_strategy cgi
# CGI . , .
# ( ) - .
The above settings are enough for normal operation. These settings are specified in more detail in the documentation, but there is no need to wait a lot from munin - this is a useful, but very simple and limited tool.
UPD: At the request of workers added pictures already installed munin
List of hosts in surveillance:
Examples of graphs:
Source: https://habr.com/ru/post/83958/
All Articles