I may not be interpreting your question right, but most of our metrics are counters. It doesn't matter how often they get scraped, or if they get scraped twice, because we only care about the increase. Almost everything we track is aggregated with `increase()`: https://prometheus.io/docs/prometheus/latest/querying/functi...

I'm fond of SQL, but I'd be ok with some other way to express "aggregate my usage into an invoice".

Have you encountered any challenges related to metric aggregation? To the best of my understanding, such issues often stem from inherent inaccuracies due to sampling (https://www.youtube.com/watch?v=67Ulrq6DxwA&t=175s). I'm curious if using a smaller window for metric aggregation and routing these events to a stream aggregator could provide a possible solution.

Not really, but we might've just implicitly designed around it.

Continuously aggregating smaller windows and sending them off is roughly how we send usage to Stripe right now (which, let's be clear, is not working for us AT ALL). We've resigned ourselves to having to do the same thing if we want to use a billing SaaS, but I don't love it.

We’ve built https://GitHub.com/tierrun/tier with a local sidecar that can talk directly to stripe to help simplify situations like this.

A pure SaaS model for billing doesn’t do much more for you at then end of the day other than to apply billing ratings and generate an invoice (which Stripe can and is doing for you already).

I’d love to learn more about what you’d like to do with Stripe and how you are handling entitlements, plan versioning, etc

In the meantime, we looked more into metering and metrics and shared some thoughts here: Usage Data: Auditable or Operational https://news.ycombinator.com/item?id=36616364