-
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
cumulative_to_delta_processor: Add Cumulative to Delta Conversion logic #4216
cumulative_to_delta_processor: Add Cumulative to Delta Conversion logic #4216
Conversation
Hi @anuraaga and @Aneurysm9, would you please help with the review. CC: @jmacd and @bogdandrutu some early feedback is highly appreciated. |
result := delta{value: val.(float64), prevTimestamp: timestamp} | ||
|
||
if prev != nil { | ||
deltaValue := val.(float64) - prev.RawValue.(float64) |
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 had to look through awsmetrics
to see what the calculator does here. This looks good to me, although you might consider for monotonic cumulatives to insert a "Reset heuristic" the way Prometheus has. The current logic looks like it will deliver a negative delta when a cumulative value resets, and you might want to interpret that as a zero depending on your knowledge.
See https://github.com/lightstep/opentelemetry-prometheus-sidecar/blob/main/retrieval/series_cache.go#L331 for a similar handler used to convert Prometheus cumulatives w/o a start time to cumulatives with a start time. If you pass through similar logic first, you won't see the negative delta (for monotonic cumulatives).
Approving this PR because the implied logic fix probably belongs in awsmetrics
(?).
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.
Thanks Josh. Will check and update here.
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.
Deleting this comment On further review, it looks like the initial value is reported.
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.
@jmacd in order to determine a reset we should initially use "startTime" and if that is missing (0), fallback to the prometheus way to detect reset?
Hi @Aneurysm9 , thanks for your valuable comments. I pushed an update to address your comment. Would you please have another look. |
@bogdandrutu would you please take a look on this? |
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 have a few questions about this logic, after discussion I can re-review.
fromDataPoint := dataPoints.At(l) | ||
labelMap := make(map[string]string) | ||
|
||
fromDataPoint.LabelsMap().Range(func(k string, v string) bool { |
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.
Should LabelsMap
be sorted here? Do we consider labels that arrive in a different order to be equivalent?
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 am not sure. Is there any such possibility?
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.
For sure they can come in any order since a "Map" (LabelMap) does not guarantee ordering. But you add them to another Map so there should be no problem. Correct?
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.
Hi @a-feld, I think we are already sorting them in the awsmetrics
calculator.
return true | ||
}) | ||
|
||
result, _ := ctdp.deltaCalculator.Calculate(metric.Name(), labelMap, fromDataPoint.Value(), fromDataPoint.Timestamp().AsTime()) |
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.
Since the delta calculator operates only on metric name and label map, what happens if the same metricName + labelMap is sent across resources / instrumentation libraries? Do metrics compute deltas without taking into account the resource / instrumentation library?
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.
Good point. For my use case, I don't think there would be a scenario where the metric name and labels cannot uniquly identify a metric.
However, if thats a requirement, we can update the awsmetrics
calculator sending a different PR and update this processor accordingly.
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.
We cannot implement "logic" for our use-cases. I think this problem needs to be taken care of.
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.
Hi @bogdandrutu , I pushed an update where we use Rsource attributes and Metric labels together to create the mapping.
As @a-feld mentioned, we had a meeting over zoom. They had couple of more requirements. They will send a follow-up PR after this to address those needs.
result := delta{value: val.(float64), prevTimestamp: timestamp} | ||
|
||
if prev != nil { | ||
deltaValue := val.(float64) - prev.RawValue.(float64) |
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.
Deleting this comment On further review, it looks like the initial value is reported.
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.
Rayhan and I had a conversation over zoom. I think New Relic has a couple of additional requirements:
- Monotonic counter reset detection
- Default include to all cumulative metrics. Our platform doesn't currently accept cumulative metrics natively; therefore, the user story we desire is for default inclusion.
We will be submitting a follow on PR containing many of the concepts from this implementation https://github.com/a-feld/cumulativetodeltaprocessor
For now, it would be great to push this forward. Approving on behalf on New Relic. ✅
CC: @mxiamxia and @pxaws. We used the AWS MetricsCalculator here. We got a requirement to create the mapping key using Resource Attributes and Metric labels together. I had to make some changes in the MetricCalculator package and in some other from where you called the Calculate functions. I ran the unit tests in Expecting your review. |
@hossain-rayhan Just a reminder, there's an implementation here that I plan to push forward which doesn't require modifications to the AWS MetricsCalculator package 😄 |
Hi @a-feld, I agree. Same time, I think adding the Resource Attributes makes the key strong to uniquely identify a metric. And I guess @bogdandrutu was asking for this anyway. If @bogdandrutu is OK to merge without this I can revert it. @bogdandrutu as this is working fine for primary use cases, can we get this PR merged and address other needs in a separate PR (which @a-feld will send)? Waiting for your opinion. |
Agreed - I'm anxious to continue development on this processor, but waiting on this PR to merge 😄 |
Reverted the last commit for utilizing Resurce Attributes to map the key as we decided to put another PR on top of this with other major changes. I believe, it would make the review process faster. This will still support the primary use case. |
a309bd6
to
fc32228
Compare
Needs rebase |
Signed-off-by: Rayhan Hossain <hossain.rayhan@outlook.com>
Signed-off-by: Rayhan Hossain <hossain.rayhan@outlook.com>
Signed-off-by: Rayhan Hossain <hossain.rayhan@outlook.com>
Signed-off-by: Rayhan Hossain <hossain.rayhan@outlook.com>
Signed-off-by: Rayhan Hossain <hossain.rayhan@outlook.com>
Co-authored-by: Anthony Mirabella <a9@aneurysm9.com>
This reverts commit 12d63cc31ea12dd880526b3ea2a67d2eda481487.
Signed-off-by: Rayhan Hossain <hossain.rayhan@outlook.com>
fc32228
to
678f7ac
Compare
Hi @bogdandrutu , I rebased it. Please merge this one! Thanks. |
A friendly ping @bogdandrutu |
Hi @bogdandrutu, Can we get this merged please? |
Hi @bogdandrutu, please I need you opnion on this. Can you please take a look. As per our discussion on last Wednesday's SIG meeting, we (@a-feld ) will send another PR on top of this. Please say somthing. Can we get this merged? |
Thanks @bogdandrutu . Really appreciate your time. @a-feld can you plese create your PR whenever you are ready? Thanks. |
Signed-off-by: Rayhan Hossain hossain.rayhan@outlook.com
Description:
This PR adds the logic for converting cumulative to delta SUM datapoints.
Link to tracking Issue: #3751
Testing:
Unit test added. Will add more to improve coverage.
Documentation: README updated.