collectd

Last reviewed Sep 13, 2026 · 844 words

collectd is 21 years old, written in C, idles in single-digit megabytes of RAM, and is still the metrics daemon on every OpenWrt router with the statistics package installed. That is its niche in 2026: hardware where node_exporter or Telegraf are too heavy, too hard to build, or not packaged at all. On an ordinary Linux server I would not install it; node-exporter is 20 MB and speaks Prometheus natively. On a router, a NAS with a locked-down package repo, or a fleet of ARM boards with 64 MB of RAM, collectd is often the only serious option, and it is a good one.

Read plugins in, write plugins out, nothing in between

The architecture is the whole design. Every 10 seconds (the default Interval), each loaded read plugin collects its values: cpu, memory, load, df, disk, interface, sensors, ping, snmp, and about 100 more, down to exec for a shell script and curl_json for scraping an HTTP endpoint. Each loaded write plugin then receives every value and does one thing with it. There is no query language, no storage of its own, and no dashboard, which is why the catalogue flags "no native dashboard" as a con and why I consider it a feature: collectd does one job and hands off.

Interval 10

LoadPlugin cpu
LoadPlugin memory
LoadPlugin load
LoadPlugin df
LoadPlugin interface
LoadPlugin write_prometheus

<Plugin df>
  MountPoint "/"
  MountPoint "/srv"
</Plugin>

<Plugin interface>
  Interface "lo"
  IgnoreSelected true
</Plugin>

<Plugin write_prometheus>
  Port "9103"
</Plugin>

That file is a complete, useful configuration for a small box. The Apache-style syntax is the "low-level" part: there are no defaults you can inspect from a UI, plugin options are documented in collectd.conf(5) and nowhere friendlier, and a typo loads nothing and logs one line. Run collectd -t to test a config before restarting.

Three ways to get the data out

The write_prometheus plugin above exposes everything on port 9103 in exposition format, and Prometheus scrapes it like any other exporter. Metric names come out as collectd_cpu_total and the like, which is uglier than node_exporter's but perfectly graphable in Grafana. This is the path I would take for anything built today.

The write_graphite plugin sends to Graphite over its plaintext protocol, which is how most collectd installs older than a decade still work. And the network plugin sends binary datagrams to another collectd, which lets 30 routers forward to one central collectd that does the writing; that central one can run write_prometheus or rrdtool and nobody else needs a write plugin at all. The rrdtool plugin, writing local round-robin files, is the original design and still what OpenWrt's statistics page reads. Any of these can run at once, since every write plugin sees every value.

OpenWrt is where most collectd instances actually live

Install luci-app-statistics on OpenWrt and you have installed collectd; the graphs on the router's Statistics tab are RRD files it wrote. The collectd-mod-* packages add plugins individually, so a router with 8 MB of flash loads five of them and nothing else. Add collectd-mod-network and point it at a central collector, or collectd-mod-write-prometheus where the package exists for your release, and your router's interface counters, wireless signal levels, and ping times land in the same Grafana as the rest of the house. That is the use case where nothing else in the monitoring category competes; node_exporter does not ship in the OpenWrt repos for most targets and Telegraf's Go binary is far too big for the flash.

Where Telegraf and Netdata are the better daemon

Telegraf is the modern generalisation of the same idea: input plugins, output plugins, one config. It is a Go binary of tens of megabytes with a much larger plugin set, first-class InfluxDB and Prometheus output, and TOML that is easier to read than collectd's config. On any machine that can afford it, it is the friendlier tool with the more active project. Netdata answers a different question: it collects at 1-second resolution and ships its own dashboard, at the cost of far more RAM than 32 MB. If you want to look at a single host's metrics right now, Netdata; if you want a central Prometheus fed by many hosts, node_exporter; if the host is a router or an embedded board, collectd.

What I'd do

collectd on every OpenWrt device and any board that cannot run a Go binary comfortably, with write_prometheus where the package exists and network forwarding to one central collectd where it does not. node_exporter on every real server. One Prometheus scraping both, one Grafana on top. Do not try to make collectd your only agent in 2026; its project is quiet, the config is unforgiving, and the plugins for modern services are thin. As a small, stable daemon for hardware that will never see a container, it has outlasted three generations of replacements, and I expect it to outlast the next one.