mimir VS loki

It consists of 6 separate components to run, plus 4 additional optional components [1]. And I don't even count 5 additional caches [2]. How is that "simple and easy"?

[1] https://grafana.com/docs/mimir/latest/references/architectur...

[2] https://github.com/grafana/mimir/blob/9a52522a05f25d6d6bc2e8...

Yes, but also no. The Prometheus ecosystem already has two FOSS time-series databases that are complementary to Prometheus itself. Thanos and Mimir. Not to mention M3db, developed at Uber, and Cortex, then ancestor of Mimir. There's a bunch of others I won't mention as it would take too long.

I used the one in their tutorial.

Grafana Agent can collect and stream data via Prometheus remote write protocol. Then you can either use Prometheus or Mimir. to receive the data at a central location. It depends on how many millions of series you need to collect.

Long term storage all depends on your needs and sophistication. I use Thanos for our system since it has an extremely flexible scaling system. But there is also Grafana Mimir. They're both similar in that they use Prometheus TSDB format as part of the underlying storage. One nice Thanos advantage is that it does do downsampling in addition to being able to store raw metric data for a long time. It will auto-select downsampled data to make requests faster.

Grafana Mimir - scalable storage for Prometheus

Depending on how you want to set things up, you can use Thanos or Mimir to create the single-pane-of-glass view of your data.

It's like Prometheus, but for logs. Okay it's not really to do with the Norse or Greek gods, instead Loki is a horizontally-scalable, highly-available, multi-tenant log aggregation system inspired by the open source project Prometheus. Built by Grafana Labs, Loki is designed for ease of use. Instead of indexing the contents of the logs, Loki provides a set of labels for each log stream. The latest update includes query acceleration with Bloom filters, native OTel support, Helm charts, and more. Check out the changelog for all the major changes and deprecations.

I also needed to make a small patch to Promtail to make this work: https://github.com/grafana/loki/pull/10256

We don't pull logs, we forward logs to a centralized logging service.

Over the past few months, I've been spending a lot of time creating dashboards on Grafana using Loki for MyUnisoft (the company I work for).

For log systems you generally don't migrate data. Logs lose value over time. What you want to do is to go ahead and start ingesting data into the new system (OpenObserve in this case) and slowly, the data in the old system will become stale and then you can retire it. However if you need to export logs anyhow, there is no straightforward way in loki to do this. You could run a script to query loki and export it to a file. If found this thread with a sample script - https://github.com/grafana/loki/issues/409

That snap is woefully out of date. The upstream repo was recently updated to 2.8.2, but the snap stable channel has 2.4.1 from 18 months ago. https://github.com/grafana/loki/releases/tag/v2.8.2

Loki