1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
|
A munin script must fullfill the following requirements:
* Has to be executeable
* Filename should not contain ~ or # (skipping backupfiles)
* Accept the argument "config" to configure the rrd, which must return:
Needed:
- graph_title <title>
This is the titlebar in the rrdgraph.
Extra:
- graph_order <field_order>
In which order the graphs should be plotted.
- create_args [rrdcreate arguments]
extra arguments to rrdcreate
- graph_args [rrdgraph arguments]
extra arguments to rrdgraph
- graph_vlabel [label]
Y-axis label
- graph_total [label]
If set, summarise all the datasources' values and use the value
of graph_total as a label.
- graph_scale [yes|no]
Default yes. If unset, scaling of values below the graph (min,
max, cur) will not be done. Good for e.g. load (milliload
doesn't make much sense), but bad for graphs with large numbers.
- graph [yes|no]
Default yes. If unset, plugin will not be graphed.
- update [yes|no]
Default yes. If unset, plugin will never more be requested by
Munin.
- host_name [name]
If set, overrides which host_name the plugin belongs to. Rather
ugly - use the override in the node configuration instead.
Then you list the tings you want to meassure (all fields have a name
consisting of [a-zA-Z0-9_], where the first character is [a-zA-Z_]:
Needed:
- <field>.label <label>
This will become on of the lines on you graph. field is the
name of the rrdsource, label is the name we give it in the
graph
Extra:
- <field>.draw [LINE[1-3],AREA,STACK]
What type of graph field is (defaults to LINE2)
- <field>.type [COUNTER,GAUGE,ABSOLUTE,DERIVE]
What kind of datasource. (default is GAUGE)
- <field>.warn <limit>
A HRULE will be written in the graph for this field at
<limit> Later we can do fancy stuff if we cross the limit
- <field>.graph
If unset, don't graph this field.
- <field>.skipdraw
Don't draw this field. NOTE: Deprecated. Use graph instead.
- <field>.negative <negfield>
Use <negfield> as the negative value of this graph.
- <field>.cdef <cdef>
Feed <cdef> as a CDEF to rrdtool.
* When called without paramenters your script should return one or more:
<field>.value <value>
The rest of the requirements only apply if you want to submit your plugin
(the extra gizmos are used when installing the package):
* When called with the parameter "autoconf", should return 'yes' or 'no'
as to its own opinion of wether it should be run or not. The return value
should be set accordingly. (It's the return value that's used - the textual
result is only for "us humans". :-)
* If it's a "wildcard-script", it should accept the parameter
"suggest", which should list its probable uses.
* It should contain a magic marker, which matches the following perl
regular expression:
m/^#%# (.+)=(.+)$/;
where `$1' is the key and `$2' is the value. The currently recognised
keys are `family' and `capabilities`, however more may be added in the
future. It is customary to place this marker near the top of the
plugin.
* All plugins should belong to a family, as specified by one of the plugin's
magic markers. Currently known families are:
- auto
This specifies a plugin which is supported by the Munin developers,
and should work `out of the box' on most systems. It may have small
requirements to local configuration (such as the mysql_* plugins
which require mysqladmin to be able to connect passwordless), but
nothing major. Obviously, plugins which encode a certain service in
their name (such as exim_*) will require the encoded service to be
installed, but will still pass as an `auto'-plugin.
Perl-scripts which are "auto" cannot "use" any perl modules which are
not part of a standard perl installation (like "strict"). Use "require"
in "eval"s to find out if the module is available, and give the
appropriate "autoconf" result.
The fields "min" and "max" must exist for data values of type DERIVE,
and "max" for data values of type COUNTER.
- manual
This denotes a plugin which is supported by the Munin developers, but
requires significant amount of work from the user to make it work.
The plugin should explain briefly what actions are required in comments
near the top of the plugin itself. A good example of a manual plugin is
the apache-plugins, which requires the user to reconfigure Apache to
enable its mod_serverstatus feature.
Installation/setup scripts should typically not prompt the user for
enabling these plugins, unless it has some method of helping the
user through the labour needed to make it work properly.
The fields "min" and "max" must exist for data values of type DERIVE,
and "max" for data values of type COUNTER.
- contrib
Plugins which are not supported by the Munin developers, but are provided
in the hope that they will be useful to our users. This is typically
plugins contributed to us by others, or which have special requirements.
The plugin should preferably state an e-mail address in a comment, which
the user may contact if he has questions regarding that particular plugin.
If the family marker is omitted from a plugin, it is assumed to be in the
`contrib' family.
* All plugins should list their capabilities. Those that should be
listed in the magic marker, are:
- autoconf
Plugin supports autoconf parameter
- suggest
Plugin supports suggest parameter
When you're done adding a new service, restart munin-node. Munin will pick it
up in it's next sweep.
|
