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

[Prometheus Receiver Tests] #6151 #6212: Use pdata directly for validations and accept staleness markers #6219

Merged

Conversation

PaurushGarg
Copy link
Member

Description:

  1. Implement issues 6151 and 6212: Modifies existing Prometheus Receiver tests TestCoreMetricsEndToEnd and helper methods to use pdata directly for validations.
  2. Modifies getValidScrapes method to filter out failed scrapes.
  3. Moved common methods to helper file.
  4. Modifies TestStartTimeMetricRegex, TestExternalLabels, and TestStartTimeMetric to accept staleness markers and to directly use pdata assertion methods.
  5. Currently, TestCoreMetricsEndToEnd fails during assertions for start_timestamp for summary and histogram metrics if staleness markers are emitted. This issue will be posted on repo soon.

Tracking Issue:
Issue numbers #6151 and #6212

@bogdandrutu
Copy link
Member

@Aneurysm9 @dashpole please review

Copy link
Contributor

@dashpole dashpole left a comment

Choose a reason for hiding this comment

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

Nits.

t.attributes.Insert("scheme", pdata.NewAttributeValueString("http"))
}

cfgStr := strings.ReplaceAll(string(cfg), srvPlaceHolder, u.Host)
Copy link
Contributor

Choose a reason for hiding this comment

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

can we just delay the newMockPrometheus() call until after we have u.Host, and avoid this replacement?

Copy link
Member Author

Choose a reason for hiding this comment

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

@dashpole thanks. I have updated the method setupMockPrometheusto avoid string replacement.


func assertMetricPresent(name string, metricTypeExpectations metricTypeComparator,
dataPointExpectations []dataPointExpectation) testExpectation {
return func(t *testing.T, rm *pdata.ResourceMetrics) bool {
Copy link
Contributor

Choose a reason for hiding this comment

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

Instead of returning a bool here, should we just do the assertion in this function? That would make the error messages better, as instead of just getting false, we could get something like "wrong metric type". Then, in doCompare, we just need to invoke the func: e(t, got), and can remove the assert.True(

Copy link
Member Author

@PaurushGarg PaurushGarg Nov 15, 2021

Choose a reason for hiding this comment

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

@dashpole thanks. I have updated the comparator methods to make error messages better and removed the propagation of bools.


func compareTimestamp(timeStamp pdata.Timestamp) numberPointComparator {
return func(t *testing.T, numberDataPoint *pdata.NumberDataPoint) bool {
return assert.Equal(t, timeStamp.String(), numberDataPoint.Timestamp().String(), "Timestamp does not match")
Copy link
Contributor

Choose a reason for hiding this comment

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

Similar comment to the above here. We don't need to return and propagate bools if we are already asserting outcomes.

Copy link
Member Author

Choose a reason for hiding this comment

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

@dashpole thanks. I have updated the comparator methods to make error messages better and removed the propagation of bools.

Copy link
Contributor

@dashpole dashpole left a comment

Choose a reason for hiding this comment

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

lgtm, thanks!

@PaurushGarg
Copy link
Member Author

@bogdandrutu can you please merge this PR.

@alolita alolita added the ready to merge Code review completed; ready to merge by maintainers label Nov 16, 2021
@alolita
Copy link
Member

alolita commented Nov 16, 2021

Hi @bogdandrutu please merge when you have a chance. ty!

@bogdandrutu bogdandrutu merged commit 954d0bb into open-telemetry:main Nov 17, 2021
@PaurushGarg PaurushGarg deleted the prom-receiver-tests-pdata-validations branch November 18, 2021 20:32
@PaurushGarg PaurushGarg changed the title #6151 #6212: Modifies existing Prometheus Receiver Tests to use pdata directly for validations and accept staleness markers [Prometheus Receiver Tests] #6151 #6212: Use pdata directly for validations and accept staleness markers Dec 7, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
ready to merge Code review completed; ready to merge by maintainers
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants