collectd: the C daemon that still collects system metrics

What collectd solves, and who it is for

collectd is a daemon, not a platform. It runs on a host, wakes up on a configured interval, asks a set of plugins for numbers, and hands those numbers to write plugins that store or forward them. The README describes it as "a small daemon which collects system information periodically and provides mechanisms to store and monitor the values in a variety of ways." That sentence is the whole design in one line.

The audience is infrastructure engineers who run their own machines and want per-host metrics without deploying a full observability stack on every node. The plugin list is the reason people stay: cpu, df, disk, interface, memory, load and uptime cover the basics, but the long tail is unusual. ipmi reads hardware sensor data. apcups covers APC UPS charge and battery voltage. drbd reports per-resource replication statistics. intel_rdt exposes last-level cache occupancy and memory bandwidth from Intel RDT. dcpmm reads Intel Optane DC persistent memory health. If you administer racks rather than containers, that list is the argument for collectd over a generic agent.

The trade-off is equally clear. collectd assumes you can build or install a daemon, edit a config file, and restart it. It is not a library you import, and it is not a hosted service. Teams that want a single YAML file and an HTTP scrape endpoint will find the configuration model heavier than they expect.

How the read, filter and write chain works

The architecture is a pipeline with three stages. Read plugins produce values. Filter chains can drop, transform or route them. Write plugins consume them. Each value carries a hostname, a plugin name, a plugin instance, a type, a type instance and a timestamp, which is why collectd data is self-describing when it lands in Graphite or InfluxDB.

Read plugins fall into two families. Local plugins read the kernel or a device directly: cpu from system counters, df from mounted filesystems, interface from network counters. Network-facing plugins talk to something else: the curl, curl_json and curl_xml plugins retrieve data over HTTP and parse the response according to user configuration, which is how people scrape an HTTP API that has no exporter. The dbi plugin executes SQL statements on various databases and interprets the returned data. The exec plugin gathers values produced by a custom program or script.

Write plugins are where the fan-out happens. The README and repository topics name graphite, influxdb, kafka, mqtt, amqp, riemann, redis, rrdtool, snmp and stackdriver among the destinations. The network plugin sends values to another collectd instance. In practice this means one agent can feed several backends at once, which is the main reason people keep collectd in front of a newer time-series database instead of replacing it.

The filter chain sits between the two and is the part most users never touch. It exists so you can rewrite a metric name or drop a noisy series without editing the plugin that produced it.

Building collectd from source and starting it for the first time

The README does not give a package-manager one-liner. It documents the source route, and the repository layout matches that: configure.ac, Makefile.am, a build.sh script and a version-gen.sh script sit at the top level, with gnulib and m4 alongside them. The README has its own sections on generating the configure script, building on Windows and crosscompiling, which tells you the maintainers expect non-Linux builds to be possible but not the common case.

The README documents the build script as the entry point, and the repository ships the autotools files the configure step needs.

./build.sh

After that, the daemon reads its configuration file and starts collecting. The README's feature list names the cpu, df, disk and interface plugins as read sources and rrdtool as a storage destination, so a first configuration exercises one of each. The exact option names for a given plugin live on that plugin's man page, which the README points to for exec, email and several others.

./configure
make
make install

When a plugin fails to load, the daemon reports it at startup rather than silently dropping the metric. The README does not document rollback behaviour for a failed write, so treat backend reachability as something you monitor separately.

Where collectd stops being the right tool

The first limitation is the release situation. The most recent published releases are collectd-6.0.0.rc1, rc2 and rc3, dated 2024-01-29, 2024-02-07 and 2024-02-21. Those are release candidates, not a final 6.0.0. Distribution packages, meanwhile, are typically built from the 5.x line. If you write configuration against a 6.0 feature you read about, check which version you actually have before you commit to it.

The second is the pull model. collectd is push-oriented. It collects on an interval and sends values out. Prometheus and its ecosystem are pull-oriented: the server scrapes an HTTP endpoint. You can bridge the two, and the repository topics list a prometheus-exporter, but the bridge is an extra component in the path rather than something the daemon does natively. Teams standardized on scraping will find that collectd adds a hop.

The third is configuration ergonomics. collectd.conf is a custom syntax with nested plugin blocks, not YAML. Every plugin has its own options, and the README's feature list is a catalogue rather than a reference: to configure ipmi or intel_rdt you need the plugin's own man page. There is no schema validation step that will tell you a key is misspelled before the daemon starts and silently skips the plugin.

Finally, collectd is a host agent. It has no native concept of Kubernetes pods, service discovery or label-based relabelling. For container-native environments, a per-node daemonset running collectd works, but you are responsible for mapping metrics to the objects you care about.

collectd vs Telegraf, node_exporter and StatsD

The comparison people actually search for is collectd vs Prometheus, and the honest answer is that they are not the same kind of thing. Prometheus is a time-series database and query engine with a pull-based collection model. collectd is an agent. You can run collectd and have it feed Prometheus through an exporter, which is a common migration pattern: keep the plugins you depend on, change the destination.

Against Telegraf, the difference is language and plugin philosophy. Telegraf is Go, ships as a single static binary, and its plugin set grows quickly. collectd is C, predates most of the current ecosystem, and its plugin set is deep in hardware and system areas rather than cloud services. If your metric source is an IPMI sensor, a DRBD resource or an Intel RDT counter, collectd likely has a plugin and Telegraf may not. If your metric source is a SaaS API, the reverse is usually true.

Against node_exporter, the split is architectural. node_exporter exposes an HTTP endpoint that Prometheus scrapes; it does one job and does it in the pull model. collectd pushes to whichever backend you configure and can fan out to several at once. node_exporter has no equivalent of the filter chain or the write plugin fan-out, and collectd has no equivalent of a single scrape endpoint that a Prometheus server can hit without a bridge.

StatsD is a different shape again: it is a UDP listener for application-emitted counters and timers, not a system poller. People run collectd and StatsD side by side, not instead of each other.

Maintenance, upgrade cost and licensing

The repository is not archived, and the last push was on 2026-05-29. That is recent activity on the main branch. It does not change the release picture: the newest tagged releases remain the three 6.0.0 release candidates from early 2024, so anyone planning an upgrade path should look at the branch rather than assume a final 6.0.0 tarball exists.

The upgrade cost has two parts. The first is the daemon itself, which means rebuilding from source or moving to a newer distribution package. The second is the configuration, and that is where time goes. collectd.conf is not versioned with a migration tool, and plugin options change between major versions. A 5.x configuration moved to a 6.0 release candidate may need edits, and the README does not document a rollback procedure, so keeping the previous config and binary available is a practical precaution rather than a documented feature.

On licensing: the repository metadata reports the licence as NOASSERTION, which means the automated detector could not classify it. The repository contains a COPYING file at the top level, and that file is the authoritative statement of terms. Read it before you redistribute collectd inside a product image or a bundled appliance. This is a description of where the terms live, not legal advice.

One operational note from the README that is easy to miss: there is a section titled "collectd and chkrootkit". If you run chkrootkit on the same host, that section is worth reading before you conclude the daemon has been tampered with.

Editorial conclusion

collectd fits environments that already run RRDtool or Graphite, need a long-tail plugin such as ipmi, apcups, drbd or intel_rdt, and want one C daemon with a small dependency footprint on each host. It is the wrong tool when you want a pull-based HTTP endpoint as the primary model, when you expect one binary that covers every cloud service, or when you need a stable 6.0 API today: the newest published release is collectd-6.0.0.rc3 from 2024-02-21, so verify on your target platform whether your distribution packages 5.x or a 6.0 release candidate before you design around it.

Frequently asked questions

Official sources

1. collectd/collectd on GitHub
2. Issues
3. Project website
4. README
5. Releases