Define resource.detectors.attributes.included/excluded #64
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…te keys provided by detectors
jack-berg
commented
Jan 8, 2024
examples/kitchen-sink.yaml
Outdated
| # Configure exact match disabled attribute key. | ||
| - process.command_args | ||
| # Configure wildcard match disabled attribute key(s). | ||
| - process.* |
There was a problem hiding this comment.
Discussed in the 1/8/24 configuration SIG:
- Decided to move this property up to the top level instead of nesting under detectors. This solves any ambiguity issues about whether attributes like
telemetry.sdk.*are included in the set, since those may be part of the default resource or provided by resource detectors. - Discussed whether wildcard syntax is sufficient. Opened Default config file template that incorporates standard env vars #55 to discuss. I propose we stick with wildcard syntax for now and use user feedback to determine if full regex support is needed before a 1.x release.
- Discussed whether it would also be useful to match on resource values. Answer is probably? Could add
disabled_attribute_valuesin a separate PR.
jack-berg
changed the title
codeboten
reviewed
Apr 29, 2024
examples/kitchen-sink.yaml
Outdated
| # Attribute keys are evaluated to match disabled_attribute_keys in the following manner: | ||
| # * If the value of the attribute key exactly matches. | ||
| # * If the value of the attribute key matches the wildcard pattern, where '?' matches any single character and '*' matches any number of characters including none. | ||
| disabled_attribute_keys: |
There was a problem hiding this comment.
Maybe this could be an included/excluded list under attributes.
There was a problem hiding this comment.
Scratch that. .resource.attributes is currently a map with key values which directly reflect the resource attributes. Its odd to have special-case included and excluded keys which have values following different rules.
Lets nest included and excluded under something which indicates that we're referring to attributes from resource detectors. Maybe something like:
resource:
detectors:
attributes:
included:
- foo*
- b?r
excluded:
- baz
Nesting included and excluded under .resource.detectors.attributes because:
- We might want to configure other things related to resource detectors
- If
includedandexcludedare directly under.resource.detectors, then its not clear that we're including / excluding attributes vs. detectors themselves
There was a problem hiding this comment.
Pushed a commit which reflect this. ^^
codeboten
changed the title
…y-configuration into resource-detectors
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The specification defines the concept of resource detectors, which automatically provide resource information based on the environment.
We need to give the user the ability to disable these keys, as they can contain sensitive information (i.e.
process.command_lineoften contains secrets for java) or just not be valuable to the user.This PR introduces
resource.disabled_attribute_keys, an array of strings defining attribute keys from resource detectors that should be disabled. Entries in the array can exactly match an attribute key, or can use a basic pattern matching syntax (inherited from metrics view instrument selection criteria) supporting?single character any match, and*any number of character any match including none.The effect is that
disabled_attribute_keysacts as a disallow list. We may wish to add an allow list variant in the future, but disabling keys is much more common so let's start there.