Splunk AppDynamics

Identifying the deployed Java Agent supported version and distribution

Andrew_Nerdahl
Explorer

I’m attempting to determine how to identify the distribution of the Java Agent deployed on a server.

I know that for the agents that support Java1.7 or lower you can unpack the javaagent.jar and look at /META-INF/MANIFEST.MF

If it’s the IBM specific agent:
Then Implementation-Version will read “Server IBM Agent #”
Elseif it’s the Sun+JRocket:
Then Implementation-Version will read “Server Agent #”

However, how do you tell if it’s the Sun+JRocket that supports Java1.7 and lower, or the Sun+JRocket that supports Java1.8 or higher?

I have unpacked javaagent.jar for both agents, ran a diff on the entire file structure and it came back with no results.

Labels (1)
0 Karma
1 Solution

Andrew_Nerdahl
Explorer

Per AppDynamics support in attempting to identify the java 1.7 Sun+JRocket agent from the java 1.8 agent:

"Unfortunately there is no way (other than the appdynamics download page and checking the checksums) that can show the difference between 1.7 and 1.8 versions."

If I were to follow supports recommendation, this would mean that there would need to be 3 data stores that contained the checksums of every agent release since 20.7.0.0 (1 for java1.8, 1 for java1.7-ibm, and  for java1.7-sun+jrocket) so that you could check which list the agent you're working with falls under. The only way to build those data stores is to manually download and extract each checksum from every agent.

Since that process would be far to costly from a data transfer and time expediture stand point...

I have opted to alter the agent packages and add a unqiue coded entry and value to the MAINIFEST.MF under the base directory javaagent.jar file. The same place the entry that identifies the IBM agent from the Sun+JRocket agent. This allows me to gather the needed information at the same time and location as the 1.7 agent sub-distribution.

This is a massive oversight on AppDynamics part in the configuration and release management disciplines. One that could have been easy corrected... in the exact same way that I have been forced to correct it for them.

View solution in original post

Andrew_Nerdahl
Explorer

Per AppDynamics support in attempting to identify the java 1.7 Sun+JRocket agent from the java 1.8 agent:

"Unfortunately there is no way (other than the appdynamics download page and checking the checksums) that can show the difference between 1.7 and 1.8 versions."

If I were to follow supports recommendation, this would mean that there would need to be 3 data stores that contained the checksums of every agent release since 20.7.0.0 (1 for java1.8, 1 for java1.7-ibm, and  for java1.7-sun+jrocket) so that you could check which list the agent you're working with falls under. The only way to build those data stores is to manually download and extract each checksum from every agent.

Since that process would be far to costly from a data transfer and time expediture stand point...

I have opted to alter the agent packages and add a unqiue coded entry and value to the MAINIFEST.MF under the base directory javaagent.jar file. The same place the entry that identifies the IBM agent from the Sun+JRocket agent. This allows me to gather the needed information at the same time and location as the 1.7 agent sub-distribution.

This is a massive oversight on AppDynamics part in the configuration and release management disciplines. One that could have been easy corrected... in the exact same way that I have been forced to correct it for them.

iamryan
Community Manager
Community Manager

Hi @Andrew.Nerdahl,

Thank you for adding that information from Support. Knowledge sharing is key to the community.

0 Karma
Get Updates on the Splunk Community!

Aligning Observability Costs with Business Value: Practical Strategies

 Join us for an engaging Tech Talk on Aligning Observability Costs with Business Value: Practical ...

Mastering Data Pipelines: Unlocking Value with Splunk

 In today's AI-driven world, organizations must balance the challenges of managing the explosion of data with ...

Splunk Up Your Game: Why It's Time to Embrace Python 3.9+ and OpenSSL 3.0

Did you know that for Splunk Enterprise 9.4, Python 3.9 is the default interpreter? This shift is not just a ...