Features

Modularity
Everything in collectd is done in plugins. Well, except parsing the configfile. This means that the main daemon doesn't have any external dependencies and should run on nearly anything that has heard of POSIX. The daemon has been reported as working on Linux, Solaris, Mac OS X, FreeBSD, NetBSD, and OpenBSD. It's likely that other UNIX^® flavors work to some extend, too.
The daemon does not build on Microsoft^® Windows^® without major modifications. Client-only Windows^® support is available in form of SSC Serv, a native Windows^® service that implements collectd's network protocol.

Reasonable defaults
collectd's configuration is kept as easy as possible: Besides which modules to load you don't need to configure anything else, but you can customize the daemon to your liking if you want.

High-resolution statistics
In contrast to most similar software, collectd is not a script but written in plain C for performance and portability. As a daemon it stays in memory, so there is no need to start up a heavy interpreter every time new values should be logged. This allows collectd to have a 10 second default resolution while being nice to the system. It runs on OpenWrt without much impact on the CPU.. The result are very high resolution graphics. The sample graph gives you an idea of the detail you can expect. Please note that this is a ten-minute sample!

Sophisticated network code
collectd utilizes a data push model, i. e. the data is collected and sent (pushed) to a multicast group or server. Thus there is no central instance which queries any values.
The network code utilizes the advanced network technologies IPv6 and Multicast. But of course you can use collectd without any of this knickknack (i. e. IPv4 unicast ;), too. Since you can configure data transmission and reception separately, you can realize the following setups easily (see the networking howto for more details):

• No networking: If you don't load the network-plugin, networking is completely disabled. No sockets, no overhead, no problem.
• Multicast: Data can be sent to or received from a multicast group. This is the easiest and most interesting solution if you have many "clients" and one or a few "servers" on a local network. Using multicast is trivial: Simply enter a multicast address and any "server" will automatically recognize it and join the specific group.
• Unicast: Of course you can simply send data to specific hosts only. This is mostly interesting for scattered hosts - network wise.
• Proxy operation: An instance can be configured to forward the data it received over the network. Using this you can forward the data received from a multicast group to a unicast address, couple two distinct multicast groups without the need for (extra-AS) multicast routing and so on. Of course, IPv4/IPv6 can be wildly mixed with this, too.

The network protocol has been designed to be lightweight, so data collection over slow network links isn't a problem. The protocol is extensible, so it's open for new features in the future without breaking backwards compatibility.

Using multicast can be thought of as "auto discovery": The server doesn't (need to) know what clients exists (it never does) and the clients don't need to know the server's IP-address. In fact, they don't even know how many servers there are. You can think of it like radio communication: Once set to the right channel you can receive all the data transmitted by some senders - no matter what their position is.

Custom extensions
There is a variety of means by which you can extend the functionality of collectd to your needs:

• C-plugins: These plugins are compiled to shared objects and can be loaded by the daemon directly. These plugins possibly have the longest development cycle, but it is the best performing and most elegant solution, too.
• Perl-plugins: The perl-plugin includes a Perl-interpreter into the daemon which provides the C-interface to Perl-modules. Please note that his plugin is considered experimental and might change with the next minor version.
• UNIX domain socket: The unixsock-plugin opens a UNIX socket to which you can connect and submit your values or query collected values.
• Execute binaries or scripts: Arguably the easiest and least performant solution. The exec-plugin forks a binary or script which acquires the values somehow and writes them to standard output.

Build to scale
collectd is able to handle any number of hosts, from one to several hundred (or possibly thousand, but no one has reported that yet). This is achieved by utilizing the resources as efficient as possible, e. g. by merging multiple RRD-updates into one update operation, merging the biggest possible number of values into each one network packet and so on. The multithreaded layout allows for multiple plugins to be queried simultaneously - without running into problems due to IO-latencies.

SNMP-support
SNMP is in widespread use with various network equipment, for example switches, routers, rack monitoring systems, thermometers, UPSes, and so on. The snmp-plugin provides a generic interface to the SNM-protocol which you can use to query values and dispatch them over collectd's mechanisms, e. g. transmit them to a server instance somewhere else. Since devices one would query using SNMP usually are embedded devices with not very much computing power, you can set the interval in which data is gathered for each host individually. And since it may take a while for a timeout to occur or the device may take a little while to answer a request, the hosts are queried in parallel using multiple threads.

Integration with existing monitoring solutions.
Since collectd doesn't interpret and act upon the values it receives, it's not a monitoring solution by our standards. You can, however, use the values collected by collectd in Nagios by using the collectd-nagios(1) utility included in the package.
We're thinking about including some monitoring features in collectd, but we're not there yet. If you have thoughts on how it should be or are willing to work with us on that, please get in touch with us.