-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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
[processor/metricsgeneration] Add option to match metric attributes for calculation operations #35425
Comments
Pinging code owners:
See Adding Labels via Comments if you do not have permissions to add labels yourself. |
I would say that match_attributes should be true by default. match_attributes=false seems like just an incorrect behavior. Maybe we do it via a feature gate instead? If we see users complaining, we can move it to a config option as you suggested, but I wouldn't expect that. |
To be honest, I hadn't thought about using a feature gate when I made this proposal. Using a feature gate implies that somewhere down the line users will only be able to do calculations on metrics when all attributes match between two different metrics, as eventually it would be deleted rendering this functionality permanent. So the question becomes: Is there a valid case where attributes don't matter, or simply don't match up exactly that we have to account for? One edge case here is that in the user may want some attributes to match, but some are irrelevant. For the case I've provided when filing the issue, the match would actually never occur as Would it be worthwhile to make the match logic be the "overlapping attributes match" instead of a strict count requirement as well? Maybe this is an invalid use case that we can ignore? If we did the matching logic this way I could see the possibility of using a feature flag, but I'd be concerned otherwise without more thoroughly vetting possibilities. |
Yes, I actually meant overlapping. We don't need to require that all attributes match, but if two metrics have any attributes with the same keys but different values, they must not participate in the calculation. |
Sounds good, I'll implement using a feature gate. If users present a valid use case for not matching attributes we can revisit accordingly. |
…ity (open-telemetry#35628) #### Description The metrics generation processor's default behavior is to get the first data point's value in the configured `metric2`, and use it for all calculations done with the given rule. As described in the issue, this may yield unexpected or incorrect results. This introduces the feature gate `metricsgeneration.MatchAttributes`. When enabled, calculations will **only** be done on data points whose overlapping attributes match. This means that if both data points have a given attribute, their values must match. #### Link to tracking issue Fixes open-telemetry#35425 #### Testing Added golden tests to ensure expected metrics are generated. Existing tests remain unchanged, showing this functionality did not impact other functions. --------- Co-authored-by: Dmitrii Anoshin <anoshindx@gmail.com>
Component(s)
processor/metricsgeneration
Describe the issue you're reporting
Context
Currently the metrics generation processor simply grabs the first datapoint's value from the metric whose name matches the supplied
metric2
configuration option. This value is then used for generating all new metrics and datapoints.Current implementation's limitation
The limitation here is that attributes are ignored when generating a new metric. An example of when this yields unexpected results is for the host metrics receiver's filesystem scraper. Let's say a user wants to calculate total size of the filesystem in bytes using the two metrics
system.filesystem.usage
andsystem.filesystem.utilization
. This would be done by the following configuration:The problem here is that the attributes of these two metrics may mismatch. One attribute is the filesystem's
mountpoint
. The resulting metric would incorrectly use the first datapoint's value, regardless of mountpoint. This would result in meaningless generated metrics.Proposal
I propose adding a new configuration option,
match_attributes
, abool
that's disabled by default. This would preserve current functionality be default.If this option is enabled, the two datapoints being compared must have identical attributes to create a resulting datapoint in the desired metric. If they're not an identical match, no action will be taken.
Resulting configuration:
The text was updated successfully, but these errors were encountered: