Minio dashboard showing no data in mimir-blocks bucket

[udeshyaG]

Hi,

• I followed the tutorial for Getting started and setup the environment using docker-compose as mentioned.
• I exposed the Minio service at port 9000 and viewed the console. I found that the mimir-blocks bucket is empty.
• The 3 mimir instances are not storing data in minio.

I would be thankful if anyone could tell me why this is happening?

I viewed the logs of the 3 Mimir instances using docker logs command. It just gives a warning msg="Worker address is empty in single binary mode. Attempting automatic worker configuration. If queries are unresponsive consider configuring the worker explicitly".

[pracucci]

The 3 mimir instances are not storing data in minio.

How long have you kept Mimir running? Incoming metrics are stored in the ingesters and then periodically uploaded to the object storage: it happens every 2h, while for the first run (when ingesters have no data at startup) you may have to wait up to 3h.

I viewed the logs of the 3 Mimir instances using docker logs command. It just gives a warning msg="Worker address is empty in single binary mode. Attempting automatic worker configuration. If queries are unresponsive consider configuring the worker explicitly".

This is fine and expected when running Mimir in monolithic mode.

[udeshyaG]

Thank you for your quick answer.

• I kept Mimir running for 3+ hours and found the data was uploaded to the Minio object storage 👍 🚀
• Is there some way to configure Mimir to fasten this time? I took a hint from the docs and set -blocks-storage.tsdb.retention-period=20m but it seemed to have no impact.
• Is this doable in monolithic mode or only configurable when we set up Mimir in microservice mode?

[pracucci]

Is there some way to configure Mimir to fasten this time?

To increase the frequency at which ingester data is uploaded to the storage, you have to lower -blocks-storage.tsdb.block-ranges-period (see doc). However, we strongly recommend to keep the default because other parameters are based on it and reducing the block range period introduces side effects and potential performance issues.

I took a hint from the docs and set -blocks-storage.tsdb.retention-period=20m but it seemed to have no impact.

This is unrelated. This how long blocks are retained in the ingester after they've been written, and should be larger than the -blocks-storage.tsdb.block-ranges-period, -querier.query-store-after and large enough to give store-gateways and queriers enough time to discover newly uploaded blocks. Like other advanced configs, we strongly recommend to keep defaults.