Allow incoming data to use graphite’s whisper database as an optional backend. This would augment the existing RRD backend, instead of replacing it.
LibreNMS is already fetching the snmp data in a semi-structured fashion. We can then supply it to multiple backends with minimal cost. Using a secondary data store would allow additional tools to integrate data from a fetch that was “already paid for” the first time LibreNMS went to poll the device.
Graphite’s whisper database is an established and matured solution. Supporting it should not require significant coding.
The LibreNMS administrator would define a single global entry that specifies a host, port, and enable/disable switch, similar to other global settings. The admin would enter the information for the graphite host and then “enable” the feature.
When enabled, the system will send the polled data to a whisper database at the specified address and port number. When disabled, no activity occurs. As such, processing time is only taken for when the feature is active.
The encoded data points would be identified as hostname.OID or something similar, which in turn should provide unique keys for retrieval. Example key format: com.mydomain.myhost.18.104.22.168.4.1.26322.214.171.124.3.1 would be a single datapoint.
- existing RRD structure, benefits, graphs, etc. continue to be used without changes.
- minimal to moderate coding complexity, should not require extensive changes.
- data is backed up in a separate format.
- database be queried using this format.
- data integration is provided to 3rd party packages, which does not require additional coding for LibreNMS to support.
- sets the groundwork to allow graphite graphs to be used either/or with RRD graphs; a switch in the system would offload graph generation to the graphite server, sending graph data back instead of RRD data; this would be a “preference” and not a requirement.
Concerns or potential issues:
- is it possible for the whisper backend to block-on-transmit, causing LibreNMS to back up under heavy load?