APM config overriding

Elastic Observability APM
1

Guys, first of all thank you for fixing this issue APM config_file location
We have switched to 1.11.0 and it works like a charm

ATM I am experiencing anther issue with configs
Docs say that:

The first configuration sources override the configuration values of over the latter sources.

I am running Spring Boot App with properties file, having

service_name=app-dev

and try to override this value by setting -Delastic.apm.service_name=app-feature-branch or even by setting env variable ELASTIC_APM_SERVICE_NAME=app-feature-branch
and don't see any effect

Can you please confirm that this feature works for Java?

Kibana version : 6.8.0

Elasticsearch version : 6.8.0

APM Server version : 6.8.0

APM Agent language and version : JAVA apm-agent-attach:1.11.0, apm-agent-api:1.11.0

Java version : openjdk:11

2

The problem is that currently, the properties file in src/main/resources of your Spring Boot app gets treated differently than the _AGENT_HOME_/elasticapm.properties file. The former is always applied as the highest prio config source while the latter behaves like documented.

While I think that's a bug some might rely on that behavior. But as it's not really behaving as documented I'm in favor of changing it.

@Eyal_Koren @Sylvain_Juge wdyt?

3

okay, but then the whole concept of overriding and having central config doesn't make much sense for Spring Boot apps then :frowning:

4

You mean even when fixing the order so that it matches the order described in the the documentation?

5

Sorry, if i wrote it unclear in the beginning

I mean, I think we should fix the implementation for spring boot to be the same as defined in the docs, so property file (even located in resorces folder) has the least prio and can be overridden upon app deployment with values from environment and from central config

6

I agree. Let's see what the others think.

7

I agree that it needs fixing, so it is in accordance with the documentation.
Regarding breaking it for current users- can we add a message in log right before we log all the configs we see, and in a Breaking changes sections in the release notes. Should be enough.

2 Likes
8

Hi,

Also got caught out by this one. As a product developer, we would like to be able to provide a default config that can be overridden as required. It does not appear that this is possible using classpath mechanisms.

Is there any workaround for this in the interm?

Is the possible fix here for backward comparability to add support for reading an addition config from the classpath with a different name to preserver backwards comparability.

However, in terms of backwards comparability the current behaviour is not documented. Having the elasticapm.properties on the classpath is different to having it in the AGENT_HOME

Anyone who is currently using it on the classpath and is not having issues is not aware of the limitation and I don't believe that backwards comparability will effect them.

All that said I am in favour of fixing this and adding section to breaking changes section.

My 2c...

9

I have filed an issue to improve both documentation and implementation for classpath configuration. Don't forget to subscribe to it in order to know when this will be fixed.

10

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