RFC: Metric Builder Wildcard Name Matching #13358
Conversation
braydonk
requested review from
codeboten,
bogdandrutu,
dmitryax,
mx-psi and
a team
as code owners
| The grammar is an extension of the OTel name grammar. In plain english, the OTel name gramma is an OTel identifier (characters with underscores) optionally followed by a `.` and another OTel identifier. With the wildcard matching, the grammar is similar, except instead of a name you can optionally have one of two things: | ||
|
|
||
| * A wildcard `*` character, which matches anything in a group. If it is the final group, it will match any number of subsequent groups. | ||
| * A multimatch `{x,y,z,...}` which will match anything specified within it |
There was a problem hiding this comment.
When last discussed, this part of the grammar was in contention. Removing it may simplify the implementation a bit.
|
|
||
| ### What and Why | ||
|
|
||
| The following is a specification for OpenTelemetry Wildcard Name Matching grammar that could be added to the generated `metadata` packages from `mdatagen`. This grammar will facilitate the use of wildcards in metric and resource attribute configurations to enabling/disabling metrics/resource attributes in a more concise way, allowing a configuration like: |
There was a problem hiding this comment.
Arguably this could be added as a package in the collector repo that the templates import.
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #13358 +/- ##
==========================================
- Coverage 91.54% 91.53% -0.02%
==========================================
Files 526 526
Lines 29434 29434
==========================================
- Hits 26946 26942 -4
- Misses 1962 1965 +3
- Partials 526 527 +1 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
|
Awesome proposal! |
|
@bogdan-st Good idea. This would be technically feasible, and I'll add a section to the RFC that explains how it would look. One thing I'm unsure of is how to actually expose it though. Perhaps as part of the Metric Builder's config validation somehow so that when the Collector config validation is called the dry-run output can be sent to stderr? That part I'm not sure about. |
|
I support this proposal. This will allow us to have a generic way for grouping enabled/disabled metrics, sth that today we do through specific settings (i.e. metric_groups) in components like kubeletstatsreceiver. What this proposal suggests is way more flexible. +1 on providing a way to output what the actual configuration will be after is evaluated. |
Description
This PR is an RFC to allow wildcard name matching in
mdatagenmetric/resource attribute builder configs. This is needed because of the high number of metrics and resource attributes that need to be controlled in many receivers, making configs extremely dense, hard to follow, and more prone to breakages as metrics/attributes themselves get added or changed.Link to tracking issue
Originally discussed in #10074
Implementation in #10065. PR is quite outdated now, but the generated matching library is the meat of it.