How solve "GET unknown route" from APM Java?

Kibana version:
7.4.0

Elasticsearch version:
7.4.0

APM Server version:
7.4.0

APM Agent language and version:
APM Agent 1.7.0

Browser version:
Chrome 78.0.3904

Original install method (e.g. download page, yum, deb, from source, etc.) and version:
ELK Stack URL Download: docker.elastic.co/elasticsearch , Kibana and Beats
APM Agent URL Download: https://repo1.maven.org/maven2/co/elastic/apm/elastic-apm-agent/1.7.0/elastic-apm-agent-1.7.0.jar

Description of the problem including expected versus actual behavior. Please include screenshots (if relevant):

I installed and let the ELK Stack configuration default. After that, i installed APM Agent Java in Tomcat Server and edited the setenv.sh:

export CATALINA_OPTS="-Xms512M -Xmx3072M"
export CATALINA_OPTS="$CATALINA_OPTS -javaagent:/opt/tomcat/elastic-apm-agent-1.7.0.jar"
export CATALINA_OPTS="$CATALINA_OPTS -Delastic.apm.service_name=tomcat-appx"
export CATALINA_OPTS="$CATALINA_OPTS -Delastic.apm.application_packages=appx"
export CATALINA_OPTS="$CATALINA_OPTS -Delastic.apm.server_urls=http://192.168.0.44:8200"

I followed the wizard to enable APM Server and add service "tomcat-appx".

Some transactions was classified like "GET Unknown route".

How can i solved this?

Hi @dancristian,

By default, transactions are named with the Servlet name that handled the request.
Thus, if request does not reach a servlet, you get those unknown route transactions.

There are two possible cases:

  • your requests reach a servlet but Elastic agent is not properly able to detect those
  • your requests do not reach a servlet: handled by filter, static resources, ...

Regarding detection of Servlets, agent has a 'pre-filter' heuristic to only consider classes which name
ends with 'Servlet'. This heuristic can be disabled by setting the internal configuration enable_type_matching_name_pre_filtering=false.
Please note that this has an impact on all plugins, thus a small extra overhead during application startup time is expected.

In the second case, it is possible to change the default transaction naming to use URL path instead.
use_path_as_transaction_name.

The major implication is that it may create lots of duplicate transactions if they have similar paths
like /usr/{id} where {id} is the user ID, you can get as many transactions as there are users.

Thus, if required, you can mitigate this by using
url_groups, which will allow to use wildcards in transaction URLs.

Another option is to set transaction names using our API:

Also, could you provide us some details about the application ?
For example do you have a list of all servlets that should be instrumented ?