Monitoring Applications Executing on Zones

An eG agent can be installed on a Solaris zone to monitor specific applications executing on it. For instance, say that an Oracle server is executing in a Solaris zone. You can deploy an eG agent on the zone and configure it to monitor the Oracle server. Figure 1 depicts the layer model, tests, and measurements of such an Oracle database server. 

Figure 1 : The layer model, tests, and measurements of the Oracle server executing on a Solaris zone

Note that eG Enterprise does not differentiate between applications executing in virtualized and non-virtualized Solaris environments, while reporting metrics for the application-specific layers. In the case of our example therefore, the top 6 layers of the layer model in Figure 1, will report the same metrics that the eG agent typically extracts from any Oracle server executing on a normal Solaris host.

The difference however lies in the resource-usage statistics reported by the operating system-specific layers – i.e., the bottom 3 layers of Figure 1 in our example. In a virtualized Solaris environment, both the zones and the Solaris kernel at the base share resources from a common resource pool. Therefore, while monitoring the CPU usage of an application that is executing on a Solaris zone, the eG agent reports the percentage of the total CPU resources that the zone has utilized, and also the percentage CPU consumption of each of the processors of the Solaris kernel at the base.  Accordingly, you will find that the System Details test mapped to the Operating System layer reports one set of CPU usage metrics each for every kernel processor (in the format, kernel:<Processor>), and one set of metrics for the zone zone1. This way, whenever there is a spike in resource utilization, administrators can easily figure out what has contributed to the excessive usage – CPU-intensive processes executing on the zone? or one/more runaway processes executing on the Solaris kernel?

Similarly, the Network layer of the application will report network traffic statistics and network interface-related metrics (if available) for the kernel and the zone as well, thereby enabling you to accurately figure out where the traffic is more. Likewise, the TCP layer will report the TCP connections currently established with the kernel and the zone, so as to help you instantly determine the busier of the two entities.

Also, since the Oracle database server in our example is running on a virtual machine that is hosted on a Solaris virtual server, a link for virtual topology appears to the top of the right hand panel in Figure 1. This link is pre-fixed by a state indicator, which indicates whether/not there is a problem with the virtualized environment that this application is part of. In Figure 1, the virtual topology link indicates that the virtualized environment that the Oracle database server belongs to is experiencing no problems.

Note:

• If the current monitor user is not authorized to monitor the Solaris virtual server, but is associated with one/more of the server applications executing on the managed Solaris virtual server, then, while viewing the layer model of any of these server applications, the virtual topology link will not appear in the layer model page depicted by Figure 1.
• The virtual topology link also appears in the user interface that displays the layer model of a managed Solaris virtual server.

Clicking on the virtual topology link reveals Figure 2, which depicts the association between the Solaris virtual server and each of the server applications executing on it. eG Enterprise is able to automatically determine the mapping of applications to the Solaris virtual server.

Whether eG Enterprise automatically determines the mapping of applications to Solaris virtual servers or not is determined by the value of the AutoVirtualMapping variable in the [MISC] section of the eg_external.ini configuration file in the <EG_INSTALL_DIR>\manager\config directory of the eG manager. If the value of this variable is true, the eG manager auto-discovers the applications to Solaris virtual servers mapping.

Note:

• For AutoVirtualMapping to work, the detailed diagnosis frequencies set globally (i.e., using the Configure -> Diagnosis menu sequence) should not be set to 0:0.
• As long as the Identify agents only using nick names flag in the manager settings page of the eG administrative interface (Configure -> Manager Settings menu sequence) is Yes (which is the default), eG Enterprise can automatically identify the server applications executing on an ESX host, using the host/nick names that are mapped to the IP addresses discovered on the host. If the Identify agents only using nick names flag is set to No instead, then make sure that, while managing a server application executing in a virtualized environment, the hostname of the virtual machine is specified as the nick name of the corresponding server application. If more than one server application is executing on the same virtual machine, then any one of those server applications should have the virtual machine name as its nick name.

To disable auto-discovery, set this value to false. In such a case, once a Solaris Virtual server is added, when adding any new server application using the eG administrative interface, you will be prompted to manually set an association between the server application being added and the Solaris virtual server. This mapping (determined automatically or indicated manually) is used by eG Enterprise for correlation – e.g., since the application runs on a Solaris zone, which shares resources with the base operating system, it is most likely that a problem with the Solaris virtual server (at the base) will impact the performance of the application running on one of its zones.

Note:

The topology representation of Figure 2 will differ according to the monitoring rights of the current user. If the user has been assigned only some of the server applications executing on the managed Solaris virtual server, then Figure 2 that appears will depict the association between the Solaris virtual server and the assigned server applications only.

Apparently, besides the Oracle server in our example, a Web server, and a WebLogic server are also executing on virtual machines configured on the same Solaris virtual server.

Figure 2 : The association between the Solaris host and server applications executing on its zones

Whenever the virtualized environment is faced with performance issues, administrators can easily and accurately identify the root-cause of the issue – is it the base Solaris operating system? Or any of the configured Solaris zones? - using the direction of dependency between the various components in the topology representation, and the color coding of the components. Clicking on the problem source so identified, allows the administrator to manually drill down to the layer model of the problem component, revealing exactly what the problem is. 

Besides this manual exercise, the eG Enterprise system also automatically performs the correlation – between applications, zones, and the kernel - in real-time. As and when a new alert is detected, and a problem is narrowed down to one application, the eG Enterprise manager assesses the zone to Solaris virtual server mapping to determine which Solaris virtual server the impacted application is running on. The solution then reviews the real-time state of the other zones running on the same host, and the performance of the base operating system itself (using the dependency graph shown in Figure 2) to determine where the real problem lies.