draft_logging specs

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.

Current questions

1. What to log to stderr ? (agreed)
   • 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 --debug flag should send everything to stderr as currently done.
   • ssm: yes, we should keep this. See also "5: options"
2. 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
3. Logging to syslog
   • ssm: I'd like to do that per default

   • snide:

     • 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 munin-node.conf.

   • 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 :)
4. 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.
5. 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? --log-output syslog:debug,file:warning ?

  • 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 syslog: or --log-output file:,syslog: to avoid all logging.
  • In that respect, --debug would be an alias to --log-output stderr:debug.
  • 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

6. 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

7. 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 --debug nightmare that happend when munin-graph didn't understood it anymore [e0a1fe5].