The first thing that is not right away apparent is that every host must belong to some group. So, this syntax is invalid:
[;myhost]
address ip.add.re.ss;
And this way you get a group with no hosts:
[myhost;]
...
You can check it by adding the following code after the following line:
foreach my $k (keys %$gah) {
DEBUG "-- $k";
foreach my $h (keys %{$gah->{$k}{'hosts'}}) {
DEBUG " $h";
}
}
Then run (a lot of output, you might probably want to add | tail -n 100
or something):
$ su - munin -s /bin/bash -c '/usr/share/munin/munin-update --debug'
...
2019/06/14 16:31:43 -- myhost1
2019/06/14 16:31:43 -- myhost2
2019/06/14 16:31:43 myhost2
2019/06/14 16:31:43 -- myhost3
2019/06/14 16:31:43 myhost3
...
So,
[myhost] # group "myhost", conaining host "myhost"
[foo.com] # group "com", containing host "foo.com"
[group;foo.com] # group "group", containing host "foo.com"
[group1;group2;foo.com] # group "group1", containing group "group2",
# which in its turn contains host "foo.com"
With that out of the way, the syntax is basically as follows:
[group1;host1]
...
[group1;host2]
...
[group1;virt_host1]
virt_plugin1.graph_title Some title
virt_plugin1.graph_order resulting_field_name1=host1:plugin1.field_name1 resulting_field_name2=host2:plugin2.field_name2
virt_plugin1
, resulting_field_name1
, resulting_field_name2
are all arbitrary names. virt_plugin1
appears in the breadcrumbs of the page. resulting_field_name*
becomes a graph's label. Unless you override it:
[group1;virt_host1]
...
virt_plugin1.resulting_field_name1.label = my_field_name
Regarding where to get (how to confirm) plugin and field names (data sources):
$ nc host1 4949
# munin node at host1
fetch plugin1
field_name1.value 0.17
.
Then, if you're borrowing data from a different group, you've got to specify it explicitly:
[group1;host1]
...
[group2;host2]
...
[group2;virt_host1]
virt_plugin1.graph_title Some title
virt_plugin1.graph_order resulting_field_name1=group1:host1.plugin1.field_name1 resulting_field_name2=host2:plugin2.field_name2
A note on when to expect changes to the config to take effect.
When html_strategy
is cgi
, munin-html
(as part of munin-cron
) writes state to /var/lib/munin/htmlconf.storable
every 5 minutes. The state contains settings of every host, and is used by munin-cgi-html
as a config.
So, either you wait for the next update, or trigger the update yourself:
$ su - munin -s /bin/bash -c /usr/share/munin/munin-html
Or:
$ su - munin -s /bin/bash -c munin-cron
In the same vein, munin-update
updates /var/lib/munin/datafile.storable
. But datafile
part is marked to include base, as opposed to htmlconf
one. Which means that contents of /etc/munin/munin.conf
is merged into datafile
part. And munin-cgi-graph
uses datafile
part for a config.
So you can just restart munin-cgi-graph
for it to notice the changes.
And the last thing, munin-cgi-graph
sets Expires
header. That means you've got to somehow reset/disable browser cache for browser to make the request.
In case you notify one of them, but not the other... Let me leave it as an exercise for the reader :)