Прямой ответ
VictoriaMetrics (VM) — TSDB-хранилище метрик (PromQL-совместимое — метрики-экосистема переносится), выросшее из «Prometheus, который держит большие объёмы на скромном железе»: эффективность — главный аргумент (практические замеры сообщества: ×3–7 экономии RAM на активных рядах, ×7–10 сжатие на диске против Prometheus — кардинальность-контекст — «12M рядов на 16 ГБ RAM» — норма VM против 48 ГБ Prometheus — Mimir-сравнение — сверять на своих данных — бенчмарк-дисциплина); две редакции: single-node (один бинарник — весь функционал — «Prometheus-замена» — деплой за 10 минут (docker/бинарь — данные на диск — тома) — оптимум до ~1–2M активных рядов/100k samples/s на сервере (ёмкость-оценка); cluster (vminsert/vmstorage/vmselect — шардирование — горизонтальный масштаб — «10M+ рядов/мульти-тенантность» — ближе к Mimir по роли, но: объектное хранилище НЕ требуется (vmstorage — локальные диски — «S3-зависимость» — минус из архитектуры — проще/дешевле для self-hosted — выбор-контекст); фичи сверх Prometheus: downsampling (cluster-версия — 5m/1h-агрегаты — Mimir-аналогия — retention-экономия), multi-tenancy (из коробки в обоих — tenant-id в URL — Mimir-сравнение), vmalert (алерт-движок — Prometheus-правила совместимы — алерты — запись алертов обратно в VM — история), vmagent (лёгкий сборщик — скрейпы+remote write — 10–30 МБ RAM — замена Prometheus на edge/k8s-нодах (Operator-контекст) — буферизация на диске — сеть до хранилища рвётся — данные не теряются — надёжность), MetricsQL (расширение PromQL — обратно совместим — keep_last_value/median_over_time/сглаживания — PromQL-практика — «в PromQL так нельзя» — в MetricsQL можно — Grafana-запросы работают как есть); когда выбирать VM: Prometheus упирается в RAM/диск (single — частая точка: 5–15M рядов — тюнинг исчерпан — метрики-стоимость), self-hosted без S3-зависимости (свои диски — MinIO-альтернатива не нужна — VM сам «своё хранилище»), стоимость (железо ×3 меньше Mimir-кластера при том же объёме — расчёт — ADR); когда НЕ VM: глубокая Grafana-стек интеграция нужна (Mimir — нативнее — Mimir — экосистемный выбор), managed-путь (Grafana Cloud — VM Cloud существует, но Mimir-совместимость шире), «один Prometheus, 15 дней хватает» — ничего не менять (метрики-минимум — миграция ради миграции — техдолг-наоборот).
Практика: миграция Prometheus → VictoriaMetrics без остановки
Пошагово (single-node-путь, самый частый): (1) VM-single рядом (docker/systemd-юнит — диск с запасом ×3 от текущего Prometheus-размера — сжатие учтено — тома — retention -retentionPeriod=13m (месяцы — синтаксис VM); (2) импорт истории (vmctl — vmctl prometheus --prom-snapshot (tsdb-снапшот — бэкап-механика — снапшот перед — безопасность) — история переезжает часами на больших объёмах — параллельно с работой — миграция-осторожность); (3) dual write (Prometheus remote_write → VM (/api/v1/write) + локальное хранение продолжается — неделя сверки (сверка-культура — Grafana-дашборд из VM против Prometheus — расхождения — метрики-качество); (4) Grafana-свитч (новый datasource VictoriaMetrics (Prometheus-тип — URL /prometheus — Grafana — дашборды/переменные без правок — PromQL-совместимость — запросы — единственное: recording rules — пока в Prometheus (evaluator); (5) алертинг (vmagent/vmalert: скрейпы+правила — Prometheus-файлы правил совместимы (-rule — алерты — Alertmanager остаётся (receivers — Grafana Alerting — или как был); (6) Prometheus → agent (режим агента (WAL+remote write — конфигурация — локальное TSDB отключено — RAM нод −70% — ресурсы — или vmagent вместо Prometheus (k8s-скрейпы — ServiceMonitor-конвертация — vmagent-оператор (Operator-контекст); (7) проверка под нагрузкой (неделя dual — затем отключение локального хранения — rollback-план: Prometheus-агент снова пишет локально — стратегии); результаты типичные (замеры сценариев): RAM 48→11 ГБ, диск 340→48 ГБ, запросы дашбордов p95 3.2 с→400 мс (индекс-эффективность — Grafana-UX); подводные камни: MetricsQL-расхождения в edge-кейсах (сложные subquery/агрегации — поведение «почти» то же — критичные recording rules проверить тестами — vmalert-тестирование — тесты), dedup при нескольких источниках (-dedup.minScrapeInterval — два Prometheus пишут одно — VM дедуплицирует — настройка — HA-контекст), бэкап VM (vmbackup — снапшоты в S3/локально (MinIO) — «метрики не бэкапим» — SLO-история — 3-2-1 — политика — ADR).
FAQ
VictoriaMetrics против Mimir — что выбрать для долгосрочного хранения? Архитектурное ядро различия: VM хранит на локальных дисках vmstorage (своё железо — проще стек, дешевле на self-hosted, но масштабирование — шардами/нодами — ёмкость), Mimir — в объектном хранилище (S3/MinIO — эластичность/дешевизна архива, но +компонент и латентность S3 — Mimir-архитектура); критерии: парк железа свой, S3-культуры нет — VM (проще эксплуатация — один тип хранения — мониторинг-стек); облако/Grafana Cloud-вектор/огромные архивы — Mimir (S3-эластичность — Grafana-нативность — Mimir); эффективность на железе — VM впереди (RAM/диск — замеры — раздел выше — бенчмарк — сверять на своём); multi-tenancy/лимиты — оба умеют (кардинальность-защита — VM — per-tenant лимиты простыми флагами); миграция между ними — возможна (remote write-совместимость — «не брак навсегда» — выбор — контекст решает); «VM — это Prometheus?» — API-совместим, архитектура своя (нет WAL-семантики Prometheus, индекс-устройство другое — «перенести tsdb-блоки» — vmctl конвертирует — миграция).
Как vmagent заменяет Prometheus в Kubernetes? vmagent: скрейпит те же таргеты (ServiceMonitor/PodMonitor-совместимость через VM-operator (Operator-практика — k8s-SD все механизмы), remote write в VM/Mimir/другой Prometheus, 10–30 МБ RAM против гигабайтов Prometheus (нет TSDB/evaluator — только сбор+буфер — ёмкость); буферизация: диск-очередь (хранилище недоступно — копится локально — часы — отправка при recovery — надёжность — против «remote_write дропнул» — Prometheus-агент-WAL — аналог — метрики-доставка); чего нет: алертинг-evaluation (правила — vmalert отдельно или хранилище — алерты — разделение ответственности), локальные запросы (нет query API — читать из VM — Grafana); паттерн парка: vmagent-DaemonSet на нодах (локальные скрейпы — близость — k8s-сети) → VM-кластер центрально — «сбор на edge, хранение в центре» — Alloy-аналогия — телеметрия-конвейер; «а Prometheus-Operator?» — сосуществует (Operator управляет vmagent через CRD — или vm-operator — выбор оператора — helm-контекст).
Правда ли, что VictoriaMetrics экономит ресурсы в разы? Да, с оговорками честности: источники экономии — сжатие (своё кодирование таймсерий — диск ×7–10 против Prometheus-tsb — на практике подтверждается на типовых нагрузках), RAM (индекс в памяти компактнее — head-данные эффективнее — ×3–7 — кардинальность — высокие цифры — на высокой кардинальности), CPU (парсинг/запросы — оптимизации — дашборды быстрее — сценарий-замеры); оговорки: цифры из промов/статей — проверять на своих данных (бенчмарк-методика — dual-write неделя — свои замеры — «в наших условиях ×4, не ×10» — типично); «VM решит все проблемы» — нет: кардинальность-взрыв дорог везде (кардинальность — VM дешевле хранит мусор, но мусор — мусор — дизайн метрик первичен), алертинг/дашборды — отдельные системы (vmalert/Grafana — стек); экономический расчёт: железо VM-single (16 ГБ/2 ТБ — ~$40/мес VPS) против Prometheus того же объёма (64 ГБ/6 ТБ — ~$160 — ёмкость-деньги) — окупается сразу при миграции-стоимости дня-два работы — техдолг-инвестиция.
Что с алертингом и recording rules в VictoriaMetrics?
vmalert — компонент-аналог Prometheus-evaluator: тот же формат правил (groups/rules/expressions — файлы переносятся as-is — алерты), читает из VM (или любого Prometheus-совместимого), алерты шлёт в Alertmanager (receivers — Grafana Alerting — или классический AM — стек не меняется), recording rules записывает обратно в VM (агрегаты — recording-практика — тяжёлые запросы предагрегированы — дашборды/SLO (SLO — burn rate-запросы из aggregates); MetricsQL в правилах (расширения доступны — keep_last_value — «дырки» в данных не рвут алерт — метрики-качество — осторожно: расширение = привязка (правила с MetricsQL не вернутся в Prometheus — миграция-обратимость — критичное — чистым PromQL); HA-пары vmalert (два инстанса — дубли алертов — dedup в Alertmanager/VM (dedup — -clusterMode/replica-лейбл — HA-контекст); тестирование правил — vmalert-флаги/unit-подходы (тесты — критичные алерты тестировать всегда — алерт-культура).
Источники: документация VictoriaMetrics (docs, key concepts, cluster) — ссылки в шапке.