Skip to content
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

Merged

Conversation

hossain-rayhan
Copy link
Contributor

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.

@hossain-rayhan
Copy link
Contributor Author

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)
Copy link
Contributor

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 (?).

Copy link
Contributor Author

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.

Copy link
Member

@a-feld a-feld Jul 20, 2021

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.

Copy link
Member

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?

@hossain-rayhan
Copy link
Contributor Author

Hi @Aneurysm9 , thanks for your valuable comments. I pushed an update to address your comment. Would you please have another look.

@hossain-rayhan
Copy link
Contributor Author

@bogdandrutu would you please take a look on this?

Copy link
Member

@a-feld a-feld left a 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 {
Copy link
Member

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?

Copy link
Contributor Author

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?

Copy link
Member

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?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

return true
})

result, _ := ctdp.deltaCalculator.Calculate(metric.Name(), labelMap, fromDataPoint.Value(), fromDataPoint.Timestamp().AsTime())
Copy link
Member

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?

Copy link
Contributor Author

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.

Copy link
Member

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.

Copy link
Contributor Author

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)
Copy link
Member

@a-feld a-feld Jul 20, 2021

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.

Copy link
Member

@a-feld a-feld left a 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. ✅

@hossain-rayhan
Copy link
Contributor Author

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 awscontainerinsightsreceiver and awsemfexporter to make sure they are working fine.

Expecting your review.

@a-feld
Copy link
Member

a-feld commented Jul 27, 2021

@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 😄

@hossain-rayhan
Copy link
Contributor Author

@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.

@a-feld
Copy link
Member

a-feld commented Jul 27, 2021

Agreed - I'm anxious to continue development on this processor, but waiting on this PR to merge 😄

@hossain-rayhan
Copy link
Contributor Author

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.

@hossain-rayhan hossain-rayhan force-pushed the cummulative_to_delta_logic branch from a309bd6 to fc32228 Compare July 28, 2021 18:30
@bogdandrutu
Copy link
Member

Needs rebase

hossain-rayhan and others added 8 commits July 28, 2021 18:52
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>
@hossain-rayhan hossain-rayhan force-pushed the cummulative_to_delta_logic branch from fc32228 to 678f7ac Compare July 29, 2021 02:49
@hossain-rayhan
Copy link
Contributor Author

Hi @bogdandrutu , I rebased it. Please merge this one! Thanks.

@hossain-rayhan
Copy link
Contributor Author

Hi @bogdandrutu , I rebased it. Please merge this one! Thanks.

A friendly ping @bogdandrutu

@hossain-rayhan
Copy link
Contributor Author

Hi @bogdandrutu, Can we get this merged please?

@hossain-rayhan
Copy link
Contributor Author

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?

@bogdandrutu bogdandrutu merged commit 41a7790 into open-telemetry:main Aug 3, 2021
@hossain-rayhan
Copy link
Contributor Author

Thanks @bogdandrutu . Really appreciate your time. @a-feld can you plese create your PR whenever you are ready? Thanks.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants