Let's make an example init-script for starting/stopping pipe-to-graphite. Target RHEL/CentOS to start, since that's what we use.
But then we'd have to architect it somewhat differently as right now you need to start the script once per script/* file.
How about we make it for one, and it's up to the user to copy+modify it for each service they wish to use? Either that, or we make a config entry for all the different commands to be run, and one master init-script controls them all.
At first glance, the separation seems like it'd be useful, but I suppose that if you want to get rid of one (or add one), you just change the config and service pipe-to-graphite reload (or whatever). collectd, for instance, operates with one service controlling a number of different plugins.
service pipe-to-graphite reload
I like the second option (one service, multiple plugins).
It wouldn't be too hard to change it. It would jut be passed a dir of plugins instead of a single one when starting up. Perhaps a .gitignored dir in the repo with symlinks to each pertinent script for the host. Though some of these scripts have arguments... or do they?
They do. The mysql ones, for instance, take an option for including metrics that have a value of zero.
Perhaps we should have a config file that is just executable bash.