Munin Logging Specs

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
  1. 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
  1. 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].
Last modified at 2013-08-05T14:15:11+02:00 Last modified on 2013-08-05T14:15:11+02:00