Prometheus хранит метрики на локальном диске одного сервера — надёжно, но не бесконечно и не горизонтально. Mimir — принимающая сторона remote_write: масштабируется по узлам, хранит историю дольше, чем позволяет один диск.
Со стороны Prometheus подключение — одна строчка:
remote_write:
- url: "http://localhost:9009/api/v1/push"
Порт 9009 и путь /api/v1/push — совместимый с обычным Prometheus remote_write протокол, поэтому переход на Mimir не требует менять, как метрики собираются — меняется только, куда они в итоге складываются на долгий срок.
Mimir изначально мультитенантный — каждый запрос (и на запись, и на чтение) несёт HTTP-заголовок X-Scope-OrgID, который определяет, какому тенанту принадлежит запрос:
remote_write:
- url: "http://mimir:9009/api/v1/push"
headers:
X-Scope-OrgID: "team-backend"
Без авторизующего reverse-proxy перед Mimir этот заголовок можно подставить напрямую в конфиг, как в примере выше — но тогда любой, кто может писать в этот URL, может писать под любым X-Scope-OrgID, который сам укажет. В проде обычно ставят reverse-proxy, который сам простaвляет заголовок на основе аутентификации, а не доверяет клиенту.
Для одного тенанта на всю инсталляцию (самый частый сценарий небольших команд) заголовок всё равно обязателен — просто фиксированное одно значение на все запросы.
На этом — конец серии про LGTM-стек: от node_exporter, снимающего метрики хоста, через postgres_exporter/встроенный плагин RabbitMQ, единый коллектор Alloy, три бэкенда для логов/трейсов/метрик (Loki/Tempo/Mimir) и сам Prometheus как точку сбора. Дальше — уже частности конкретного дашборда и алертов под свою инфраструктуру.
#prometheus #grafana #lgtm