6.3 J2EE monitoring maintenance

< Day Day Up >

During our work on this redbook, we ran into a small number of problems using the J2EE monitoring component. Most of these issues were because we were using prerelease code for much of our work. While troubleshooting these issues, the following steps were useful and may prove useful in a production environment.

ARM records not created

If you are not receiving ARM records, you can use the following steps to ensure that there are no problems with the policy, J2EE, or ARM. These steps will verify that the ARM engine recognizes the policy and that ARM records are being generated by J2EE.

Verify that the J2EE component successfully installed.

Verify in the User Interface "Work with Agents" section that the J2EE component says RUNNING.

Possible problem:

UI does not say RUNNING… .

Possible solution:

If the UI says INSTALL_IN_PROGRESS, then keep waiting. If you wait for an extremely long time (30 minutes), and you checked Automatically restart Application server, then the install is hung. You will need to manually stop and restart the application server on the Management Agent. If you do this and it does not switch to RUNNING, open a defect on Instrument.

If the UI says INSTALL_RESTART_APPSERVER, then restart the appserver on the Management Agent and rerun the PetStore or other application to collect ARM data.

If the UI says INSTALL_FAILED, then verify that you entered the correct info for your J2EE component. If you think everything was entered correctly, then open a defect on Instrument.
Verify that the J2EE appserver is instrumented.

Verify that the following files/directory structure exists:
- Management Agent
- Common J2EE Behavior files
- <MA_HOME>/app/instrument/appServers/<UUID>/BWM/logs/trace.log
Possible problem:

If this file does not exist, then the application server has not been instrumented or the application server needs to be restarted for the instrumentation to take affect.

Possible solution:

Restart the appserver and access one of your instrumented applications (that is, an application that you have defined J2EE a policy for). If the trace log still does not exist, then verify you entered the correct information into the policy. If you have entered the correct information and the trace file has not been created, then you may have encountered a defect, in which case you will need to log a PMR with IBM Tivoli Support.
Verify that your Listening Policy exists on Management Agent.

This step will verify that the Management Server sent the Management Agent your listening policy correctly; in order for this section to work, you will need to re-enable access to the HTTP Adaptor of the MBeanServer on your Management Agent. The procedure to do this is described in 6.1.1, "Checking MBeans" on page 182.

Open a browser and go to the address http://MAHost:6969, where MAHost is the host name of the Management Agent you wish to check.
1. Select Find an MBean.
2. Select Submit Query.
3. Select TMTP:type=MAPolicyManager.
Verify that your policy is listed here (the URI pattern you have specified in the policy will be listed).

Possible problem:

If the policy does not exist, but you selected "Send to Agents Now" in your policy, then there was a problem sending the policy from the Management Server to the Management Agent.

Possible solution:

To get the policy:
1. Select pingManagementServer().
2. Select Invoke Operation.
Click Back twice and then press F5 to refresh the screen.

Verify that your policy is listed here. If this has not fixed your problem, you may have encountered a defect and should open a PMR with IBM Tivoli Support.
Verify that ARM is receiving transactions.

This step will verify that ARM is using your listening policy correctly and that J2EE is submitting ARM requests.

Open the ARM engine log file in which is located in the Tivoli Common Directory. On Windows, it is located in C:\Program Files\ibm\tivoli\common\BWM\logs\tapmagent.log.

Search this file for arm_start. If it exists, then J2EE is correctly instrumented and making ARM calls.

Possible problem:

If arm_start does not exist, then J2EE could be instrumented incorrectly. Verify in the UI that the J2EE component says RUNNING.

Possible solution:

If there is no arm_start but the UI says RUNNING, you may have encountered a defect and should open a PMR with IBM Tivoli Support.

If arm_start exists, then search the file for WriteNewEdge. If this exists, then ARM has successfully matched a J2EE edge with an existing policy.

Possible problem:

If arm_start exists but WriteNewEdge does not exist, then there could be a problem with your listening policy or your have not run an instrumented application.

At this point, also check to see if ARM_IGNORE_ID exists. If it does, then the edge URI for the listening policy is not matching the edge that J2EE is sending.

Possible solution:

Verify that you have run an application that would match your policy. Verify that the listening policy is on the Management Agent and that the URI pattern matches what the URI you are clicking on for the application on the Management Agent's appserver. If this is still a problem, then you may have to open a PMR with IBM Tivoli Support.

< Day Day Up >