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

Allow instruments to be collected on different intervals #2120

Closed
jack-berg opened this issue Nov 12, 2021 · 2 comments
Closed

Allow instruments to be collected on different intervals #2120

jack-berg opened this issue Nov 12, 2021 · 2 comments
Assignees
Labels
area:sdk Related to the SDK spec:metrics Related to the specification/metrics directory

Comments

@jack-berg
Copy link
Member

A coworker of mine suggested that there may be use cases in which it would be valuable for different metric instruments (or views) to be exported on different intervals. Suppose you were interested in getting JVM runtime metrics every 10 seconds, but a 60 second interval was sufficient for potentially higher cardinality metrics capturing http server usage. This example is a bit contrived, but should illustrate the point.

I thought about how you would do this in the current Java metrics SDK. You'd have to define 2 periodic metric readers, each configured with a "filtering exporter". A filtering exporter would filters metric data according to some criteria before delegating to another exporter, eg OTLP. One periodic metric reader would be setup with a 10 second interval, and filter to only include JVM runtime metrics. The other periodic metric reader would be setup with a 60 second interval, and filter to include all metrics except JVM runtime metrics.

I know that because metrics support temporal reaggregation, that you could export all metrics in a 10 second interval, and define a processor in the collector to reaagregate the non-JVM runtime metrics to achieve the same affect. But that solution is arguably less convenient. Also, it requires that applications produce metric streams with window sizes dictated by finest granularity required by any instrument, and therefore applications to export more data than would be needed otherwise.

Has this type of use case been discussed?

Is there any appetite to provide more control in periodic metric reader for controlling which metrics / views it reads?

@jack-berg jack-berg added the spec:metrics Related to the specification/metrics directory label Nov 12, 2021
@reyang
Copy link
Member

reyang commented Nov 15, 2021

This seems to be a dup of #1432.

@reyang reyang added this to the Metrics Future Release milestone Nov 15, 2021
@reyang reyang added the area:sdk Related to the SDK label Nov 15, 2021
@jack-berg
Copy link
Member Author

Thanks @reyang. Thought that might be the case. Closing.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area:sdk Related to the SDK spec:metrics Related to the specification/metrics directory
Projects
None yet
Development

No branches or pull requests

3 participants