立即与支持人员聊天
与支持团队交流

Foglight for Java EE Technologies 5.9.7.5 - Installation Guide

Installing and Configuring Foglight for Java EE Technologies Integrating with JBoss Integrating with Tomcat Integrating with WebLogic Domain Startup Scripts Integrating with WebSphere Integrating with Oracle AS Creating a Generic Installation for Manual Java EE Agent Integration Managing Java EE Agent Installations, Integrations, and Configurations Managing Java EE Agent Configurations Managing Java EE Installations Foglight for Java EE Integration Configuration FAQ and Troubleshooting Performing Manual Application Server Integrations Appendix: Managing Permissions for the Java EE Integration Agent Appendix: Foglight for Java EE Application Methods

Uninstalling Java Installations

* 
IMPORTANT: Uninstalling the Java EE Integration Agent removes all files from the installation directory and deletes all of the installed agents. Java agents continue to collect data until you restore any modified startup scripts to the pre-integrated versions and restart the monitored processes.
To uninstall the Java EE Integration Agent:
1
On the navigation panel, under Dashboards, click Application Servers > Administration > Application Servers Administration.
2
On the Application Servers Administration dashboard, click Java Administration.
3
On the Java Administration dashboard, click the Installations tab.
4
On the Installations tab, click the installation host name in the Name column.
5
In the menu that opens, click Uninstall.
6
Read the caution and click Uninstall to confirm that you want to remove the entire installation.
A progress box opens.
7
Click Close to close the box when the process is finished.

Viewing Java Installation Properties

The installation properties include the location of the installation directory, and both the Java EE Integration Agent version and the Agent Manager name and version for that installation. This information is useful to have on hand when you are performing a manual integration with an application server.
To view the installation properties:
1
On the navigation panel, under Dashboards, click Application Servers > Administration > Application Servers Administration.
2
On the Application Servers Administration dashboard, click Java Administration.
3
On the Java Administration dashboard, click the Installations tab.
4
On the Installations tab, click the installation host name in the Name column.
5
In the menu that opens, click Properties.
The Installation Properties dialog box opens.
Use this dialog box to verify the location of the installation directory, and the agent and Agent Manager version information.
6
Click OK to close the dialog box.

Upgrading Java Installations

Upgrading an installation upgrades all agents that are managed through the installation. This is the same functionality as deploying a new .gar package to a monitored host.
Use the Installations tab of the Java Administration dashboard to determine the version of your installation and whether it is eligible for upgrade. This information appears in the Version and Upgradeable columns of the Installations table.
If an installation is upgradable, use the following procedure to perform an in-place upgrade.
To upgrade an installation:
1
On the navigation panel, under Dashboards, click Application Servers > Administration > Application Servers Administration.
2
On the Application Servers Administration dashboard, click Java Administration.
3
On the Java Administration dashboard, click the Installations tab.
4
On the Installations tab, look at the Upgradeable column for the installation you are interested in. If the word “Yes” appears, you can upgrade the installation.
5
Click the name of the installation you want to upgrade.
6
In the menu that opens, select Upgrade.
7
The dashboard refreshes, and the task appears in the Task History list, with a description such as: Upgrade Installation (<installation name>).
8
A progress indicator appears in the Result column while the task is in progress. The indicator is replaced by the text Success or Failure when the task is complete.
 
 

Foglight for Java EE Integration Configuration FAQ and Troubleshooting

This chapter discusses potential issues when configuring application servers for integration with Java EE Integration Agent.
 
Table 1. List of FAQs/Issues
FAQ / Issue
 
What are the supported JVM versions and what are the levels of metrics collected?
 
My integration task was a partial failure because the Java Home location was wrong. How do I correct it?
 
Why is the Java EE agent sometimes unable to detect the correct type for the application server?
 
Why does my application server take so long to start up after integrating it with the Management Server?
 
I have multiple application servers with the same name that reside on the same host. When the Java EE agents connect to the Management Server, why does only the first agent connect?
 
I received an error message about heap space shortage from the instrumented Java EE agent. What should I do?
 
Why do I see memory usage characteristic changes after enabling the Java EE agent?
 
When an application server running on a JRockit 1.4 JVM with a third party tool that uses the class option of the JRockit -Xmanagement flag is configured to run with the Java EE Agent, the Java EE Agent does not start. Why?
 
I received an error message about the max_long_data_size. What should I do?
 
Why does the Agent Manager support bundle not contain logs from the Java EE agent?
 
What are the supported JVM versions and what are the levels of metrics collected?
To help determine the level of metrics that are being collected for your JVM version, refer to the following table.
 
