Live data from Hacker News

Grafana Mimir – Horizontally scalable long-term storage for Prometheus

grafana.com

81–90 of 121 posts

Re: Grafana Mimir – Horizontally scalable long-term storage for Prometheus

#81
post #29

Earlier quoted context omitted.

> For $50/mo, you can self host everything easier, cheaper and with more control IMO. Can you give an example as to how you could self host a grafana stack for $50/month? On AWS that buys you 4 cores, 8GB memory and 0 storage, and it's certainly not easier than clicking one button on the grafana website.

There are Helm charts available for all Grafana products so if you already run a Kubernetes cluster and have spare capacity you can just throw it up there. Loki supports shipping logs to GCS/S3 natively and Prometheus can use Cortex (also available as a Helm chart) to do the same. Once you throw Grafana behind SSO and implement a backup cronjob you're done until you reach scale and have to start deploying/scaling ind…

Suggestions for organizing a Helm + Terraform [+ k3s/k3d/MicroShift] provisioning and monitoring git repo with CI for job accounting? (without Ansible & AWX, which I'd create a role with for this too)

- [ ] ENH,BLD: A cookiecutter for this would be cool

Re: Grafana Mimir – Horizontally scalable long-term storage for Prometheus

#82
post #27

So many solutions to the same problem, how does it compare to Victoria Metrics?

VictoriaMetrics co-founder here.

There are many similar features between Mimir and VictoriaMetrics: multi-tenancy, horizontal and vertical scalability, high availability. Features like Graphite and Influx protocols ingestion, Graphite query engine are already supported by VictoriaMetrics. I didn't find references to downsampling in Mimir's docs, but I believe it supports it too.

There are architectural differences. For example, Mimir stores last 2h of data in local filesystem (and mmaps it, I assume) and once in 2h uploads it to the object storage (long-term storage). VictoriaMetrics doesn't support object storage and prefers to use local filesystem for the sake of query speed performance. Both VictoriaMetrics and Mimir can be used as a single binary (Monolithic mode in Mimir's docs) and in cluster mode (Microservices mode in Mimir's docs). The set of cluster components (microservices) is different, though.

It is hard to say something about ingestion and query performance or resource usage so far. While benchmarks from the project owners can be 100% objective, I hope community will perform unbiased tests soon.

Re: Grafana Mimir – Horizontally scalable long-term storage for Prometheus

#83
post #19

More engineering effort going into reinventing things that already exist to upsell people on Grafana cloud. What about focusing on the core value that Grafana provides, dashboards? Grafana 8 alerting is still in my opinion at a beta level. Dashboards as code has made no meaningful progress outside of community attempts in the past 3 years. The documentation for Grafana 8 alerts is still subpar. All of these things as…

Hey there! I work at Grafana on many of the dashboard components. Beyond dashboards as code and alerts where are you feeling the pain?

I can say that a lot of effort is going into improving dashboards in a number of different dimensions and there are definitely some exciting things on the horizon.

Re: Grafana Mimir – Horizontally scalable long-term storage for Prometheus

#84
post #78
post #32

Earlier quoted context omitted.

Given Victoria Metrics is the only solution I've seen to make data comparing it to other systems easily accessible as part of official documentation, it's the only one I pay attention to. I knew from reading the docs what VM excelled at and areas it was weak in, long before I ever ran it (and expectations from running it matched the documentation). I hate aspirational marketing-saturated campaigns for deep tech proje…

Cortex, Thanos and Mimir all support "remote-read" protocol (documented in Prometheus: https://prometheus.io/docs/prometheus/latest/storage/#remote... ), so external systems (eg Prometheus) can read data from them easily.

It would be great if you could provide a few practical examples for "Prometheus remote-read" protocol given its' restrictions [1].

[1] https://github.com/prometheus/prometheus/issues/4456

Re: Grafana Mimir – Horizontally scalable long-term storage for Prometheus

#85
post #49
post #8

Grafana Labs needs to make a convincing comparison chart of some kind between Mimir, Thanos, and Cortex. Thanos and Cortex are both mature projects and are both CNCF Incubating projects. Why would anyone switch to a new prometheus long-term storage solution from those? *EDIT* : I see from another reply there is a basic comparison to Cortex here: https://grafana.com/blog/2022/03/30/announcing-grafana-mimir... To the M…

It looks like this is a fork of Cortex driven by the maintainers employed by Grafana Labs, done so they can change the license to one that will prevent cloud providers like Amazon from offering it without contributing changes back. This is interesting, since Amazon offers both hosted Grafana and Cortex today. I was under the impression Amazon and Grafana Labs were successfully collaborating (unlike e.g. AWS and Elast…

Does AWS provide managed Cortex? Is that just a part of the AWS managed prometheus thing?

Re: Grafana Mimir – Horizontally scalable long-term storage for Prometheus

#86

Earlier quoted context omitted.

Hey! Promscale PM here :) Promscale is the open source observability backend for metrics and traces powered by SQL. Whereas Mimir/Cortex is designed only for metrics. Key differences: 1. Promscale is light in architecture as all you need is Promscale connector + TimescaleDB to store and analyse metrics, traces where as Cortex comes with highly scalable micro-services architecture this requires deploying 10's of servi…

Thanks... how do we do reporting/dashboards/alerts with Promscale? Also, any performance benchmarks?

Promscale supports reporting/ingestion of data using Prometheus remote-write for metrics, OTLP (OpenTelemetry Line Protocol) for traces.

Dashboards you can use Promscale as Prometheus datasource for PromQL based querying, visualising, as Jaeger datasource for querying, visualising traces and as PostgreSQL datasource to query both metrics and traces using SQL. If you are interested in visualising data using SQL, we recently published a blog on visualising traces using SQL (https://www.timescale.com/blog/learn-opentelemetry-tracing-w...)

Alerts needs to be configured on the Prometheus end, Promscale doesn't support alerting at the moment. But expect the native alerting from Promscale in the upcoming releases.

We have internally tested Promscale at 1Mil samples/sec, here is the resource recommendation guide for Promscale https://docs.timescale.com/promscale/latest/installation/rec...

If you are interested in evaluating, setting up Promscale reach out to us in Timescale community slack(http://slack.timescale.com/) in #promscale channel.

Re: Grafana Mimir – Horizontally scalable long-term storage for Prometheus

#87
post #8

Grafana Labs needs to make a convincing comparison chart of some kind between Mimir, Thanos, and Cortex. Thanos and Cortex are both mature projects and are both CNCF Incubating projects. Why would anyone switch to a new prometheus long-term storage solution from those? *EDIT* : I see from another reply there is a basic comparison to Cortex here: https://grafana.com/blog/2022/03/30/announcing-grafana-mimir... To the M…

You're forgetting VictoriaMetrics that's presumably the best choice for Prometheus long term storage.

Such a solid solution exists and yet another competitor? Not sure why they didn't just buy VictoriaMetrics and possibly rebrand it.

Re: Grafana Mimir – Horizontally scalable long-term storage for Prometheus

#88
post #8

Grafana Labs needs to make a convincing comparison chart of some kind between Mimir, Thanos, and Cortex. Thanos and Cortex are both mature projects and are both CNCF Incubating projects. Why would anyone switch to a new prometheus long-term storage solution from those? *EDIT* : I see from another reply there is a basic comparison to Cortex here: https://grafana.com/blog/2022/03/30/announcing-grafana-mimir... To the M…

> Cortex is used by some of the world’s largest cloud providers and ISVs, who are able to offer Cortex at a lower cost because they do not invest the same amount in developing the project.

> ...

> All CNCF projects must be Apache 2.0-licensed. This restriction also prevents us from contributing our improvements back to Cortex.

I read this as "Amazon has destroyed the CNCF by not playing nice"

Re: Grafana Mimir – Horizontally scalable long-term storage for Prometheus

#89
post #8

Grafana Labs needs to make a convincing comparison chart of some kind between Mimir, Thanos, and Cortex. Thanos and Cortex are both mature projects and are both CNCF Incubating projects. Why would anyone switch to a new prometheus long-term storage solution from those? *EDIT* : I see from another reply there is a basic comparison to Cortex here: https://grafana.com/blog/2022/03/30/announcing-grafana-mimir... To the M…

> Cortex is used by some of the world’s largest cloud providers and ISVs, who are able to offer Cortex at a lower cost because they do not invest the same amount in developing the project. > ... > All CNCF projects must be Apache 2.0-licensed. This restriction also prevents us from contributing our improvements back to Cortex. I read this as "Amazon has destroyed the CNCF by not playing nice"

Holy crap I did not know CNCF discriminated against copyleft software.

This really discredits the Linux Foundation as an institution.

Re: Grafana Mimir – Horizontally scalable long-term storage for Prometheus

#90

Earlier quoted context omitted.

How did you define alarms as code in a practical way before v8? and after?

Hi, I work on Grafana Alerting. Provisioning of alert rules (and other objects used for alerting) will be possible using a new API in Grafana 8.5 and we will update the Grafana Terraform provider right after to take advantage of this new API.

Great to hear! We are looking into jsonnet based approach but having an explicit and granular API and a Terraform provider would be miles and miles better. Thanks!
Post reply on HN