forked from munin-monitoring/munin
-
Notifications
You must be signed in to change notification settings - Fork 1
/
UPGRADING-1.4
104 lines (82 loc) · 4.28 KB
/
UPGRADING-1.4
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
Upgrading to 1.4
================
Upgrading from the Munin 1.2 series to 1.4 should be quite easy. But
there are some things to take note of if you want a very smooth
transition.
If you install from SVN or tar ball please make sure you read the
INSTALL file VERY carefuly. There are new package dependencies and
some bugs in the install process are noted there.
From Munin 1.2 in general
-------------------------
Based on comparisons of a few (very few) Munin installations on Linux
we see identical rrd file names, and rrd files are created and
structured the same way as before. This ensures that your data
history is preserved. Upgrading to 1.4 should therefore prove to be
straightforward and cause no data loss. BUT! There are a few
exceptions noted below.
In terms of ordering I would upgrade the master first. If you do not
use a packaging system you may have to look around for old .pm files
and purge them to get 1.4 to work propperly. Do NOT purge the RRD
files or the configuration.
After the master is upgraded upgrade the nodes one by one. Please see
notes about changes in plugin and data-field names in the sections
below before you start upgrading the nodes.
Changes in default paths
------------------------
If you do not use a packaging system please review Makefile.config and
after doing "make" the example munin.conf and note changes in default
paths, which you may or may not like, and if you do not keep the new
default htmldir you may want to edit Makefile.config, or alternatively
take a look at the .htaccess file installed in the default htmldir to
restrict public access to your munin (as described in the INSTALL
file)
From Munin 1.2.6
----------------
If you have munin-nodes running 1.2.6 then some of the plugins use
short (truncated) field names. Especially the Linux df plugin will be
using truncated fieldnames for some disk devices. This is due to a
basing a bug fix on obsolete documentation. The device names were
limited to 19 characters, only the 19 last characters of the device
name was used. This truncation is done by the plugin on the node.
When the plugin/node is upgraded the truncation stops.
There is no really reliable way to fix this or migrate automatically.
What you can do is install 1.4.0 on one node at a time, and for each
upgrade examine your rrd file names. You should be able to identify
rrd files for the upgraded node that have nearly identical names.
Personally I would use a graphical file browser for this. If you find
two files that should be one then the one with the longest filename
should be newest, and the one with the short file name should not have
been updated since the node upgrade. Rename the file with the short
name so that it has the long name.
On Solaris
----------
Some plugin renamings to get the name aligned with the other
platforms:
- if_errcoll_ is now called if_err_
- fs_df is now called df
- fs_inodes is now called df_inodes
You can simply rename the rrd files according to this (or you can
rename the plugins, but that will be a uphill battle, they'll be
renamed back when you upgrade the next time). Note that the plugins
will change names as you upgrade and auto-configure your nodes, not
when you upgrade the munin-master.
Users of Munin 1.2 in combination with NMSes
--------------------------------------------
There are two issues that have been reported.
Users of Munin in combination with Nagios have reported that because
some graphs have changed their "graph_title" setting this
dis-associates the tests from the right nagios checks.
Also some plugins do not have default warning and critical levels set
any more (e.g. "load") because the opinions on what is "normal" load
differs widely. This means that the plugins will not send warning and
critical events to contacts any more. The warning and critical levels
should be settable for all of these plugins, please use the command
"munindoc <plugin>" on the host where the plugin is installed to see
how to set these levels.
Too audit the differences in warning and critical levels you can make
a copy of the munin file called "datafile" before upgrading (or get
one from backup), and use egrep to get a listing of the settings prior
to update:
egrep '(warning|critical)' datafile.old
and again on the post-upgrade datafile to compare the lists so you can
specify the ones you need.