DX Application Performance Management

As we discovered in an earlier post the PMI scripts listServers and configurePMI along with the companion JACL have been removed from the distribution files starting in 10.3. There have tbeen updated setPmiModules.jacl loaded here on the community site, the lasted one of 9.5 (when the PPK was incorporated into the WebAppSupport jar file).

My readying in the manuals seems to indicate that the noredef implementation should be used on all Java 1.6,x based JVM even in WebSphere 7.x.

Also, my understanding is that PMI is now totally controlled from the IntroscopeAgent.profile so the JACL script should not have the section to enable specific PMI metrics...

Has anyone or is anyone looking at modifying the scripts to reflect what is needed in the WebSphere 10.5 agent? I had this agent installed on 2 machines with 8 JVMs each and the WAS admin complained that he had (according to the manual) to create the custom service for each JVM.

Thanx

Steve

The JACL script is used to:

1. Identify each WAS instance for instrumentation (and update the Generic JVM Arguments)
2. Create the Introscope Startup Class
3. Configure PMI settings for each WAS instance

You can get a copy of the AgentNoRedefNoRetrans.jar in the 'allappserver' archive (tar/zip).

We have been using APM since 9.0.5.6 and have never used the automatic PMI or agent setup scripts.  We had to apply/request for each of the changes to each server in each environment till around the 9.6 time frame when the WebSphere admins got tried of the manual process and added the agent and settings in their WS instance creation

scripts.

The agent will only pick up a small sub-section of PMI metrics.  The mapping between what is within the agent.profile versus the actual name of the PMI takes a bit to translate but well worth the effort so everyone knows what the APM will and will not be able to be configured to request.

The 10.5 documentation has a few more things that you might have to do:

https://docops.ca.com/ca-apm/10-5/en/implementing-agents/java-agent/install-the-java-agent/configure-application-server-to-use-the-java-agent/websphere

Namely the Java2 Security Policy if you have change if you have Java Security turned on

Enabling the Business Process Service - Work Area Service so the EJB over Java RMI cross-process tracing is enabled.

On the PMI metrics, We went round and round with the WebSphere admins about the full gambit of PMI metrics that the agent could capture and report and after quite a bit of testing and reading on the costs of the PMI generation, we don't turn on everything.  We have a very limited sub-set since some of the PMI is rather costly to capture.

There are a few more settings within WebSphere to capture Resource Metric Map Data. 

Yes, all 1.6 JRE/JVM has to use the noredef profile or the agent will consume more than 10% of the CPU. 

Not in the manual but I would highly suggest using a WebSphere environment variable for the location of the agent.  That way, if you are upgrading, you create a new directory /opt/IBM/WebSphere/wily10-5 and then you can change the environment variable to the new location and if things go south, you can quickly revert to the previous directory.

PMI - Highly suggest you work with the WebSphere admins to define what will or won't be turned on within WebSphere.  Once it is turned on within WebSphere then you modify the .profile to be aware of the new PMI metric.  I usually have everything mapped and comment out any of the unused PMI setting within the .profile so the answer each and every time one of the WebSphere admins turn on PMI thinking that APM is going to capture it will be "It was not turned on within the agent configuration because that PMI is very costly.  We can turn that on for you, but we will need to have a plan to turn it back off soon after."

As the APM admin, I typically provide two agent directories, one for the 1.6 JVM and the other for 1.7 with very specific naming on the zip.  Then I typically provide any sort of update to the installation instructions.  The new version agents are deployed to a couple test servers, and the testing team adds load to those servers.  This will provide some sort of resource impact, usually we jump back and forth between no agent, old agent, new agent with the same load to see what the resource differences are for the new agent.  If everything is acceptable resource wise, then we get a more broader agent deployment to the non-production servers.

Then after a month, we typically get the OK to schedule the agent deployment in production.

Do hope this helps,

Billy

Hi Steve:

Were the answers provided helpful on when to use the scripts and giving further information on this topic?

Thanks

Hal German

Hi Steve:

     Marked as answered since two detailed responses were given and there were no follow-up questions. Please feel free to post additional questions as needed.

Thanks

Hal German