This is an optional configuration option for configuration files
in include_dir. It takes a comma separated list of additional
modules that is appended to the graph_name option. This enables
you to add custom modules without changing the monitorix.conf or
copy all names from graph_name to your config file.
A configuration file can contain sections, subsections and even
subsubsections in the form of:
<gensens> <-- this is a section or module
<list> <-- this is a subsection
0 = temp0
1 = cpu0
2 = bat0
</list>
...
If you plan to create an extra configuration file in 'conf.d/', you
must know that, from now on, you'll be forced to define the whole
subsection even when you are changing only a single value of it.
Otherwise your results might vary from what you expect.
For instance, imagine you want to monitor a second CPU in the
'gensens' module. You will create an extra configuration file in
'conf.d/' to include a second CPU (cpu1) in the key '1' inside the
subsection 'list'. In that case your extra configuration file
should define the section 'gensens' as this:
<gensens>
<list>
0 = temp0
1 = cpu0, cpu1
2 = bat0
</list>
</gensens>
That is, you must include the whole subsection 'list' with all the
rest of options. The rest of subsections of 'gensens' are not needed
because they have not been changed. Monitorix will use the subsections
configured in the main configuration file.
Now that in Multihost mode anyone can select the option "All" in the Hostname list and "All graphs" in the Graph list, this may, accidentally, hang the browser for a while due to the huge amount of images to download remotely from different servers.
In order to prevent precisely that, this new option defines which option in the Graph list will be selected ("System load" by default) automatically when the user selects 'All' in the Hostname list.
Of course, the user is still able to change it to "All graphs" at any moment, and at his own risk :-). #216
There is a well known problem with the HTTP built-in server that Monitorix
implements using the Perl module 'HTTP::Server::Simple'. It looks like it's
pretty weak to the common attacks that any web server receives every day.
As a consequence of that, it just hangs, and when you want to see the stats of
your server, you just see your browser waiting for a response that never comes,
which ends up with a timeout. In these cases, you are forced to login to your
server and restart Monitorix, in order to refresh the HTTP built-in server.
I was frustrated because I was completely unable to reproduce locally the kind
of attack that seems to do a DoS to the HTTP built-in server, so in order to
mitigate (hopefully) all this annoying hangups, I've created an autocheck to
control the responsiveness of the HTTP server on every minute, and in case of
no response then it will be restarted automatically. This is controlled by a new
option called 'autocheck_responsiveness' which by default is enabled.
Let's see how this is working!
Now the HTTP built-in will be restart every time Monitorix received the
SIGHUP signal. This should also fix thos annoying sporadic hangups of the
HTTP server, and also a truncation in the recent rotated logfile.
Removed the default installation 777 permission bits mode for the '/imgs/
directory in 'docs/monitorix.spec' and 'Makefile'.
Forced to setup the owner, group and the permission bits (now to 755) to the
'imgs/' directory every time Monitorix is started.
Jordi Sanfeliu
Andreas Bachlechner
z-eos
Georg Hofmann