Managing agent profiles for websphere

Currently, using the websphere java probe, 10.5.1 on aix. With websphere upgrade to WAS8.5.5.13, we have run into a few issues. The scenario is there is one probe installation and multiple applications are using the agent and same profile. However, the application instances are running with unique accounts.

The umask in these accounts are not all the same. So, now, if entrypoints are enabled, they are all trying to read/write to the core/config/hotdeploy directory, but with differing permissions, some are not able to read/write successfully. It seems that sometimes there are also errors logged in the log files related that say an exception occurred checking directives files until I remove the files in the hotdeploy. The permissions issue can also impact the core/config/dynamic and logs directories also.

There are multiple issues as I indicated, but I was just wondering if someone has come up with some best practices for managing the agents in this kind of scenario that is not so hands on administratively. The alternatives that support indicates are 1) to turn off automatic entry point detection by setting introscope.agent.deep.entrypoint.enabled to false, 2)have a unique probe install path for each account used, 3) enable read/write for any of the existing accounts, somehow (except their umask prevents this and security frowns on 777 permissions anyway.

There are other issues, not necessarily related to the WAS upgrade, such as apps having issues with crossjvm process tracing with the CorID header growing and causing transactions to fail. This kind of thing is making me lean toward multiple probe installs and/or multiple profiles, both of which bring administrative overhead. Just wondering how others are managing agents.

When we first implemented APM, in 9.0.5.6, we worked through the WebSphere agent and found that the agent had to be within the WebSphere directory, with the ownership of the WebSphere admin account. This has worked fairly well since each of our different agent profiles we use are actually on different WebSphere servers/hosts.

For your problem, where you have different WebSphere process owners, the only suggestion I have is to run multiple agent directories with each having a custom profile that are both set on the JVM. This might cause the cross-jvm feature to not work since the cross-jvm assumes a single memory space, namely the WebSphere node agent in order to track across processes on a single WebSphere instance/server.

With multiple WebSphere instances on a single server, I believe each would have separate node agents, so the cross-jvm is going to add keys for each to try to track across the different instances.

Also read up on the SOA Performance Agent (SPA), since in 10.5 it is enabled by default and if you are using WebSphere 8.5 only, double check to see if you are using the Axis within WebSphere or a separate one to see if the 10.5 APM is compatible with it.

When we first implemented APM, in 9.0.5.6, we worked through the WebSphere agent and found that the agent had to be within the WebSphere directory, with the ownership of the WebSphere admin account. This has worked fairly well since each of our different agent profiles we use are actually on different WebSphere servers/hosts.

For your problem, where you have different WebSphere process owners, the only suggestion I have is to run multiple agent directories with each having a custom profile that are both set on the JVM. This might cause the cross-jvm feature to not work since the cross-jvm assumes a single memory space, namely the WebSphere node agent in order to track across processes on a single WebSphere instance/server.

With multiple WebSphere instances on a single server, I believe each would have separate node agents, so the cross-jvm is going to add keys for each to try to track across the different instances.

Also read up on the SOA Performance Agent (SPA), since in 10.5 it is enabled by default and if you are using WebSphere 8.5 only, double check to see if you are using the Axis within WebSphere or a separate one to see if the 10.5 APM is compatible with it.