Better service name and version detection

[felixbarny]

Currently, the only way to take advantage of the deployment tracking is to use the service_version configuration option.

We could get the version from the MANIFEST.MF Implementation-Version entries.

While doing that, we might also want to read the Implementation-Title entry, if available to determine the service.name.

Spring Boot seems to set both of these entries.

Tasks

• Standalone jars
  • Use Implementation-Title as default service name if it is available #1921
  • Use Implementation-Version as default service version if it is available #1922
• Web applications
  • Service name discovery based on webapp manifest #2434
  • Added Instrumentation for ServletContextListener#contextInitialized #2443
• Service name auto discovery docs and polishing #2440

[samilAyoub]

@felixbarny Could you give me a few pointers to deal with that?

[felixbarny]

I gave a bit of thought after reading #1725 (comment)

I think we can make it more generic than just doing it specifically for the Servlet API.
Already today, each transaction is started in the context of a specific class loader. When co.elastic.apm.agent.impl.ElasticApmTracer#overrideServiceNameForClassLoader has been called before with that specific class loader, the overridden service name will be used.

What we could do on the first invocation of co.elastic.apm.agent.impl.ElasticApmTracer#getServiceName for a given classloader is trying to load the META-INF/MANIFEST.MF for that classloader and to override the service name and service version based on that.

That would probably work generically for any framework by looking up the service name based on the manifest entry when the first transaction of any given service starts. It can also help to determine the service name early enough in the startup process for the automatic ECS log reconfiguration (#1261) to add the correct service.name to the logs.

It needs validation but it seems worth trying it out.

[tobiasstadler]

I played with it a little bit here: https://github.com/tobiasstadler/apm-agent-java/tree/poc-service-name-and-version. It lacks tests and documentation, but It my it (mostly) works for me.

[felixbarny]

This looks great! It has one issue, though. It assumes that the agent is attached at startup via -javaagent. However, we also support runtime attachment. At the point in time when the agent is runtime-attached, all the initializers might have already run. Is there a particular reason why you preferred resolving the service name and version so early in the startup process, as opposed to resolving them when the first transaction is started? The latter seems easier, wouldn't require technology-specific instrumentations, and works with runtime attachment. But maybe I'm missing something why it's important to resolve the service name/version early.

[felixbarny]

Another thing to consider is that a single JVM may have multiple service names, for example when multiple web applications (e.g. war files) are deployed to a single Tomcat instance. I'm referring specifically to the void overrideServiceName(@Nullable String serviceName) method In your POC.

[tobiasstadler]

I implemented early service name/version detection because in case of Application Servers transactions might already be created before the first request hits the application. E.g. during deployment using startup EJBs or CDI events or after deployment using scheduled EJBs. Also the are applications which might not have a http interface because they only process JMD/Kafka/... messages. In this cases the transactions will have the „wrong“ service name/version, if more than one application is deployed on the same application server.