New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Consistent scope name scheme #9494
Comments
here is probably just
here we should calculate the scope name at runtime based on the exporter that uses the helper correct?
same as above. |
@bogdandrutu are you in favour of keeping the short form or the long form scope name? or both?
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:
I lean towards the opinion that e.g. |
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 |
This is part of open-telemetry#9494 Signed-off-by: Alex Boten <aboten@lightstep.com>
This is part of #9494 --------- Signed-off-by: Alex Boten <aboten@lightstep.com>
Looks like this is resolved for the core repo. We still use short version in contrib, e.g.
What do you think? |
Don't use hardcoded "go.opentelemetry.io/collector" prefix. Provide a way to specify the `scope_name` in metadata.yaml. If not provided, try to use the go package name. Updates #9494
This change migrates `generate` make target from using deprecated cmd/mdatagen defined in this repo to mdategen defined in core repository. In order to avoid breaking changes for end users, we keep the scope names used in this repo the same as before. This required defining them explicitly in metadata.yaml files. We can update them after open-telemetry/opentelemetry-collector#9494 and open-telemetry#21469 are resolver. Taking the opportunity that that the scope names can be explicitly defined, this PR also updates missing scope names for extensions with inconsistent package names e.g.: awsproxy and jaegerremotesampling. It's not a breaking change because the generated meter and tracer are not being used yet.
This change migrates `generate` make target from using deprecated cmd/mdatagen defined in this repo to mdategen defined in core repository. In order to avoid breaking changes for end users, we keep the scope names used in this repo the same as before. This required defining them explicitly in metadata.yaml files. We can update them after open-telemetry/opentelemetry-collector#9494 and open-telemetry#21469 are resolver. Taking the opportunity that that the scope names can be explicitly defined, this PR also updates missing scope names for extensions with inconsistent package names e.g.: awsproxy and jaegerremotesampling. It's not a breaking change because the generated meter and tracer are not being used yet.
This change migrates `generate` make target from using deprecated cmd/mdatagen defined in this repo to mdategen defined in core repository. In order to avoid breaking changes for end users, we keep the scope names used in this repo the same as before. This required defining them explicitly in metadata.yaml files. We can update them after open-telemetry/opentelemetry-collector#9494 and open-telemetry#21469 are resolver. Taking the opportunity that that the scope names can be explicitly defined, this PR also updates missing scope names for extensions with inconsistent package names e.g.: awsproxy and jaegerremotesampling. It's not a breaking change because the generated meter and tracer are not being used yet.
This change migrates `generate` make target from using deprecated cmd/mdatagen defined in this repo to mdategen defined in core repository. In order to avoid breaking changes for end users, we keep the scope names used in this repo the same as before. This required defining them explicitly in metadata.yaml files. We can update them after open-telemetry/opentelemetry-collector#9494 and open-telemetry#21469 are resolver. Taking the opportunity that that the scope names can be explicitly defined, this PR also updates missing scope names for extensions with inconsistent package names e.g.: awsproxy and jaegerremotesampling. It's not a breaking change because the generated meter and tracer are not being used yet.
This change migrates `generate` make target from using deprecated cmd/mdatagen defined in this repo to mdategen defined in core repository. In order to avoid breaking changes for end users, we keep the scope names used in this repo the same as before. This required defining them explicitly in metadata.yaml files. We can update them after open-telemetry/opentelemetry-collector#9494 and open-telemetry#21469 are resolver. Taking the opportunity that that the scope names can be explicitly defined, this PR also updates missing scope names for extensions with inconsistent package names e.g.: awsproxy and jaegerremotesampling. It's not a breaking change because the generated meter and tracer are not being used yet.
This change migrates `generate` make target from using deprecated cmd/mdatagen defined in this repo to mdategen defined in core repository. In order to avoid breaking changes for end users, we keep the scope names used in this repo the same as before. This required defining them explicitly in metadata.yaml files. We can update them after open-telemetry/opentelemetry-collector#9494 and open-telemetry#21469 are resolver. Taking the opportunity that that the scope names can be explicitly defined, this PR also updates missing scope names for extensions with inconsistent package names e.g.: awsproxy and jaegerremotesampling. It's not a breaking change because the generated meter and tracer are not being used yet.
…#31609) This change migrates `generate` make target from using the deprecated `cmd/mdatagen` in this repository to mdategen defined in core repository. To avoid breaking changes for the end users, we keep the scope names used in this repo as before. This required defining them explicitly in metadata.yaml files. We can update them after open-telemetry/opentelemetry-collector#9494 and #21469 are resolved. Taking the opportunity that the scope names can be explicitly defined, this PR also updates missing scope names for extensions with inconsistent package names e.g.: `awsproxy` and `jaegerremotesampling`. It's not a breaking change because the generated meter and tracer are not being used yet. This change unblocks #30495
…open-telemetry#31609) This change migrates `generate` make target from using the deprecated `cmd/mdatagen` in this repository to mdategen defined in core repository. To avoid breaking changes for the end users, we keep the scope names used in this repo as before. This required defining them explicitly in metadata.yaml files. We can update them after open-telemetry/opentelemetry-collector#9494 and open-telemetry#21469 are resolved. Taking the opportunity that the scope names can be explicitly defined, this PR also updates missing scope names for extensions with inconsistent package names e.g.: `awsproxy` and `jaegerremotesampling`. It's not a breaking change because the generated meter and tracer are not being used yet. This change unblocks open-telemetry#30495
…open-telemetry#31609) This change migrates `generate` make target from using the deprecated `cmd/mdatagen` in this repository to mdategen defined in core repository. To avoid breaking changes for the end users, we keep the scope names used in this repo as before. This required defining them explicitly in metadata.yaml files. We can update them after open-telemetry/opentelemetry-collector#9494 and open-telemetry#21469 are resolved. Taking the opportunity that the scope names can be explicitly defined, this PR also updates missing scope names for extensions with inconsistent package names e.g.: `awsproxy` and `jaegerremotesampling`. It's not a breaking change because the generated meter and tracer are not being used yet. This change unblocks open-telemetry#30495
Option 3. makes most sense to me. @dmitryax perhaps add emojis to each option (e.g. 1 🎉 , 2 ❤️ , 3 🚀) to enable voting on your comment. 🙂 |
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.
The text was updated successfully, but these errors were encountered: