You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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?
The text was updated successfully, but these errors were encountered:
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?
The text was updated successfully, but these errors were encountered: