Protocol extension: dirtyconfig

The dirtyconfig capability is implemented in munin 2.0 and on.

Objective

Reduce execution time for plugins.

Description

Munin plugins are usually run twice. Once to provide configuration, and once to provide values.

Plugins which have to fetch data in order to provide meaningful configuration can use the “dirtyconfig” capability to send both configuration and values in the same run.

Using “dirtyconfig”, plugins no longer have to be run twice. There is no longer a need to keep a state file to keep state between “config” and “fetch” invocations for plugins with long execution times.

Network protocol

>> command from master to node
<< response from node to master
<< # munin node at somewhere.example.com
>> cap dirtyconfig
<< cap dirtyconfig
>> list
<< lorem ...
>> config lorem
<< graph_title Lorem ipsum
<< lorem.label Lorem
<< lorem.value 1

The master and node exchange capabilities with the cap command, with an argument list containing supported capabilities.

The server must send cap with dirtyconfig as one of the arguments.

The node must respond with cap, and include dirtyconfig as one of the capabilities.

Effects

The munin node will sets the MUNIN_CAP_DIRTYCONFIG variable to 1 in the plugin environment.

The munin master will call the plugin once with config plugin, and if the output includes .value fields, it will skip the fetch plugin step.

Using dirtyconfig

In a plugin, check the environment variable MUNIN_CAP_DIRTYCONFIG, ensure it has a value of 1.

If this is correct, you can emit values when the plugin is called with the config argument.

sample plugin

#!/bin/sh

emit_config() {
  echo "graph_title test with single word"
  echo "graph_category test"
  echo "test.label test"
}

emit_values() {
  echo "test.value 1"
}

case "$1" in
  config)
    emit_config
    if [ "$MUNIN_CAP_DIRTYCONFIG" = "1" ]; then
      emit_values
    fi
    ;;
  *)
    emit_values
    ;;
esac