Open Mpdreamz opened 1 year ago
This seems reasonable to me.
We're currently trying to implement the Java agent as follows:
So for example, take the log level. The Elastic default is INFO. So
Note that we rolled back trying to support elastic config in the Java agent. The current strategy is to not explicitly support any elastic configs and give documentation that tells users how to convert from a subset of elastic configs to otel configs
Thanks for highlighting that @jackshirazi 👍 We'll follow on from your learnings and won't do this in our agent, existing or new OTEL wise.
listening to OTEL environment variables in our logging libraries might be its own discussion though as per: https://github.com/elastic/apm/issues/816
Will put that back up on the agenda next week.
Relates to: https://github.com/elastic/apm/pull/813 where we'd listen to
OTEL_*
environment variables in the context of logging.If we agree to make our
ecs-logging
OpenTelemetry aware it makes sense to extend the same logic to our agent configuration.Quick summary is to propose adding support for the following
OTEL_*
environment variables.OTEL_SDK_DISABLED
OTEL_RESOURCE_ATTRIBUTES
OTEL_SERVICE_NAME
OTEL_LOG_LEVEL
This would create a new resolving logic for the listed APM Agent configuration items:
Enabled
ELASTIC_APM_ENABLED
OTEL_SDK_DISABLED
if settrue
ServiceName
ELASTIC_APM_SERVICE_NAME
OTEL_SERVICE_NAME
OTEL_RESOURCE_ATTRIBUTES
value forservice.name
ServiceVersion
ELASTIC_APM_SERVICE_VERSION
OTEL_RESOURCE_ATTRIBUTES
value forservice.version
Environment
ELASTIC_APM_ENVIRONMENT
OTEL_RESOURCE_ATTRIBUTES
value fordeployment.environment
ServiceNodeName
ELASTIC_APM_SERVICE_NODE_NAME
OTEL_RESOURCE_ATTRIBUTES
value forservice.instance.id
LogLevel
ELASTIC_APM_LOG_LEVEL
OTEL_LOG_LEVEL
Error
.We could later follow this up with a discussion on what other resource semantic conventions we could support in the future. As well as finding a way to map
OTEL_RESOURCE_ATTRIBUTES
toGlobalLabels
but leaving it out of scope for now.