Anuket Project

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Current »

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. Thus there is no central instance which queries any values.
    • 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 (I’m sure Fedora as well, but I haven’t looked this up)...

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…  
      • 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.

 

 

Other OpenSource Monitoring projects:

  • No labels