Closed codeboten closed 1 month ago
go.opentelemetry.io/collector/service/process_telemetry
here is probably just otelcol
?
go.opentelemetry.io/collector/exporterhelper
here we should calculate the scope name at runtime based on the exporter that uses the helper correct?
go.opentelemetry.io/collector/obsreport/processor
same as above.
@bogdandrutu are you in favour of keeping the short form or the long form scope name? or both?
here is probably just otelcol?
I guess it depends on how specific we want this scope to be. Would it make sense to scope it to the individual go modules that are published? This way it would allow a consumer of the telemetry to identify package versions and maybe if there's a problem with a specific module version, they would be able look at the scope information to narrow down their search?
I like the fully qualified name a bit more, as it is more descriptive. We also have some components of different types that have the same name, which would result in same short scope name, for example:
otelcol/routing
scope nameotelcol/datadog
otelcol/sumologic
I lean towards the opinion that e.g. exporterhelper
should use the scope of the exporter that it is embedded in. I'm not convinced that we should surface Go module names in the metrics exposed to users - this feels like an implementation detail. We don't want the metrics to change when we move functionality from one module to another, which might otherwise be a purely non-functional refactoring.
I've liked when the scope name is actually a link to the godocs for the package (e.g. go.opentelemetry.io/collector/exporter/exporterhelper). It removes any ambiguity for someone trying to figure out where the metric is defined, or what it is about.
I've liked when the scope name is actually a link to the godocs for the package (e.g. go.opentelemetry.io/collector/exporter/exporterhelper). It removes any ambiguity for someone trying to figure out where the metric is defined, or what it is about.
The problem with this, is that we need also a attribute to describe the component (exporter name) for which you record the metric when is a shared library like exporterhelper
. I do understand that using go.opentelemetry.io/collector/exporter/exporterhelper
may help but comes with that downside, which we may be fine.
Looks like this is resolved for the core repo. We still use short version in contrib, e.g. otelcol/countconnector
. We need to update that as well. I see 3 options:
go.opentelemetry.io/collector/connector/countconnector
github.com/open-telemetry/opentelemetry-collector-contrib/connector/countconnector
go.opentelemetry.io/collector-contrib/connector/countconnector
assuming we are going to migrate the modules to vanity URLs in contrib https://github.com/open-telemetry/opentelemetry-collector-contrib/issues/21469What do you think?
Option 3. makes most sense to me.
@dmitryax perhaps add emojis to each option (e.g. 1 :tada: , 2 :heart: , 3 :rocket:) to enable voting on your comment. :slightly_smiling_face:
This has been done for core and contrib components.
The meter name (that is translated into scope name) is currently inconsistent in this repository. Some components instantiate a meter with a short form like the following, which is consistent w/ the contrib repo:
While others use a fully qualified name, which is consistent w/ go instrumentations:
These should be consistent.