From collectd Wiki
Revision as of 22:43, 26 February 2009 by Octo (talk | contribs) (Created initial page.)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search


The Exec plugin executes scripts / applications and reads values back that are printed to STDOUT by that program. This allows to extent the daemon in an easy and flexible way.

The downside is that executing external programs is very inefficient and always a potential security concern. collectd tries to counter these problems with the following options / mechanism:

It is ensured, that only one instance of the program is executed by collectd at any time. Because executed programs can submit as many values as they want, it is common to let the custom program run in a loop, so that they don't have to be started frequently. Especially with scripts this is a big performance gain, because the interpreter doesn't need to be started over and over again and the script is parsed only once. The required memory for the interpreter to stay in memory is the trade-off though.

Scripts that are implemented like that usually have the following form:

while sleep $INTERVAL; do
  echo "PUTVAL leeloo/exec-magic/gauge-magic_level interval=$INTERVAL N:$VALUE"

The security concerns are addressed by forcing the plugin to check that custom programs are never executed with superuser privileges. If the daemon runs as root, you have to configure another user ID with which the new process is created.

Details on the configuration of the Exec plugin can be found in the collectd.conf(5) manpage, information about the syntax the custom extension scripts must write to STDOUT can be found in the collectd-exec(5) manpage.


<Plugin exec>
  Exec "myuser:mygroup" "myprog"
  Exec "otheruser" "/path/to/another/binary" "arg0" "arg1"
  NotificationExec "user" "/usr/lib/collectd/exec/handle_notification"

Example graph


(Data for this graph was collected using the exec-smartctl script which can be found in contrib/.)


  • none