​​Долгосрочное хранение метрик всегда было одной из слабых сторон Prometheus. Изначально он был спроектирован для оперативного мониторинга, не подразумевающего хранение истории метрик на срок более двух недель. Сохранить в нём тренды месячных или годовых интервалов было отдельной задачей с привлечением внешних хранилищ и инструментов. Весной Grafana анонсировала своё решение под названием Grafana Mimir, которое способно максимально просто, быстро и дёшево решить вопрос с долгосрочным хранением метрик в том числе с помощью S3 совместимого хранилища. В самом простом варианте может на файловую систему складывать данные. Одним из основных преимуществ указывается возможность быстро и просто настроить горизонтально масштабируемый high availability кластер хранения. Настроить всё это дело реально очень просто. 1️⃣ Поднимаете в Docker сервер Mimir, указав в его конфиге бэкенд для хранения данных. В самом простом случае это может быть локальная директория. 2️⃣  Указываете в Prometheus в качестве remote_write сервер с Mimir. 3️⃣ В веб панели Grafana добавляете сервер Mimir в качестве Prometheus data source. Авторы Mimir называют её самой производительной TSDB для долговременного хранения метрик Prometheus. Насколько это правда, трудно судить. Вот пример их нагрузочных тестов. Авторы конкурирующего хранилища из VictoriaMetrics собрали свои стенды с обоими продуктами и протестировали их производительность. В результате оказалось, что Mimir более требовательна к памяти, больше нагружает процессор и больше расходует места хранилища, но имеет ниже задержку в 50-м перцентиле и выше в 99-м. По результатам теста почти по всем параметрам Mimir хуже, причем с кратной разницей, что немного странно. Ниже ссылка на get started, где в самом начале представлено наглядное видео по настройке связки Prometheus + Grafana + Mimir + MinIO. Сайт - https://grafana.com/oss/mimir/ Исходники - https://github.com/grafana/mimir Get started - grafana.com/docs/mi…-started #prometheus #grafana #devops #мониторинг