-
Notifications
You must be signed in to change notification settings - Fork 43
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
Support for 2 semconv registries #627
Conversation
# Conflicts: # Cargo.lock # crates/weaver_cache/Cargo.toml
# Conflicts: # Cargo.lock # crates/weaver_cache/Cargo.toml
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #627 +/- ##
=======================================
- Coverage 74.2% 73.6% -0.6%
=======================================
Files 57 57
Lines 4578 4612 +34
=======================================
- Hits 3399 3398 -1
- Misses 1179 1214 +35 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
…a structure combining registry_id and path.
This is really good. I tried this on my own company registry where we purposefully want to add attributes into the otel defined namespaces. I got a few of these:
Perhaps we need a merge mode or maybe just group-id naming guidance? Or perhaps a mode where all groups are prepended with the |
Another usability thing I ran into, not introduced in this PR though, is the discovery of the Regardless of the above, if the manifest is NOT found it would be useful to have a log line stating it has not been found to help debug. Perhaps I misspelled it or used |
I suggest we discuss this during our next SIG meeting. |
@jerbly Could you create a GitHub issue to add the warning to improve user experience? Regarding the recursive search for the manifest file, I’m less sure about it, as it raises the problem of potentially finding multiple manifests and deciding how to handle that. For now, I think it’s best to keep it simple until we have a clear need for that type of functionality. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks good to go now with the default change and extra config.
/// Garbage collect all the signals and attributes not defined or referenced in the | ||
/// current registry, i.e. telemetry objects only defined in a dependency and not | ||
/// referenced in the current registry. | ||
fn gc_unreferenced_objects(manifest: Option<&RegistryManifest>, registry: &mut Registry) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"garbage collect" :)
I like keeping this concise, easy to read/maintain.
This PR closes #604.
With this PR, it’s now possible to create a custom SemConv registry that depends on another registry (e.g., the official OTEL SemConv registry). Currently, only a single-level dependency is supported, meaning only two registries can be merged and resolved automatically by Weaver. This PR is an initial step toward full support for multiple registries without these limitations.
For example, let’s imagine a custom registry named
acme
referencing the OTEL registry. The followingregistry_manifest.yaml
file should be defined in the directory containing the custom acme registry.The
registry_path
can be any valid registry path already supported by Weaver.The definition of the custom registry
acme
is defined in the following yaml file:The
error.type
attribute is not defined locally, so Weaver will resolve it using the imported registry.