Avoid hard coding database credentials in the script

Hm. Great idea! Really neat. As long as i understand the data collection mechanism in munin, every graph has to have its own plugin script doesn't it? If not, this suggestion might work really great. No script to generate, everything configurable in the admin backend and no possible security problems.

So: Time for a Version 2?

Each plugin could provide it's own individual script file, which can then be symlinked according to kbahey.

One could propose the following:
/modules/munin
/modules/munin/plugins
/modules/munin/plugins/nodes
/modules/munin/plugins/nodes/nodes-plugin.munin.php
/modules/munin/plugins/users
/modules/munin/plugins/users/users-plugin.munin.php
/modules/munin/plugins/mail
[...]
/modules/munin/plugins/watchdog
[...]

Each foo-plugin.munin.php file could then be symlinked manualy into /etc/munin/plugins. (to enable it)
Voilà, one script per graph.

Following this, the munin.module could simplify plugin development by providing it's API calls like this.

Example plugin code (php CLI)

  # You need to symlink this file into /etc/munin/plugins
  # and do /etc/init.d munin restart.

  # 1- Drupal boot
  require_once './includes/bootstrap.inc';
  drupal_bootstrap(DRUPAL_BOOTSTRAP_FULL);
  // this probably provides us with all module calls as well, I think?

  # 2- Munin.module go go go (static CLI code)
  print munin_plugin_run();
  
  # 3- Plugin implementation (callbacks and module magic)

  /**
    * handle munin plugin command line parameters
    * as well as plugin output
    * called during munin_plugin_run() on request
    * and during plugin runs
    */
  function mailqueue_munin_plugin($op) {
    switch $op:
      case 'autoconf':
        // [...] can this plugin do it's work?
        return 'yes';
        break;
      case 'print':
        // do some minor individual plugin magic
        $mail_queue_value= mailqueue_munin__plugin_get_current_queue_length();
        // ## munin_plugin_output($graph_label, $current_value);
        return munin_plugin_output('Drupal mailqueue', $mail_queue_value);
        break;
  }
  /**
   * conjure the current length of the drupal mailqueue
   * this is what the plugin is good for
   */
  function mailqueue_munin_plugin__get_current_queue_length() {
    // [...] e.g.
    return 500;
  }

API:munin_plugin_output() to do the heavy lifting of printing proper munin responses.
API:munin_plugin_run() to do things like $_SERVER['argv'] to react on 'autoconf' and 'conf' command line arguments. Calling _munin_plugin_run() with the correct $op.

Plugin development looks pretty easy this way.

Plugin developers would really only modify step 3 and implement individual plugin code there.

This would keep us from re-generating script files. Also it would keep us from updating drupal munin plugins upon any potential munin output format changes. (munin.module would handle any version changes)

And first of all, it would keep any db credentials within drupal. :)

Another idea: a Drush plugin, with only one symbolic link in the /etc/munin/plugins directory. So then after the one-time symlink, you could have all configuration in the Munin module's settings (or the settings for the modules that implement the Munin module's API). Or a short shell script that calls Drush with the right parameters.

Subscribe.

Subscribe.

See #1133544: Refactored for Drush, other changes

This is implemented for some time.