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

Configurable AggregationTemporality for agent-for-testing #7902

Closed
ptrdom opened this issue Feb 24, 2023 · 2 comments · Fixed by #7904
Closed

Configurable AggregationTemporality for agent-for-testing #7902

ptrdom opened this issue Feb 24, 2023 · 2 comments · Fixed by #7904
Labels
enhancement New feature or request

Comments

@ptrdom
Copy link
Contributor

ptrdom commented Feb 24, 2023

Is your feature request related to a problem? Please describe.

At Mesmer project we are working on an instrumentation library for Scala applications, and recent change in agent-for-testing for AggregationTemporality from cumulative to delta caused many issues in our tests - they either broke or became flaky. The issue is related to the style of testing we are doing, which is quite typical to Scala codebases - we call async code without clearly knowing when it will finish executing, so after calling it we immediately start polling assertions that check for metrics being produced by said async code for success for a certain amount of time until they succeed or finally fail. This polling, which fetches exported metrics from agent-for-testing, combined with delta temporality makes metric output from the exporter non-deterministic, and this breaks our test assertions. Of course, we could force certain constraints on our tests that would make them comform to behavior of delta temporality, but such approach feels excessively limiting. As a workaround for this, we started building agent-for-testing JAR on our own, with only one line change that reverts temporality back to cumulative.

Describe the solution you'd like

We suggest adding a way to configure temporality for agent-for-testing, possibly by adding a system property which we could pass on application startup.

Describe alternatives you've considered

Only alternatives we see is either refactoring our tests or building agent-for-testing JAR on our own, both seem non-ideal options.

@mateuszrzeszutek
Copy link
Member

Hey @ptrdom ,
Can you contribute a PR that makes that change?

@ptrdom
Copy link
Contributor Author

ptrdom commented Feb 24, 2023

@mateuszrzeszutek Yes, I can do it!

trask pushed a commit that referenced this issue Feb 27, 2023
…er (#7904)

References
#7902.

Not sure if system property name is the most appropriate or if any tests
are required for these changes.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
2 participants