Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Moving a large-scale metrics pipeline from StatsD to OpenTelemetry / Prometheus

medium.com

Post reply on HN
Print view View original

11–20 of 26 posts

Re: Moving a large-scale metrics pipeline from StatsD to OpenTelemetry / Prometheus

#11

Post by porridgeraisin »

pahae wrote: post #9
codeduck wrote: post #6

> given Prometheus’s widespread adoption and proven reliability in diverse environments. I have used Prometheus a lot. Reliable is not a word I would associate with it.

I set up a fairly large Prom-based architecture which I later on migrated to VictoriaMetrics (VM) so I think I can chime in here. Both Prom and VM are exceptionally stable in my opinion, even on _very_ large scales. There were times when I had a single (Prom, later VM) and not-overly-large instances scrape 2Mio samples/s without any issues. In addition to fairly spiky query loads. However, if something does go wrong,…

Yeah, at previous work we used both as well. The transition from prom to vm was "ongoing" and from the time I joined to the time I left we did parallel writes to both. Never faced issues with either. If I remember correctly, we wrote from services to a kafka queue first, and then a consumer took that and pushed it to (both) the metrics endpoint(s).

Re: Moving a large-scale metrics pipeline from StatsD to OpenTelemetry / Prometheus

#12

Post by blueybingo »

the zero injection fix for sparse counters is the most underrated part of this writeup -- injecting a synthetic zero on first flush to anchor the cumulative baseline is actaully a pretty elegant solution to a problem that bites almost every team migrating from delta-based systems to prometheus, and the fact that they centralized it in the aggregation tier rather than pushing the fix to every instrumentation callsite is exactly the right call.

Re: Moving a large-scale metrics pipeline from StatsD to OpenTelemetry / Prometheus

#13

Post by zbentley »

> Initially, we anticipated that the edge case would have minimal impact, given Prometheus’s widespread adoption and proven reliability in diverse environments. However, as we migrated more users, we started seeing this issue more frequently, and it stalled migration.

That's a very professional way of saying "Wait, everyone just lives with this? What the fuck?!"

Many such cases in the Prometheus ecosystem.

Re: Moving a large-scale metrics pipeline from StatsD to OpenTelemetry / Prometheus

#16

Post by igor47 »

awoimbee wrote: post #4

Directly emitting metrics using OTLP instead of having the OTel receiver scrape the metrics endpoint is interesting. I never made that move because the Prometheus metrics endpoint works and is so simple, and it's what most projects (eg kubernetes) use.

A long time ago, I introduced dogstatsd at Airbnb. We had already been using vanilla statsd (with no tag support -- cardinality lived in the metric name!) and this was a low cost migration. More than a decade later, I'm assuming it was difficult to track down and refactor all the places that statsd calls were emitted and using OTLP was an easier route. This is a great example of how technical decisions compound over time.

Re: Moving a large-scale metrics pipeline from StatsD to OpenTelemetry / Prometheus

#17

Post by camel_gopher »

dig1 wrote: post #3

> The irony is that this may be a $0 revenue user for Grafana Labs. Why is that ironic? Since Mimir is open-source, $0 revenue users are expected. AFAIK, Grafana Labs relies heavily on go, typescript, and linux, without necessarily being their top financial contributor. They could have kept Mimir proprietary like Splunk, but whether that would have attracted the same level of adoption or community contribution is ano…

Grafana knows their open source products are eating into revenue. Expect corresponding strategy to offset that.

Re: Moving a large-scale metrics pipeline from StatsD to OpenTelemetry / Prometheus

#20

Post by skrtskrt »

camel_gopher wrote: post #17
dig1 wrote: post #3

> The irony is that this may be a $0 revenue user for Grafana Labs. Why is that ironic? Since Mimir is open-source, $0 revenue users are expected. AFAIK, Grafana Labs relies heavily on go, typescript, and linux, without necessarily being their top financial contributor. They could have kept Mimir proprietary like Splunk, but whether that would have attracted the same level of adoption or community contribution is ano…

Grafana knows their open source products are eating into revenue. Expect corresponding strategy to offset that.

It already exists, it’s their Bring Your Own Cloud offering.

It’s to retain customers that grew big enough on Grafana Cloud to justify having their own in-house team run the tools instead. So Grafana offers them a pricing where the Grafana engineers operate the platform within the customer’s cloud account. Very large customers get to keep not having to operate and build/hire for the expertise, and save some money.

Sure some companies are big enough to make it worth it and still want to run their own OSS observability stack, but it’s generally not going to be popular with executive decision-makers, so it likely will remain rare. And if they do run it, Grafana still benefits from their contributions to AGPL code.

On the low-spending end, OSS users not buying cloud would not really be a serious revenue concern. They just don’t spend enough. You use cloud if tou have super broad product usage, so you don’t have to run and maintain Grafana, Mimir, Loki, Tempo, Pyroscope, k6, etc. all yourself. If you don’t want or need all that, you run Loki+Grafana yourself and enjoy.

Post reply on HN