ganglia/ganglia-nagios-bridge

Scalable Ganglia - Nagios integration bridge

ganglia-nagios-bridge's Issues

separate the code for generating a Nagios checkresult file into a dedicated class

This code can be used for other purposes, so it should be in a standalone class in a separate repository

allow more mechanisms to set thresholds

Allow users to provide custom functions or other logic for testing raw values and deciding if a warning or critical alert is required

automatically generate missing service definitions

syslog-nagios-bridge already creates service definitions on the fly

They should be stored to a different configuration directory, possibly under /var, and it should be included into the main Nagios configuration

automatically detect which hosts Nagios knows about

Currently, ganglia-nagios-bridge sends checkresults to Nagios for all hosts it discovers in the gmetad XML

If the Nagios server doesn't have a static configuration for some of those hosts or metrics, it wastes CPU cycles processing that content from the checkresults file and it also logs a lot of spurious warnings about those entries.

It would be useful for ganglia-nagios-bridge to find out which hosts and services Nagios really knows and only write checkresults for those hosts

do not continue to write checkresults files if disk full

Be careful not to keep writing checkresults files to a full disk

support for thresholds based on a combination of metrics

Some thresholds may depend on a combination of raw metric values

For example, a disk used percentage threshold may need to access both the raw metrics for total bytes used and total capacity and divide them to get the percentage.

storing threshold data in MongoDB

Instead of storing the threshold data in a text file, it could be stored in MongoDB and managed through a web interface