-
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
delta-to-cumulative-processor: initial #28910
delta-to-cumulative-processor: initial #28910
Conversation
Please open an issue for this new component. New components require sponsors. Please read CONTRIBUTING.md for more information. |
@0x006EA1E5, thanks for the PR. I have this on my list to give you some initial feedback, but as mentioned above, you'll need to formerly propose the component before we can proceed with anything more than that. I will sponsor the component. |
- `identity_mode`: How to create a metrics identity signature. Options are | ||
- `SCOPE_AND_RESOURCE_ATTRIBUTES`: Use both the metrics `scope` and `resource` attributes | ||
- `SCOPE_ATTRIBUTES_ONLY`: Use only the metrics `scope` attributes | ||
- n.b., if metrics will be exported wit the `prometheus` or `prometheus remote write` exporters, this should be set to work will with the exporter's `resource_to_telemetry_conversion` configuration |
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.
I'm having a hard time grappling with this part of the component. Typically, I would expect that we aggregate without changing anything at all about the resource or scope. i.e. We always use both the resource and scope attributes to uniquely identify the set of timeseries we're aggregating.
// resourceAttrs contain the resource attributes. They are used to output instance and job labels. | ||
resourceAttrs pcommon.Map |
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.
Related to my previous comment, I would expect we maintain both resource and scope attributes separately.
for i := 0; i < dps.Len(); i++ { | ||
ip := dps.At(i) | ||
|
||
signature := timeseriesSignature(a.identifyMode, il.Name(), metric, ip.Attributes(), resourceAttrs) |
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.
Rather than create a signature, would it make sense to define a hierarchical data type which mirrors the result we will emit? A little oversimplified, but roughly:
type timeseriesManager struct {
resources map[pcommon.Map] resource // resource attributes => resource
}
type resource struct {
lastUpdated time.Time
attributes pcommon.Map
scopes map[pcommon.Map]scope // scope attributes => scope
}
type scope struct {
lastUpdated time.Time
attributes pcommon.Map
name string
metrics map[string]metric // metric name => metric
}
type metric struct {
lastUpdated time.Time
pmetric.Metric // stored as reference so we can recreate the metric as cumulative
timeseries map[pcommon.Map]timeseries // data point attributes => timeseries
}
type timeseries {
lastUpdated time.Time
// accumulated data points
}
This PR was marked stale due to lack of activity. It will be closed in 14 days. |
I may not be aware of all recent discussions around the cumulativetodelta processor (which this new one seems to be very closely related to), but there was this comment a while back:
|
This PR was marked stale due to lack of activity. It will be closed in 14 days. |
Closed as inactive. Feel free to reopen if this PR is still being worked on. |
Description:
Added initial draft of Delta to Cumulative Processor
Allows converting delta metrics to cumulative metrics
Link to tracking Issue: TODO
Testing: TODO
Documentation: TODO