#plugin-api #plugin #write #statistics #collection #instance #collectd

sys collectd-plugin

Provides ergonomic API ontop of collectd's C interface and macro for defining plugins easier

26 releases

0.14.0 Jun 15, 2021
0.13.0 May 10, 2020
0.12.0 Apr 25, 2020
0.11.0 Oct 30, 2019
0.2.0 Nov 30, 2017

#213 in Operating systems

Download history 29/week @ 2024-03-09 28/week @ 2024-03-16 7/week @ 2024-03-23 48/week @ 2024-03-30 45/week @ 2024-04-06 22/week @ 2024-04-13 33/week @ 2024-04-20 19/week @ 2024-04-27 5/week @ 2024-05-04 7/week @ 2024-05-11 16/week @ 2024-05-18 9/week @ 2024-05-25 21/week @ 2024-06-01 56/week @ 2024-06-08 98/week @ 2024-06-15 44/week @ 2024-06-22

220 downloads per month

MIT license


ci Rust Version

Write a Collectd Plugin in Rust

Collectd is a ubiquitous system statistics collection daemon. collectd_plugin leverages collectd's ability to dynamically load plugins and creates an ergonomic, yet extremely low cost abstraction API to interface with collectd.


  • No unnecessary allocations when submitting / receiving values, logging
  • Register multiple plugin instances
  • Automatic deserialization of plugin configs via Serde (can opt-out)
  • Deployment: compile against collectd version and scp to server
  • Referenced Rust libraries are statically linked
  • Help writing thread safe plugins thanks to the Rust compiler


Add to your Cargo.toml:

collectd-plugin = "0.14.0"

Serde support is enabled by default for configuration parsing.

Works with any collectd version 5.4+, but all users will need to specify the collectd api version they want to target via the COLLECTD_VERSION environment variable (or rely on $(collectd -h) or COLLECTD_PATH variable).

5.4 [5.4, 5.5)
5.5 [5.5, 5.7)
5.7 [5.7,)


See what to add to your project's Cargo file

Below is a complete plugin that dummy reports load values to collectd, as it registers a READ hook. For an implementation that reimplements collectd's own load plugin, see examples/load

use collectd_plugin::{
    collectd_plugin, ConfigItem, Plugin, PluginCapabilities, PluginManager, PluginRegistration,
    Value, ValueListBuilder,
use std::error;

struct MyPlugin;

// A manager decides the name of the family of plugins and also registers one or more plugins based
// on collectd's configuration files
impl PluginManager for MyPlugin {
    // A plugin needs a unique name to be referenced by collectd
    fn name() -> &'static str {

    // Our plugin might have configuration section in collectd.conf, which will be passed here if
    // present. Our contrived plugin doesn't care about configuration so it returns only a single
    // plugin (itself).
    fn plugins(
        _config: Option<&[ConfigItem<'_>]>,
    ) -> Result<PluginRegistration, Box<dyn error::Error>> {

impl Plugin for MyPlugin {
    // We define that our plugin will only be reporting / submitting values to writers
    fn capabilities(&self) -> PluginCapabilities {

    fn read_values(&self) -> Result<(), Box<dyn error::Error>> {
        // Create a list of values to submit to collectd. We'll be sending in a vector representing the
        // "load" type. Short-term load is first (15.0) followed by mid-term and long-term. The number
        // of values that you submit at a time depends on types.db in collectd configurations
        let values = vec![Value::Gauge(15.0), Value::Gauge(10.0), Value::Gauge(12.0)];

        // Submit our values to collectd. A plugin can submit any number of times.
        ValueListBuilder::new(Self::name(), "load")


// We pass in our plugin manager type


There are five main ways to extend collectd:

And my thoughts:

  • I'm not confident enough to write C without leaks and there isn't a great package manager for C.
  • Python and Java aren't self contained, aren't necessarily deployed on the server, are more heavy weight, and I suspect that maintenance plays second fiddle to the C api.
  • The exec plugin is costly as it creates a new process for every collection
  • Depending on the circumstances, writing to a unix socket could be good fit, but I enjoy the ease of deployment, and the collectd integration -- there's no need to re-invent logging scheme, configuration, and system init files.

Rust's combination of ecosystem, package manager, C ffi, single file dynamic library, and optimized code made it seem like a natural choice.

To Build

To ensure a successful build, adapt the below to your project's Cargo file.

crate-type = ["cdylib"]
name = "<your plugin name>"

bindgen = ["collectd-plugin/bindgen"]
default = []
  • A collectd version is required to build. There are several ways one can specify it:
    • Via environment variable: COLLECTD_VERSION = 5.4, 5.5, or 5.7.
    • Via environment variable: COLLECTD_PATH points to the root git directory for collectd. This option makes the most sense when coupled with the bindgen feature.
    • Auto detection by executing collectd -h.
  • The bindgen feature is optional (it will re-compute the Rust bindings from C code, which shouldn't be necessary). Make sure you have an appropriate version of clang installed and collectd-dev (if not using COLLECTD_PATH)
  • collectd expects plugins to not be prefixed with lib, so cp target/debug/libmyplugin.so /usr/lib/collectd/myplugin.so
  • Add LoadPlugin myplugin to collectd.conf

Plugin Configuration

The load plugin in examples/load demonstrates how to expose configuration values to collectd.

# In this example configuration we provide short and long term load and leave
# Mid to the default value. Yes, this is very much contrived
<Plugin loadrust>
    ReportRelative true

Benchmarking Overhead

To measure the overhead of adapting collectd's datatypes when writing and reporting values:

cargo bench --features stub

If you'd like to use the timings on my machine:

  • 60ns to create and submit a ValueListBuilder
  • 130ns to create a ValueList for plugins that write values

Unless you are reporting or writing millions of metrics every interval (in which case you'll most likely hit an earlier bottleneck), you'll be fine.


Do you use collectd-rust-plugin? Feel free to add your plugin to the list.

  • pg-collectd: An alternative and opinionated postgres collectd writer


~107K SLoC