[WFLY-22046] Support fine-grained/individual metric filtering#845
[WFLY-22046] Support fine-grained/individual metric filtering#845jasondlee wants to merge 1 commit into
Conversation
jasondlee
changed the title
github-actions
Bot
added
stability-level/default
github-actions
Bot
added
stability-level/default
github-actions
Bot
added
stability-level/default
github-actions
Bot
added
stability-level/default
github-actions
Bot
added
stability-level/default
github-actions
Bot
added
stability-level/default
github-actions
Bot
added
stability-level/community
| It may turn out, however, that this flexibility makes for an awkward model/schema that hinders more than helps. We should be sensitive to this as the design matures and be prepared to pivot. | ||
| ==== | ||
|
|
||
| If an "accept" filter and a "reject" filter overlap, the accept filter will win, since the inclusion of the meter was explicitly configured. |
There was a problem hiding this comment.
Is this worth it? It adds quite a bit of complexity and can be unintuitive.
In a different context I've done quite a bit of work around filters using the JEP 290[1] mechanism, which for the class filtering aspect uses accept/reject semantics, applying a list of filter expressions in the order they are provided. As soon as a given class matches, the accept or reject applies and processing ends. The user is responsible for providing a list that results in the desired behavior. Reading the list the user can readily intuit what will happen using step by step reasoning.
See java.io.ObjectInputFilter.Config.Global.checkInput
There was a problem hiding this comment.
Based on my preliminary experiments, if the accept filters are registered before the reject, then Micrometer just does the right thing. I think it will be a bit more manual on the OpenTelemetry side (via their view (?) API), but I think it should be pretty straightforward all around.
| ** Dropping certain tags | ||
| ** Replacing tag values | ||
| ** Limiting the number of tags on a meter | ||
| * A unified configuration for both Micrometer and OpenTelemetry, while interesting, given their similarities, is not in scope. |
There was a problem hiding this comment.
Please clarify what "A unified configuration" means.
Reading the above it sounds like the applicability to OpenTelemetry is not nailed down, which is ok at this stage. But it also sounds like there will be thinking about consistency (good!) and conceptually it seems like things can be consistent. So as this progresses if we end up being consistent, this non-requirement will be confusing unless it's explained.
There was a problem hiding this comment.
I've expanded the wording here. I hope that adequately addresses your concerns.
github-actions
Bot
added
stability-level/community
Create proposal document
2 participants
https://redhat.atlassian.net/browse/WFLY-22046
Create proposal document
Resolves: #844