The Universal eG Agent vs the eG VM Agent
One of the questions on virtualization monitoring that often comes up is, why not use the Universal eG agent instead of the eG VM agent for 'inside view' monitoring? The answer to that is 'Yes'; you can install the Universal eG agent on every Windows VM, instead of the eG VM agent, to pull metrics on the internal health of each VM. However, there are trade-offs between using the eG VM Agent and the eG Universal Agent. While one is cost-effective, the other scores big in terms of its monitoring depth. The two tables below discuss these trade-offs in detail, so you can make a well-informed choice. The first table compares the two agent types broadly, in terms of architecture, deployment, licensing cost, and performance visibility.
|
eG VM Agent |
Universal eG Agent |
|
Deployed on desktops mainly |
Focused on servers |
|
Communicates with the eG remote agent which then communicates with the manager |
Communicates directly with the eG manager |
|
Listens on port 60001 (by default). Can be configured to not listen on a port, but connect to the eG remote agent on a specific port. |
Does not listen on any port |
|
If user is logged in reports by user name. This makes it easier to search for desktops by user name. |
Metrics reported for the server/applications running on it. |
|
VMs are not managed entities in eG Enterprise. Either hypervisors or cloud desktops are the entities. VMs are components of these entities. |
Each system monitored by an eG agent is a managed entity. |
|
VM agents licensed by concurrent desktops/users. If the hypervisor on which the VM is running already has a license, the VM agent requires no additional license. |
Each eG agent will consume an OS/application monitor license depending on what is being monitored by the agent. |
|
Collects a wide variety of metrics on VM performance. Limitations include no monitoring of event logs or application logs, individual processes/services cannot be monitored. Also cannot be used for in-depth application monitoring. |
Collects a wide variety of metrics on server performance. Event logs and application/system logs can be monitored, individual processes/services can be tracked. Can be used for in-depth application monitoring. |
|
Since thousands of VMs may be monitored, thresholds are typically not auto-baselined. Thresholds are set for all the VMs and are not easily configured VM by VM. |
Auto-baselining is fully supported. Thresholds can be set for the system or for individual descriptors (disk drives, processes, etc.) |
|
VMs are not placed in a service topology. Hence, auto correlation across tiers not possible. |
Managed entities can be part of service topologies. Auto correlation across tiers is supported. |
The next table compares the performance insights provided by both the agent types, metric-wise.
|
Performance Metric |
eG VM Agent |
Universal eG Agent |
|
CPU usage |
Yes |
Yes |
|
Top 10 processes by CPU |
Yes |
Yes |
|
GPU usage |
Yes |
Yes |
|
Memory usage |
Yes |
Yes |
|
Top 10 processes by memory |
Yes |
Yes |
|
Disk space usage of all the drives |
Yes |
Yes |
|
Disk activity on each drive |
Yes |
Yes |
|
Top I/O-intensive processes |
Yes |
Yes |
|
Page file usage of the VM |
Yes |
Yes |
|
Network traffic on each VM |
Yes |
Yes |
|
TCP connection traffic to and from the VM |
Yes |
Yes |
|
Handles usage by processes on the VM |
Yes |
Yes |
|
Uptime of the VM |
Yes |
Yes |
|
Monitoring of all automatic services in the VM |
Yes |
Yes |
|
Configure and track specific process patterns |
No |
Yes |
|
Configure and track specific process Windows services |
No |
Yes |
|
Monitoring of server event logs (Application, Security, System) for warnings and errors |
No |
Yes |
|
Monitoring of any other server/application logs on the server |
No |
Yes |
|
In-depth insights into the critical server applications (Oracle database server, Microsoft SQL server, Citrix XenApp server, etc.) deployed on the VMs |
No |
Yes |
