Networking setup

If you're collecting performance data for more than just one host, you probably want to have the data in one central place instead of having it spread out over potentially hundreds of servers. That's exactly what the network-plugin is there for. All the configuration options are documented in the collectd.conf(5) manpage.

collectd's network-plugin implements some very sophisticated features. We'll start with some simple examples and work our way up to the technically interesting setups. Since the statistics are collected on one host and stored on another host, the communication is unidirectional, i. e. one-way only. In the following we will call the process which is collecting the statistics (e. g. by reading a file in /proc) and sending them to another host the "client", while the process listening on a socket, receiving and storing the values is called the "server".

Basic unicast setup

The most common and easiest setup is where you have one "server" and a bunch of "clients", which send their data directly to the server.

The server

On the server you need to load the network-plugin, a plugin to store the data somewhere (the most common plugin to do that is the rrdtool-plugin) and a plugin to handle log-messages, i. e. either the logfile- or syslog-plugin:

The network-plugin now needs to be told that it should be receiving data, making this instance a "server". This is done by telling it which IP-address to listen on using the Listen configuration option. We use the IP-address 192.168.0.42 in this example. You need to substitute that with the IP-address of the server. IPv6-addresses can be used here, too.

The clients

On the clients the network-plugin needs to be loaded, too. The output plugin (in our example that's the rrdtool-plugin) does not need to be loaded. But you'll need some plugins that actually collect some data. In this example we'll use the cpu- and memory-plugin as examples for plugins which collect data.

Now you need to tell the network-plugin where it should send the data to. Again, in this example this will be the IPv4-address 192.168.0.42:

Basic multicast setup

Multicast-addresses (both, IPv4 and IPv6) are recognized automatically. On the client there is no difference to sending to a unicast address. The server, however, needs to "subscribe" to the multicast group. This is done automatically when a multicast group is configured. So the following example is all there's to it:

Using a different port

By default UDP port 25826 is used. If that's a problem for some reason, you can configure a different port using the second argument to Listen and Server:

Multiple servers

If you have multiple servers and your clients are sending to a multicast group, all you need to do is install the next server exactly as the ones before. Multicast means the values are sent to all interested parties, so this is exactly what's happening. Sometimes multicast makes your job so easy, it's almost boring.. ;)

If you have multiple unicast servers (or, of course, a mixture of unicast servers and multicast groups) you need to configure all the servers on the clients. Simply use the Server option multiple times:

Multiple interfaces / multicast groups

If you need to listen on more than just one interface, or you want to subscribe to more than one multicast group (or any variation of the two), just use the Listen option multiple times:

Simple proxy setup

If for some reason the server is not directly reachable by the client, you can use a third instance as proxy between the two. This setup requires the option Forward to be set to "true" on the proxy:

Advanced proxy setup

Of course, you can use the above setting to translate between IPv4 and IPv6, or to convert between multicast and unicast communication. Or both at once. It's a proxy alright, I think you get the picture.