Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Munin Logging Specs
Content from Munin Trac Wiki. Was written by ssm and snide between 2013-07-30 and 2013-08-05.
As discussed on IRC, a new logging system is needed for Munin.
Stig already did many improvements, mostly in replacing existing logging with the Log::Dispatch module, but now several designs questions needs to be answered. This page is here for this purpose. It will then be exported to the "Munin Guide".
The current code [de43ae291] includes:
- Logging to STDERR
- Logging to Syslog
- Logging to File
The Munin::Common::Logger module can (should) be used from master, node and the munin plugin perl module.
- What to log to
- ssm: by default, I'd like to log everything of severity "critical" to STDERR.
- snide: it all depends on how you launch the components. I think logging to stderr should be only before the logging is properly initialized. Using the
--debugflag should send everything to
stderras currently done.
- ssm: yes, we should keep this. See also "5: options"
- Logging to file by default, or optional? (agreed)
- ssm: I'd like to not to log to file by default
- snide: I'd prefer to have a seamless upgrade path. That is, per default, do the same thing as before. At least in term of log files & filenames. Content may vary.
- ssm: ok
- Logging to syslog
- ssm: I'd like to do that per default
- Can you provide a syslog configuration that emulates the old behavior ?
- Would you have a sample for logging configuration in
munin.conf? Ideally it would be the same syntax as the one in
- ssm: - the syslog configuration that emulates the old behaviour is "don't log to syslog". - sample configuration files
- snide: yet, the logging to syslog should only be a matter of uncommenting a sample comment line in the config file :)
- How to handle logging when you've got syntax errors in
munin.conf, which may configure logging, etc... (agreed)
- snide: as said before, I think it's best to blindely use STDERR until logging is fully configured.
- ssm: A sensible default, and should be easy to configure.
- Logging options
- ssm: I'd like to split severity and destination. However: --debug would be an expected alias for "log to screen with minimum-severity debug". I'll keep this. I'd do the same thing with --verbose and --quiet regarding output to screen.
- ssm: Option names and format are not set, what if I want debug logging to syslog, and warnings to file?
- snide: sounds quite sane to me.
- I'd like a way of option in the config file to have their command line counterparts.
- Also, what do you think about having multiple additive
--log-output? It would add if the target isn't the same. To disable an output, just add an empty one as :
--log-output file:,syslog:to avoid all logging.
- In that respect,
--debugwould be an alias to
- Stays the question, what file would the the
file:refer to ?
- ssm: file: would refer to $logdirectory/munin-$component.log by default. munin-update would log to /var/log/munin/munin-update.log
- Configuration files
Configuration of logging. Example:
# Default logging log_output syslog:warning # Override logging for "munin-update", add debugging to default log file update_log_output syslog:warning, file:debug
- Command line arguments
Map directly to the configuration file syntax?
log_output maps to
--log-output, with the same argument ?
- snide: that's a real plus to me. It enables to have a very sane overriding behavior. Besides, it can also be done for more than just logging.
--limits-log-output would make no sense for munin-limits, but may for munin-cron.
- snide: Every option that are fairly generic should be allow on every
munin-*. It enables a generic calling scheme in
munin-cron. Otherwise we'll just reproduce the
--debugnightmare that happend when
munin-graphdidn't understood it anymore [e0a1fe5].