Table 2. JVM versions and collected metrics.
JVM Version
Level of Metrics Collected
IBM 1.4.2
Oracle JRockit 1.5.0_[05-07]
Limited
Oracle 1.4
Oracle JRockit 1.4
Oracle JRockit 1.5.0_[01-04]
Many
IBM 1.5, 1.6
Oracle 1.5, 1.6
Oracle JRockit 1.5.0_08 (R27.1.0) and above
Oracle JRockit 1.6
Full
OpenJDK 1.7
Oracle JDK 1.7
Full
* 
NOTE: For some versions of the JRockit JDK that ship with application servers the JMX implementation is problematic, which causes the JVM metrics collector to fall back to using APIs that do not provide as much information as is normally collected.
My integration task was a partial failure because the Java Home location was wrong. How do I correct it?
If you specify the wrong Java Home location during the creation of the Java EE Integration Agent, you can correct it from the Java Administration dashboard.
1
On the Integration Configurations tab of the Java Administration dashboard, click the name of the integration configuration (not the target) that you want to edit.
2
In the menu that opens, click Properties.
3
Type the correct value in the Java Home box.
4
Click Save.
5
Click OK to close the confirmation message box.
6
Click the name of the integration configuration again, and select Reintegrate targets.
7
In the Reintegrate dialog box that opens, select one or more targets and click Reintegrate.
Why is the Java EE agent sometimes unable to detect the correct type for the application server?
Users start their servers in various ways. Some of these ways may be different enough from the standard approaches described in this guide to cause the Java EE agent to be unable to determine the correct type for the application server. For example, if you are using a custom class to do some preliminary setup before launching the WebLogic server, and you are passing weblogic.Server as a parameter to this class rather than calling weblogic.Server directly in the Java startup line, the Java EE agent gets the wrong name for the application server.
If the Java EE agent is unable to detect the application server type, it disables the associated agent and logs a fatal error.
Workaround
The workaround is to set the application server name, and type explicitly as a system property in the Java command line that starts the application server. Add a -D option to the Java startup line that has this format:
-Dquest.agent.appserverinfo=<server-name>:<type>[:[<version>][:<cluster-name>]]
There are 4 fields, each separated by a colon-character.
The <server-name> and <type> are required parameters. The <version> and <cluster-name> are optional; if they are not supplied, the Management Server attempts to auto-detect the missing information. Valid application server type parameters are Generic, WebLogic, WebLogicNodeManager, WebSphere, WebSphereDmgr, WebSphereNodeAgent, WebSphereAdminAgent, OracleAS, and JBoss. The Java EE agent uses the server type and server version that are set in the command line to configure itself for that specific application server.
* 
CAUTION: Specifying an incorrect application server type or version number results in errors later in the startup sequence. Application server type parameters are case-insensitive.Specifying an incorrect application server version number results in errors later in the startup sequence. The format for setting the version parameter differs based on the application server that you are configuring to work with Management Server.
Consult the examples below for the correct server-specific and version-specific format to use to set the version parameter.This example specifies all four fields for a WebSphere 6.1 named server3 in a cluster named my_cluster: -Dquest.agent.appserverinfo=server3:WebSphere:6.1.0.27:my_clusterThis example specifies only 3 of the fields, leaving the agent to determine the application server version number for a WebLogic server named myserver in a cluster named my_cluster: -Dquest.agent.appserverinfo=myServer:WebLogic::my_cluster
Why does my application server take so long to start up after integrating it with the Management Server?
When configuring agents, the user that is running the server(s) must have read, write, and execute permissions on all directories under and including the Installation directory (QUEST_DEPLOYMENT_DIRECTORY). The installation directory is specified for the Java EE Integration Agent agent that is activated on the same host.
If you have manually integrated an application server with Management Server on AIX 5.3 with JVM 1.4, and the server is taking a long time to start up, it is due to a problem with JVM 1.4 on AIX 5.3.
Workaround
Add -Djava.net.preferIPv4Stack=true to the Java command line that starts the server.
See ibm.com for more information about the problem with JVM 1.4 on AIX.
I have multiple application servers with the same name that reside on the same host. When the Java EE agents connect to the Management Server, why does only the first agent connect?
This error occurs because the Foglight Management Server does not allow duplicate agent names. Agent names are duplicated when multiple servers with the same name on the same host try to connect. If multiple Java EE agents reside on the same machine with the same server name, only one is permitted to connect.
Workaround
The workaround is to uniquely identify the agent name by using the following server startup line:
-Dquest.config.agent.agentname=<unique_name>
For example, if you have two administrative servers for two different WebLogic domains running on the same host, the startup lines can be modified to include the following (one per server):
-Dquest.config.agent.agentname=test_domain.admin
-Dquest.config.agent.agentname=prod_domain.admin
Since the agent names are unique, they will connect to the Foglight Management Server but do not modify the server name.
For more detailed information, see About the Installation Directory .
I received an error message about heap space shortage from the instrumented Java EE agent. What should I do?
The Java EE agent is designed to monitor and collect valuable diagnostic detail out-of-the-box with minimal impact on application server heap. The agent configuration can be tuned to reduce (or increase) the amount of detail collected which in turn will reduce (increase) the agent memory usage.
The Java EE agent runs on the application server JVM and uses CPU resources to collect data about the application server. Two types of data are collected: periodic metrics (JMX) and request metrics (instrumentation).
•
The Java EE agent collects JMX metrics, such as heap usage, and thread count, regularly by calling standard JVM and application server MBean methods.
•
The agent collects request metrics as the application server processes requests that match the filters specified in the agent configuration.
Both types of data are transmitted to the Nexus running on the Foglight Management Server.
The memory usage is proportional to:
•
The number of metrics collected and the frequency at which they are collected
•
The number of service requests monitored, the level of detail captured about those requests, and the complexity of the requests
The metric collection memory usage impact is typically fixed, while the instrumentation memory usage impact varies considerably according to the application(s), workload, and the agent instrumentation and collection configuration.
Workaround
Consider increasing the heap size of the instrumented application server.
Why do I see memory usage characteristic changes after enabling the Java EE agent?
The Java EE agent runs in the same JVM as the application server. As a result, the memory usage behaviors of the Java EE agent can impact the memory usage behaviors of the Application Server, which in turn can impact the memory usage behavior of the operating system.
One major contributor for the change is that objects are allocated for a cache that stores instrumented class information so the agent does not need to examine it every time. This is an optimization made to improve the startup time performance. These are soft references, so the Garbage Collector can collect these objects if needed.
As a result, you may notice memory usage characteristic changes after enabling the Java agent.
Workaround
A few different strategies can be used to minimize the changes to memory usage characteristics, as follows:
•
The environment may benefit from some basic heap size tuning. For example, reducing the maximum size of the heap when it is unnecessarily large may not only improve garage collection performance, but it will also limit the size of the process. This can help alleviate problems that may arise from the JVM heap growing beyond typical or past levels.
•
Turning off class caching during instrumentation greatly reduces the number of allocated objects during instrumentation, and causes memory usage to more closely match the behavior that was exhibited before the Java EE agent was integrated. However, it also causes instrumentation to take longer.
To turn off class caching, add the following to the JVM startup command-line of the application server:
-Dquest.agent.class.cache.disable=true
* 
IMPORTANT: By disabling the class caching, the startup time of the instrumented application server will increase.
When an application server running on a JRockit 1.4 JVM with a third party tool that uses the class option of the JRockit -Xmanagement flag is configured to run with the Java EE Agent, the Java EE Agent does not start. Why?
Like some other third party tools, the Java EE Agent registers a management class with the JRockit JVM. Although the JRockit Management API supports multiple management classes, some third party tools, such as AspectJ, may replace previously registered management classes; this can prevent the Java EE Agent from starting. Fortunately, the Java EE Agent is designed to work with any previously registered management classes, but because management classes are processed in the order they are specified, the Java EE Agent management class must be specified after other management classes on the command line.
Workaround
Edit your application server startup script to add
‑Xmanagement:class=com.quest.pas.agent.bootstrap.JRockitPreProcessor to the java command line after the third party tool's ‑Xmanagement:class flag.
For example:
‑Xmanagement:class=org.aspectj.weaver.loadtime.JRockitAgent
‑Xmanagement:class=com.quest.pas.agent.bootstrap.JRockitPreProcessor
I received an error message about the max_long_data_size. What should I do?
When creating new agent profiles or adding configuration file overrides to an agent profile, the Management Server may log the following error messages:
SQL Error: 1105, SQLState: HY000
Parameter of prepared statement which is set through mysql_send_long_data() is longer than 'max_long_data_size' bytes
Could not synchronize database state with session
Workaround
Increase the value for the max_long_data_size or the max_allowed_packet system variable in your MySQL configuration. The recommended value is 8388608.
If you still encounter the error when using the recommended value, you must either increase the value further or reduce the number of agent profiles.
* 
IMPORTANT: The largest usable value is 1073741824, however it is recommended you increase the value in increments, by 50% at a time.
Why does the Agent Manager support bundle not contain logs from the Java EE agent?
In order for the Agent Manager (FglAM) support bundle to include the log files from the Java EE agent, the Java EE Integration Agent (JavaIntegrator) must be active when the support bundle is collected.
If the Java EE Integration Agent is not active, the support bundle contains logs from the Java EE Integration Agent, but not from the Java EE agent.
 
 
相关文档

The document was helpful.

选择评级

I easily found the information I needed.

选择评级