Tracking metrics over time with metrics-util?

[Marwes]

I was looking at updating the metrics dependency in https://github.com/ramn/metrics_cloudwatch and since the API has changed to allow for more performant metrics tracking I figured I'd try to use the types that metrics_util provides. Unfortunately I am either confused about how to use them, or they aren't quite compatible with how cloudwatch metrics works.

Basically I want to group metrics collected in either minute or second intervals and send them to cloudwatch that way, but when I look at how metrics_util is used for the prometheus exporter it looks like it only tracks metrics from the start of the program and doesn't take time into account at all? I am not familiar with prometheus but I assume that is handled by the consumer of the metric instead(?).

I could probably build a bespoke solution for cloudwatch that perhaps uses some bits from metrics_util but I figured I could ask if I am misunderstanding something or if it would be something that could be added to metrics_util.

[tobz]

You're generally correct that nothing in metrics-util really cares about when a metric was submitted, at least in terms of how it's stored / aggregated. Exporters are generally either exposing the absolute value of each metric in the registry (Prometheus), or they're calculating the delta of each metric, perhaps by consuming the total change, and so on.

It certainly shouldn't be a problem to have your exporter code iterate over the registry to do that aggregation, although you obviously pay a small cost in storage if you're aggregating at a granularity that is higher than how often you report the metrics, since you can't just report as you iterate.