This section describes the known issues in the Monitoring Console and in the Monitoring Framework. The Monitoring Framework is a shared component that is automatically installed with other components to enable monitoring.
The following patches are required to prevent certain known issues in the Monitoring Framework. These patches are normally included in other patch bundles required for Java ES or in updated versions of the Solaris operating environment. However, you should verify the existence of these patches or their replacements on any host where you will monitor a Java ES product component:
Table 1 Patches for Monitoring in the Solaris Operating Environment
Solaris Version |
Patch Number |
---|---|
Solaris 9 Sparc Platform (up to and including version s9u7_06) |
114344-17 |
Solaris 9 i386 Platform (up to and including version s9u7_06) |
114345-08 (obsoleted by: 117172-17), 118559-28 (or later) |
Solaris 10 Sparc Platform (up to and including version s10_58) |
114344-17 |
Solaris 10 i386 Platform (up to and including version s10_58) |
114345-08 (obsoleted by: 117172-17), 118855-15 (or later) |
For the HP-UX operating system, the patches required for monitoring are included among those described in HP-UX Requirements and Issues.
When adding a new host to be monitored, the Monitoring Console uses SSL to secure the connection, but does not show the certificate presented by the selected host. Because the Monitoring Console transmits the host's root password to the node agent, there is a vulnerability to an attacker forging the IP address of the intended host and receiving the password. The risk of this happening is very low because most node agents run on hosts already within a secure network.
Solution If your node agent hosts are not within a secure network, you should verify their authenticity before adding them as new hosts in the Monitoring Console. To verify the authenticity of a host, log in to the host and make sure you recognize its configuration and its file system. For a UNIX host, you can log in with ssh to view the certificate information.
Objects contained in a product are referred to in Monitoring Console as an “application server.” This terminology should not be confused with Sun Java System Application Server.
Solution In the context of the Monitoring Console, an application server refers to the running instance of an installed Java ES component.
Displaying and switching pages in the Monitoring Console can take up to 30 seconds in some cases.
Solution Run the Monitoring Console on a powerful host with no other applications.
Labels in the left-hand tree do not include host or domain names, only component names. This can make it difficult to identify similar components on different hosts. Similarly, when creating a monitoring rule and selecting the monitored component, instances of the same component on different hosts may be indistinguishable.
Solution Look for host identifiers in the detailed views of the monitored component. Some components include their process ID in their instance name, so you need to know the process ID of the instance on each host.
The Monitoring Console cannot enable or disable monitoring on a per-component basis.
Solution You must enable and disable the monitoring of a component through each component's own mechanism. For instructions, see the component–specific sections in Chapter 2, Enabling and Configuring the Monitoring Framework, in Sun Java Enterprise System 5 Monitoring Guide.
When a monitored component crashes or is stopped normally, its monitored objects may not be removed from the node agent and remain visible in the left-hand tree of the Monitoring Console. Similarly, if you stop an entire node agent, the host node may not be removed from the left-hand tree. This issue occurs intermittently.
Solution When you stop or restart a server instance, you may need to restart the node agent, the master agent and the Monitoring Console. If you stop a host and its node agent, you may need to restart the master agent and the Monitoring Console. The procedure To Restart a Node Agent in Sun Java Enterprise System 5 Monitoring Guide describes how to do both.
When a host is removed from the Monitoring Console, the monitoring rules and alarms associated with its monitored components are not deleted automatically. This allows persistency of the rules and alarm states if you add the same host again.
Solution If you do not plan on adding that host again, use the Rule dialog to find and delete all rules associated with the host. Alarms that exist when the host is removed may be acknowledged but will remain in the Monitoring Console because the monitored attribute that triggered the alarm can no longer be accessed. To avoid leaving alarms in the acknowledged state, resolve all alarm conditions in a monitored component and acknowledge the alarms in the Monitoring Console before removing the host.
The following list tracks other known issues with the Monitoring Console.
Various tables are not sorted by default
Host linked from “Objects Using This Installed Product” should not be unknown object
Using the AppServer plug-in, the “objects contained by this server” should not include children of children
Enable and disable functionality is not working correctly in the table of hosts
Caption and description fields displayed for Statistics and Settings objects but not for base objects
Selecting an object and clicking on Monitoring Rule->New should not require the user to select the object again
The names of JVM objects listed for a given host are inconsistent
CMM_Cluster objects created by Application Server are not displayed anywhere
List of observable objects in the New Rule dialog is not clear
Object and Operational Status of Portal, Web, and Application Server objects display as unknown
Enterprise Java Beans deployed in Application Server should have more descriptive names
The names of attributes in Application Server monitoring objects are impossible to use
Internal Application Server configuration changes not reflected in the Monitoring Console
On a Linux system, the Monitoring Framework will not work when IPv6 is enabled. As a result, the instrumentation of your monitored components on this system will not be loaded into the cacao container, and you will not see them in the Monitoring Console.
Solution There are two possible solutions:
Configure the Monitoring Framework to not use the loopback interface:
In the Monitoring Framework configuration directory (default /etc/opt/sun/mfwk/config), make a copy of the sample properties file:
cp mfwk.properties.sample mfwk.properties |
Set the following parameter in the newly copied mfwk.properties file:
mfwk.multicast.disableloopback=true |
Restart the node agent, the master agent, and the Monitoring Console with the procedure To Restart a Node Agent in Sun Java Enterprise System 5 Monitoring Guide.
Or disable IPv6 on Red Hat 3.0 with the following steps:
Find this line if it appears in the /etc/modprobe.conf file:
alias net-pf-10 ipv6 |
Change it or add the following line:
alias net-pf-10 off |
Reboot the system. IPv6 should now be disabled.
On Red Hat 4.0, follow the same procedure using the /etc/modules.conf file.
In the process of disabling a monitored component, it should be undeployed from its node agent, but this sometimes freezes. Specifically, the cacaoadm undeploy command never returns and monitoring is blocked in the entire node agent.
Solution Kill the process and restart the node agent, the master agent, and the Monitoring Console with the procedure To Restart a Node Agent in Sun Java Enterprise System 5 Monitoring Guide.
Components that rely on C libraries to interface with the Monitoring Framework may display more slowly in the Monitoring Console when they run in the Linux operating environment.
Solution None.
Components that rely on C libraries may exhibit slower monitoring performance in the Monitoring Console after other components in the same node agent are redeployed or terminated.
Solution Restart the node's Common Agent Container including the node agent, then restart the master agent and the Monitoring Console with the procedure To Restart a Node Agent in Sun Java Enterprise System 5 Monitoring Guide.
Inter-process communication between components that rely on C libraries and the node agent on the same host is not secure. By default, communication uses the loopback interface, thereby reducing the security risk.
Solution None.
Components that rely on Java libraries to interface with the Monitoring Framework may experience performance issues when accessed through SNMP.
Solution None.
Due to a bug in Solaris 9, packets addressed to an IPv4 address are not delivered to listener on an IPv6 socket. This interrupts the discovery mechanism between node agents and the components to be monitored on that host.
Solution Force the node agent's JVM to listen on IPv4 sockets with the following commands:
cacaoadm stop oldvalue=`cacaoadm get-param java-flags --value` cacaoadm set-param java-flags="${oldvalue} -Djava.net.preferIPv4Stack=true" |
Then restart the node agent, the master agent, and the Monitoring Console with the procedure To Restart a Node Agent in Sun Java Enterprise System 5 Monitoring Guide.
If the time on the node agent and master agent hosts is too far out of sync, adding that node in the Monitoring Console will fail. The error log of the master agent's Monitoring Framework will report a severe error “during JRMP connection establishment.”
Solution Set the time on either host so they are synchronous.
Documentation for a private C API was inadvertently included in the run-time packages. The interfaces it describes are private and subject to change at any time, therefore their use is discouraged.
Solution None.
When many monitoring rules are created in parallel in a node agent on the HP-UX operating system, thread numbers in the Java Virtual Machine (JVM) may exceed kernel parameter limits and cause an OutOfMemory exception.
Solution Download and run the HPjconfig tool, as described in the procedure To Optimize Kernel Parameters for Monitoring Framework on HP-UX in Sun Java Enterprise System 5 Monitoring Guide.