Open AlexanderWert opened 1 week ago
Pinging @elastic/unified-observability (Team:Observability)
Pinging @elastic/obs-knowledge-team (Team:obs-knowledge)
cc @basepi
@AlexanderWert Is the goal to just split these new agent names such that they fall into the existing buckets? Or are we trying to collect the distro as well?
@AlexanderWert Is the goal to just split these new agent names such that they fall into the existing buckets? Or are we trying to collect the distro as well?
@basepi We want to be able to at least differentiate our distro (i.e. with agent name opentelemetry/java/elastic
) from any other OTel distro (i.e. agent names opentelemetry/java/*
or just opentelemetry/java
for older Stack versions)
@basepi We want to be able to at least differentiate our distro (i.e. with agent name opentelemetry/java/elastic) from any other OTel distro (i.e. agent names opentelemetry/java/* or just opentelemetry/java for older Stack versions)
Understood. That may be complicated on the telemetry collection side, but we'll investigate when we dig into the data.
In the past, all OpenTelemetry SDKs / agents had the
agent.name
patternopentelemetry/<LANGUAGE>
. So, for theper_cluster
snapshot telemetry the set of valid agent names was a closed setAGENT_NAMES
as being used in this telemetry task.With the introduction of
distro.name
into opentelemetry and Elastic introducing its own distros of the language SDKs theagent.name
has the patternopentelemetry/<LANGUAGE>/<DISTRO_NAME>
(e.g.opentelemetry/java/elastic
or`opentelemetry/java/opentelemetry-java-instrumentation
). With that the set of valid agent names is expanded / open-ended.The current task for per-cluster snapshot telemetry just ignores this new name pattern and, thus, ignores that data for telemetry. This needs to be fixed to still retrieve correct telemetry data and to ebing able to have proper telemetry for our new Elastic distros of the OTel SDKs.