Service_name auto-discovery issue

Elastic Observability APM
1

Kibana version: 7.10.1

Elasticsearch version:7.10.1

APM Server version:7.10.1

APM Agent language and version: 1.26.0

Description of the problem including expected versus actual behavior. Please include screenshots (if relevant):
Service name is being auto discovered as '-project-artifactId-' which is incorrect

image
image923×524 29.7 KB

Steps to reproduce:

  1. Run my java application with the -javaagent parameter set
  2. Metrics reach APM as expected and viewable in Kibana
  3. Service name is incorrectly discovered as '-project-artifactId-'

Provide logs and/or server output (if relevant):

Full command that runs the application is...
/usr/bin/java -javaagent:/usr/local/apm/elastic-apm-agent-1.26.0.jar -Xms82m -Xmx2048m -DdockerNetworkNames=SA_Service_Overlay -DdockerServiceNames=capability-access-manager_rest -DhazelcastPeerPort=5701 -DdockerServiceLabels=container_name=capability-access-manager-rest -DskipVerifySsl=False -DlogAllServiceNamesOnFailedDiscovery=false -DstrictDockerServiceNameComparison=true -cp capability-access-manager-rest.jar -Dhttps.proxyHost= -Dhttps.proxyPort= -Djdk.tls.ephemeralDHKeySize=2048 org.springframework.boot.loader.JarLauncher

Docker log when container spins up...

2021-11-18 15:25:33,014 [main] INFO  co.elastic.apm.agent.util.JmxUtils - Found JVM-specific OperatingSystemMXBean interface: com.sun.management.OperatingSystemMXBean
2021-11-18 15:25:34,704 [main] INFO  co.elastic.apm.agent.configuration.StartupInfo - Starting Elastic APM 1.26.0 as JarLauncher on Java 1.8.0_212 Runtime version: 1.8.0_212-b04 VM version: 25.212-b04 (IcedTea) Linux 3.10.0-1127.19.1.el7.x86_64
2021-11-18 15:25:34,706 [main] INFO  co.elastic.apm.agent.configuration.StartupInfo - environment: 'PRO-1' (source: Environment Variables)
2021-11-18 15:25:34,707 [main] INFO  co.elastic.apm.agent.configuration.StartupInfo - server_url: 'https://gt6h12345.icts.abc.net:8200' (source: Environment Variables)
2021-11-18 15:25:34,708 [main] INFO  co.elastic.apm.agent.configuration.StartupInfo - verify_server_cert: 'false' (source: Environment Variables)
2021-11-18 15:25:34,709 [main] WARN  co.elastic.apm.agent.configuration.StartupInfo - To enable all features and decrease startup time, please configure application_packages
2021-11-18 15:25:57,471 [main] INFO  co.elastic.apm.agent.impl.ElasticApmTracer - Tracer switched to RUNNING state
2021-11-18 15:25:58,550 [elastic-apm-server-healthcheck] INFO  co.elastic.apm.agent.report.ApmServerHealthChecker - Elastic APM server is available: {  "build_date": "2021-01-12T21:51:32Z",  "build_sha": "42a349a4ec9d2dd16e08b8af125647294e7a7e4b",  "version": "7.10.2"}
{"@timestamp":"2021-11-18T15:26:06.778+00:00","@version":1,"message":"Client environment:java.class.path=capability-access-manager-rest.jar:/usr/local/apm/elastic-apm-agent-1.26.0.jar","logger_name":"org.apache.zookeeper.ZooKeeper","thread_name":"main","level":"INFO","level_value":20000}
2021-11-18 15:26:19,591 [main] WARN  co.elastic.apm.agent.bci.bytebuddy.ErrorLoggingListener - io.micrometer.core.instrument.MeterRegistry$$EnhancerBySpringCGLIB$$983437b8 uses an unsupported class file version (pre Java 4}) and can't be instrumented. Consider updating to a newer version of that library.
2021-11-18 15:26:22,032 [main] INFO  co.elastic.apm.agent.micrometer.MicrometerMetricsReporter - Registering Micrometer MeterRegistry: io.micrometer.prometheus.PrometheusMeterRegistry@42dd7d82
2021-11-18 15:27:44,213 [main] INFO  co.elastic.apm.agent.servlet.ServletVersionInstrumentation - Servlet container info = Apache Tomcat/9.0.16
2

Hi and welcome to our community!

Did you try to set ${project.artifactId} or something similar somewhere in your application (e.g. as the <display-name> in your web.xml or spring.application.name in application.properties), expecting it to be replaced on build time?

If so, note that it doesn't get rendered as you expect, and since it contains some illegal characters, as documented, they are being escaped.

In order to fix that, either make sure that your application artifacts contain the proper service/application name, or set the service_name configuration manually.

3

Thanks for feedback here. I looked at what you suggested and I see the following is set in the /capability-access-manager-rest/src/main/resources/application.properties file....

"application.name=@project.artifactId@"

Is this what is being used?

We have a number of other applications and this property is also set as above but the autodiscovery is working as expected

4

It seems to be the case

I guess in those other applications this value is properly being set with a proper value at build time

5

I can see in the associated pom.xml that the project artifactId is set as capability-access-manager-rest

Is there any way, logs or otherwise, where I see what value the auto discovery is picking up? We plan to on-board a significant number of applications so I want to avoid this issue in future.

6

Currently only if you set log_level to DEBUG (or lower). Can you use this logging level only for the onboarding process?

7

I'll see can I deploy a Github code branch to our test environment. Will the service discovery module logging be detailed enough to give me the information I need if I set it to DEBUG?

8

It should print something like: Using <AUTO-DISCOVERED-NAME> as the service name for class loader <CLASS-LOADER>.
Try it with the one you already have.

9

This topic was automatically closed 20 days after the last reply. New replies are no longer allowed.