eG Enterprise provides a 100%, web-based RHEV Manager monitoring model, which periodically runs availability and health checks on the RHEV manager and proactively reports abnormalities.
Figure 1 : The layer model of the RHEV Manager
Each layer depicted by above figure is mapped to tests, which employ agent-based or agentless mechanisms (depending upon how you want the RHEV manager to be monitored by the eG Enterprise system) to pull out a variety of metrics from the RHEV manager. The metrics so collected enable administrators to quickly find accurate answers to the following performance queries:
- Is the RHEV manager available over the network? If so, how quickly is it responding to requests?
- Have any error/warning events occurred on the RHEV manager? What are these errors/warnings?
- Has the RHEV manager log captured any new errors/warnings? If so, what are they?
- How many data centers have been configured on the RHEV manager? What are they, and what is the compatibility level of each one of them?
- Is any data center in a problematic state currently?
- Which data center is running short of disk space? How many clusters, RHEV servers, and VMs have been configured in that data center, and which ones are they?
- How many storage domains are operational in each datacenter? Which ones are they?
- Is any storage domain unavailable? If so, which one? Which VMs are using this storage domain?
- Is any storage domain running out of space? Which one is it, and which VMs will be impacted by this space crunch?
- Is any logical network currently down? Which clusters and RHEV servers are using this logical network?
- Which logical network is experiencing heavy network traffic?
- Have any errors occurred on a logical network? If so, which one is it, and when did these errors occur - while transmitting data or while receiving it?
- Is any cluster using CPU resources excessively? If so, which cluster is it? Are any CPU-hungry VMs operating within that cluster? What are they?
- Are all clusters rightly sized in terms of memory, or are there any clusters that are currently experiencing a memory contention? If so, which cluster is it, and what is causing the memory crunch on that cluster - is it owing to improperly sized hosts or memory-starved VMs?
- Which cluster has too many hosts and VMs that are powered off?
- What is the compatibility level of each cluster?