Hi everyone,

I am glad that version 1.2 is on his way to be completed but I was curious if there is any future plan to develop agents to extend CACTI.

Cacti Primarily uses SNMP, which is available under Windows and Linux. On Linux, the Net-SNMP packages are also extensible. Plus there are a tonne of scripts to gather more data and even a WMI plugin (though i've never tried it myself).

What would you envision the agent for?

Agents for passive monitoring on the CACTI servers and active monitoring for the remote devices.

I think NAGIOS and Zabbix and others has a similar approach and it could help on server monitoring, practically you would run the agent on the server/device and collect data locally, package it and send it back to the poller for processing, TCP for critical devices and UDP maybe optional.

CACTI pollers would run a process (or a number of them) to collect inbound data packaged (and possibly encrypted...) matching the related data source, imagine like a tag set in the payload with dynamic data structure where you have the ID of the device or directly the data source to populate and the actual value, it may contain also the time window slot record so in case of loss of communication the agent may store it locally and send it once restored all together (kinda how it works with remote pollers).

agents and pollers should authenticate themselves via a key or a PAC file (manually or automatically generated)

Another interesting topic would be to see an implementation using REST APIs but this is I guess dependent on the devices to monitor and it could be even easier to implement as a server side PHP script calling up for Objects even if I am not sure how it would be handled on the error/values side.

There are a few things I was thinking about, they are, in no particular order:

1) Bringing back cigamit's wmi plugin that would allow WMI queries to be periodically run from the Cacti server and stored locally for graphing. Entries would be chached into MariaDB/MySQL tables and then the poller would capture data from the tables. This would essentially result in a scalable wmi implementation.

2) Writing a carbon2cacti plugin that would enable the creation of from one to many ingestion services on the Cacti server that would siphon data from either a carbon server or an AMQP service. Then, you would only have to deploy collectd on windows to get all the standard metrics. This plugin seems somewhat trivial in it's simplest form in that the carbon protocol is a wire protocol that is simple to dissect. However, collectd also supports AMQP and encryption which would add a few layers of complexity.