Я о том что в момент миграции будет outage так или иначе.

Прометей может медленно стартовать и жрать память после kill -9 или OOM. См. https://github.com/prometheus/prometheus/issues/4609 . ВМ в этом плане быстрее всего рнстартует :)

Ну да, я плюс минус так и думал. Спасибо за подтверждение.

магии не существует*

* - магии общего типа, устраивающей всех и вся, а специализированные решения уже не магия

@valyala просто люди хотят репликацию, а подразумевают какую-то возможность автоматической проверки консистентности и понимание где данные правильные (поэтому multi write не катит)

и хотят что-то что не будет требовать дорогих решений и будет работать на любом разумном хостинге (on-prem на железе, gcp, aws, azure, digital ocean, ...) и позволит переживать локальные аутейджи (зона или стойка отъехала)

ну или как минимум мое понимание причин такое

И хотя бы умеренную возможность меж-AZ растягивать

тогда могу развернуть так.
"В Кортексе данные хранятся в Кассандре, которую можно (при всех ее других минусах) настроить под любую консистентность и потерять хоть всю AZ целиком.
ВМ не имеет репликации и настраиваемой консистентности, поэтому в вопросах надежности полагается только на GCP персистентные диски
(или аналогичное решение у других клауд провайдеров). Это решение в принципе достаточно надежно, но стоит понимать что не обеспечивает
100% доступности при проблемах с инфраструктурой провайдера (потеря виртуалок, zone outage). Также использование персистентных GCP дисков может быть ощутимо дороже обычных или даже облачных SSD дисков. Ну и использование только GCP дисков для HA не дает возможности развернуть ВМ в HA режиме on-premise, на собственном железе или в частном облаке".
Не понимаю, почему люди любят строить простые но ненадежные системы из говна и палок вместо использования готовых, надежных и проверенных временем решений (хоть и за счет увеличенной сложности). :trollface:

и это тоже

yep, what @Civiloid said

quantile_over_time считает индивидуальный квантиль для каждого временного ряда. Эти квантили потом нельзя агрегировать, т.е. sum(quantile_over_time(...)) не имеет смысла.
Если нужно подсчитать квантиль поверх многих временных рядов, то можно использовать что-то вроде такого:
histogram_quantile(0.95, sum(histogram_over_time(metric[1h])))
Функция histogram_over_time есть только в вм, поэтому такой запрос не будет работать в проме. Пишу это с телефона, поэтому могу допустить ошибки в запросе. Но идея должна быть понятна. См. про histogram_over_time и другие дополнительные функции, подлерживаемые вм, вот тут - https://github.com/VictoriaMetrics/VictoriaMetrics/wiki/MetricsQL

@valyala и если что это не является нападками на VM, а просто попытка объяснить почему людям не нравится текущее положение дел ) Подобные претензии можно очень много к каким системам предъявить и не значит, что эти проблемы не надо как-то решать

я в результате сделал через quantile (by job) (label_replace(metric) or label_replace(metric))
гистограмму тоже попробую - может оно будет интереснее :)

Да и у меня нет особых претензий к ВМ, продукт хороший. Но аггресивный маркетинг штука обоюдоострая - будь или лучше своего конкурента во всем или понимай (и доноси до потенциального пользователя) ограничения текущей реализации  - а значит и недостатки, а не только преимущества своего продукта. А они всегда есть.
Честность - лучшая политика имхо в таком вопросе.

Ребята все ок мы понимаем что репликация нужна. Это сложно и нет решения которое хоп и работает. Задача намного глубже чем просто скопируй метрики из одного инстанса в другой. Тут куча инженерных деталей.

Диски не выход - но могут решить проблему но это не панацея

И да они отказывают хотя и не часто :)

Второй запрос, скорее всего, неправильный - там двоеточие лишнее перед 24h. В текущем виде он пытается использовать prometheus subquery, который тут вообще не нужен. См. https://medium.com/@valyala/prometheus-subqueries-in-victoriametrics-9b1492b720b3
Если же убрать лишнее двоеточие перед 24h, то этот запрос вернет ряды, значения которых увеличились в течение последних 24 часов. Подразумевается, что ряды  drop_bytes могут только расти, но не уменьшаться, т.е. это counter. Если это не так, то increase может возвращать вообще все, что угодно. См. про counter вот тут - https://prometheus.io/docs/concepts/metric_types/#counter
Первый же запрос возвращает ряды, значения которых увеличились в течение последнего шага (параметр step в запросе к /api/v1/query_range или к /api/v1/query - см. https://prometheus.io/docs/prometheus/latest/querying/api/#expression-queries ). По умолчанию он равен 5 минутам. Очевидно, что количество рядов, значение которых увеличилось за последние 5 минут, будет меньше количества рядов, значение которых увеличилось за последние 24 часа

ровно об этом и была речь выше )