5 ms·

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

• paulvnickerson 3y ago
  Currently we run it in "monolithic" mode, in which all components are grouped together, and it works just fine: https://grafana.com/docs/mimir/latest/references/architecture/deployment-modes/#monolithic-mode https://grafana.com/docs/mimir/latest/references/architectur...
  • hagen1778 3y ago
    How is it different from running a Prometheus server then? Prometheus is monolithic as well. It is cool and not cool in the same time. With monolithic approach, the process becomes very simple to run and efficient at the same time, since there is no penalty on interprocess communication and network is not involved. But you can't scale monolithic applications horizontally. Horizontal scaling is very likely the reason why Mimir exists at all. If Prometheus supported horizontal scaling out of the box, there may be no need in Thanos, Cortex or Mimir.
    • Jedd 3y ago
      Have a read about the design intent and architecture to get deeper info on how it's different - but basically, indexes aren't retained locally, which means you've got a MUCH bigger scale (several orders of magnitude) than Prometheus can cope with. You're right that you can't 'scale monoliths horizontally' but Mimir was designed to handle much more data than Prometheus was, on the same compute/memory footprint (obviously storage is a direct function). Mimir will consume multiple Prometheus with remote_write's and de-dup those series. Because it puts older (default 2h) data out to block storage, costs plummet without impacting performance too savagely - the vast majority of queries are going to be hitting fresh data. We've been running monolithic (Nomad, docker) but are experimenting with their 'in-between model' which has 3 components - read, write, backend - which should help us scale more easily than juggling the full microservices deployment method you mentioned above. > If Prometheus supported horizontal scaling ... Well, yes, precisely so.
      • hagen1778 3y ago
        > Have a read about the design intent and architecture to get deeper info on how it's different - but basically, indexes aren't retained locally Would appreciate if you refer to link where this explained. But from what I was able to find, both Mimir and Prometheus store indexes within data blocks. It doesn't matter where data blocks are: locally or on S3. Because you still need to read the index and fit it in the memory in order to locate the needed data. So I don't understand how S3 helps here, unless you run an additional store-gateway which does this job instead. > but Mimir was designed to handle much more data than Prometheus was Do you have any numbers to refer? Isn't Mimir based on Prometheus source code? The storage, indexes, query engine - that should be the same or mostly the same. I'd be really surprised if Mimir could outperform significantly Prometheus in monolithic mode. If I understood correctly, the whole "Mimir was designed to handle" is related to microservice architecture, to its horizontal scaling capabilities and ability to shard read queries across multiple components.
        • Jedd 3y ago
          Sure, no problem - I typed 'mimir architecture' into my search engine to get the link I was thinking of: https://grafana.com/docs/mimir/latest/get-started/about-grafana-mimir-architecture/ https://grafana.com/docs/mimir/latest/get-started/about-graf... Perhaps indexes wasn't the optimum word. There's some references to Prometheus' memory usage if you go looking, typically if you're searching around 'why does prometheus use so much memory'. I'm struggling to find the comparative metrics on capacity that you're seeking, though I do recall seeing them previously, and having run up multiple prometheus instances (in vanilla and agent-mode) and fed those into mimir, I'm aware that prom has some non-negotiable limits on time series.