Automation of Cacti console tasks
From our point of view, at least bigger installations cannot be maintained without automatic synchronization with some asset management (store of the list of hosts).
Goal is to automate Cacti management tasks to the ultimate minimum to allow for automatic device creation.
For new or existing hosts, automate graph creation, e.g. if new „interfaces“ appear is required as well. It should be possible to select the graphs „you are interested in“ by defining properties (e.g. special ifDescription, ifType and the like).
Change graphs (e.g. titles) at least once a day if e.g. ifDescription changed.
Plugin Development
Changes like cacti087+PIA1.3 are surprising for plugin developers. Roadmap is missing or other means of communicating changes or directions of development. As long as PIA is provided as a patch, we may require a beta testing period both for cacti and for cacti+PIA.
Raise attention by plugin developers in earlier development stages to gain momentum e.g. for regression testing and focus them on verifying at least their own plugins with a new version.
It would be very helpful to tell plugin developers which interfaces have changed (both PIA and cacti).
SW Architecture
We discussed Template Structure and interaction of Templates (explanation and walkthrough of topics covered at docs.cacti.net).
Poller processing and interaction of poller.php with cmd.php/cactid was discussed in more detail. This was an introduction into the more detailed discussion about a "scalable, reliable and distributed Cacti" (see bottom).
Roadmap
We discussed changes introduced with Cacti 087a, detailed plans for 088 (as of docs.cacti.net) and plans for 089 and 090.
We talked about the requirement to map planned features to required features (e.g. from Feature Request Forum)
Plugins
Walkthrough the REPORTIT Plugin. Explained 3 different roles provided
- Report Template Designer
- Report Designer
- Report User
We identified 4 different functional parts of Cacti SW Architecture, with respect to optimal association between functional parts and hw to place these parts on.
- DB(MySQL) engine holding the „tasks“ for the poller, the „output“ from the poller and the structure for presentation
- Polling engine in terms of cactid/spine responsible for fetching his „tasks“ from DB engine.
We discussed the use of some „caching“ feature if running over non-reliable links; writing polling results to DB Engine, perhaps again introducing kind of a „write cache“ if running over non-reliable links.
Approach: do not ultimately require a complete DB system on the poller engine to be able to use small footprint hw (e.g. non-moving parts, no disks, RAM only). Allow for remotely accessing the DB engine directly using a DB (MySQL) client - RRD file engine fetching performance data from the DB engine to update rrd files and to store those files. Again, the recommendation for „structured RRA folder“ was discussed. This way, it would be possible to divide the whole mess of rrd files on different disks without recommending huge SAN systems. And directory search should be more efficient. Think about heirarchy levels (e.g. first level related to poller engine, second level to host, third level to data/graph template or stuff) to achieve better „understanding“ were files are placed.
- Presentation engine (web server) accessing both the DB engine to get the structure and the RRD file engine to access specific files. Perhaps, high performnace to rrd files is not ultimately required because only few rrd's will be used when displaying data
Reinhard