Most of the Information on this page was obtained from https://collectd.org/features.shtml
Collectd Advantages:
- Has windows, Linux, Solaris, Mac OS X, AIX, FreeBSD, NetBSD, and OpenBSD
- It’s been around a long time, The first version of the daemon was written in 2005
- The daemon is written for performance and portability. The daemon stays in memory, so there is no need to start up a heavy interpreter every time new values should be logged.
- collectd utilizes a data push model, i.e. the data is collected and sent (pushed) to a multicast group or server. But you can also query deamons using the collectd protocol.
- The network code can use the advanced network technologies IPv6 and Multicast.
- The network plugin offers cryptographic extensions to sign or encrypt network traffic. Servers can be instructed to only accept signed or encrypted traffic, so that information cannot be forged and, in case of encrypted data, read.
- Proxy operation: An instance can be configured to forward the data it received over the network
- There are hooks for perl, python, and other languages. As an added bonus it can push nagios alerts too.
- Built to scale -> collectd is able to handle any number of hosts, from one to several thousand. The multithreaded layout allows for multiple plugins to be queried simultaneously – without running into problems due to IO-latencies. It has integration with time series DBs and RRD to deal with scalability IO issues.
- SNMP support
- Already integrated with Nagios http://e.lefant.net/debienna/collectd_and_nagios/. Also has some integration with Zabbix for VNF monitoring.
- Is available as a package for Ubuntu, CentOs, Fedora.
Note 1: 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.
Note 2: 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.
Collectd Disadvantages:
It does not support:
- Extensible plugins at runtime: you have to restart the daemon to use more plugins… --> something the barometer project is looking into
- IP SLAs Reports: Supporting Cisco's IP Service Level Agreement mechanism.
- Logical Grouping: Supporting arranging the hosts or devices it monitors into user-defined groups.
- Trending: Providing trending of network data over time.
- Trend Prediction: Supporting algorithms designed to predict future network statistics.
- Inventory: Supporting the ability to keep a record of hardware and/or software inventory for the hosts and devices it monitors.
Overall comparison of Network Monitoring systems: https://en.wikipedia.org/wiki/Comparison_of_network_monitoring_systems
Projects using collectd
- oVirt is a management console for virtual guest systems, including statistics. It's developed by RedHat's Emerging Technologies group.
- LuCI, a web-based configuration frontend for embedded devices, can display statistics collected by collectd. There is a screenshot of the statistics in OpenWrt, which uses LuCI as its web-frontend.
- Stackdriver is using collectd 5 as its agent to monitor AWS EC2 nodes.
- RightScale Inc. use collectd on Amazon EC2 nodes.
- noris network AG collects performance data from own and hosted servers as well as a wide variety of network equipment using the SNMP plugin.
- neoTactics use collectd in their cloud management framework CloudScale. They have sponsored the development of a module which allows configuring collectd with Puppet, a configuration management solution.
- Elastic Search
- Rackspace are using it as part of an alternative monitoring solution to Rackspace could monitoring https://community.rackspace.com/products/f/25/t/6800.