А на каких обьемах начались такие проблемы ?

или это предположение исходя из прочитанного и общей схемы ?

На любых

Единственные таймауты которые я поймал это при использовании ceph как s3

там он тупо упирался в диск i/o timeout отдавал

Но там маленькие обьемы, до 50 GB

Я очень рад что вам нравится и в голове инекментировпл счётчик довольных пользователей

Тогда можно напрямую промы опрашивать через promxy или thanos-querier)

Отказ от сайдкаров позволит включить сжатие и мб вам и не нужно будет ничего выгружать в облако

А так получается сто данные выгружаются в облако, но запросы за последние 2ч все равно идут во все регионы

Может вам и просто пара федерирующих промов в европе все решит

Может, не понравилось в этой схеме то что промы обжираются памятью и оомятся

а ткак должен оомится квериер

Как ни странно квериер живет

мониторите его ?

я без подкола.

Внутренние метрики нет, пока только стандартные cpu memory network

Cpu близится к нулю , память примерно 1-3 gb на запросах

Вы случайно не путаете доступность данных с их консистентностью и сохранностью? Если часть данных теряется или портится, но при этом оставшиеся данные остаются доступны для чтения, то система считается highly available. Если же при потере или порче части данных система перестает работать, то она не highly available.
Репликация снижает риск утери части данных, но она не всегда может обеспечить консистентность и сохранность данных. Например, если данные повредились сразу на всех репликах или не смогли вовремя восстановиться из живых реплик. Или если данные повредились при неудачном обновлении кластера.
Для сохранности данных нужно делать бэкапы, а не репликацию.