CA Wily on HP ALM application

[CMCN1982]

Hi, 

 

I have Wily successfully configured in our HP ALM production environment. I can see both of my applications listed in the Investigator console and they are monitoring resource usage as expected.

 

However, when I try to set it up in the exact same way in my HP ALM Development environment it does not work. The application server cannot be seen in the Investigator console.

 

Details below:

 

We are using CA APM Introscope Agent 10.1.0.15 in both Production and Dev.

Install path is the same on both: D:\Wily

 

In the application's wrapper file we have it configured exactly the same.

 

wrapper.java.additional.20=-javaagent:D:\\wily\\Agent.jar
wrapper.java.additional.21=-Dcom.wily.introscope.agentProfile=D:\wily\core\config\IntroscopeAgent.profile

 

In the IntroscopeAgent.profile they are configured similarly, the only difference being that we point to different Wily DNS names to distinguish between our Wily production and Wily dev. For example:

 

Prod:

introscope.agent.enterprisemanager.transport.tcp.host.DEFAULT=XX.***.***.*** (Our Wily Prod IP)
introscope.agent.enterprisemanager.transport.tcp.port.DEFAULT=5101
introscope.agent.enterprisemanager.transport.tcp.socketfactory.DEFAULT=com.wily.isengard.postofficehub.link.net.DefaultSocketFactory

 

Dev: 

 

introscope.agent.enterprisemanager.transport.tcp.host.DEFAULT=***.XX.***.XX (Our Wily Dev IP)
introscope.agent.enterprisemanager.transport.tcp.port.DEFAULT=5101
introscope.agent.enterprisemanager.transport.tcp.socketfactory.DEFAULT=com.wily.isengard.postofficehub.link.net.DefaultSocketFactory

 

We restart the application's service as well as the server, but still cannot figure out why the Wily agent is not being triggered. This is what I see in the wrapper.log file of the application when it restarts:

 

Launching a JVM...
INFO | jvm 1 | 2017/12/20 11:03:20.072 | -XX:+ExplicitGCInvokesConcurrent -XX:+HeapDumpOnOutOfMemoryError -XX:InitialHeapSize=8594128896 -XX:MaxHeapSize=8594128896 -XX:MaxPermSize=536870912 -XX:MaxTenuringThreshold=6 -XX:NewRatio=2 -XX:OldPLABSize=16 -XX:+PrintCommandLineFlags -XX:+PrintFlagsFinal -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC -XX:-UseLargePagesIndividualAllocation -XX:+UseParNewGC

 

So no mention of Wily there. But when I check the same wrapper log file in Production, Wily isn't mentioned there either. But yet it works in Production.

 

Does anyone have any tips or advice? Thanks.

[Haruhiko Davis]

Is the agent producing any logs?

Are the JRE versions the same in both environments?

What is the Java container (Tomcat, JBoss, etc)?

[CMCN1982]

Both environments are using 1.8.0_73

The Java container is Jetty

 

I checked for logs (d:\wily\logs) in the non-working tier and there are no recent logs.

[Haruhiko Davis]

Have you tried grabbing the working wrapper.conf file and copying it to the non-working setup?

Have you tried DIFF'ing the files to see where the differences are?

[CMCN1982]

Tried both suggestions. The server still does not appear. It is very strange.

[Haruhiko Davis]

Please email me your wrapper.conf from both.
Let me know which one doesn't work.

 

[e-mail]

[CMCN1982]

Just sent. Thanks.

[Haruhiko Davis]

Yes I got them.

[Hallett German]

Dear Colin:

I am marking this as answered since this should have been a discussion and multiple responses have been given. You are also welcome to open a case as well. Please provide an update on your progress so others can learn from your use case

[Haruhiko Davis]

I'm meeting with Colin tomorrow to go over the configurations.

[CMCN1982]

Thank you so much Haruhiko.

 

We eventually discovered that another monitoring tool was installed on the server and there appeared to be some conflict between it and Wily.

No matter what we tried the wily Agent.jar wasn't being triggered when the application was starting up despite the wrapper.conf and IntroscopeAgent.profile config looking ok.

 

Once we removed the other monitoring tool and restarted the server, Wily began to work ok.

 

Thank you all once again for your assistance with this - much appreciated.

[Haruhiko Davis]

Awesome. You cannot have two monitoring tools trying to do bytecode instrumentation at the same time. It will cause strange issues like this.