Как спроектировать архитектуру observability-платформы для мультирегиональной системы с десятками сервисов, учитывая рост кардинальности метрик и требования к latency запросов дашбордов?

Короткий ответ

Единственного правильного решения нет — выбор зависит от числа регионов, требований к задержке между региональным сбоем и видимостью, бюджета на хранение и допустимой сложности эксплуатации; типичный подход — региональные Prometheus-инстансы с локальным коротким retention плюс глобальный слой агрегации (Thanos/Mimir/VictoriaMetrics cluster) с remote_write и downsampling для долгосрочного хранения и кросс-регионального query.

Как это работает подробнее

региональные Prometheus собирают метрики локально с низкой задержкой и минимальной зависимостью от сети между регионами (что важно само по себе — observability не должна зависеть от того же сетевого пути, который мониторит); глобальный слой объединяет данные для кросс-региональных дашбордов и алертов, но добавляет задержку (секунды–минуты) и становится дополнительной системой, которую тоже нужно мониторить и поддерживать отказоустойчивой.

Компромисс: полностью централизованная архитектура проще в эксплуатации и даёт единый источник правды, но создаёт единую точку отказа и зависимость от межрегиональной сети; полностью децентрализованная (независимые стеки по регионам) надёжнее при частичных сбоях, но усложняет кросс-региональные дашборды, увеличивает число систем для поддержки и требует согласования конфигурации между командами. Выбор должен обсуждаться с учётом SLO самого observability-стека, стоимости и зрелости команды эксплуатации; кандидату стоит explicitly проговорить эти критерии, а не называть один вариант единственно верным.

Пример кода

example.txtКопировать

Регион A: Prometheus (retention 2d, raw) --remote_write--> Mimir (глобальный, retention 13 мес, downsampled после 7д)
Регион B: Prometheus (retention 2d, raw) --remote_write--> Mimir (тот же кластер)
Alertmanager: региональный инстанс в каждом регионе для critical-алертов + глобальный для cross-region SLO

Что использовать на практике

• Практика. ключевые решения — где физически находится точка принятия решения об алерте (региональный Alertmanager ближе к источнику данных снижает задержку реакции, но требует синхронизации правил между регионами); как ограничивать кардинальность на глобальном уровне (агрегация high-cardinality данных на уровне региона перед отправкой наверх); какой downsampling применять для данных старше недели/месяца, чтобы не хранить raw-данные бесконечно.
• Практика. Такая схема сохраняет быструю локальную видимость и алертинг при сетевом разделении между регионами, одновременно давая глобальный долгосрочный view через Mimir — но требует отдельного мониторинга доступности самого Mimir-кластера и remote_write очередей (prometheus_remote_storage_failed_samples_total).

Подводные камни

• Частые ошибки. строить единый глобальный Prometheus без региональных инстансов, из-за чего сбой сети между регионами делает observability недоступным именно в момент, когда он нужнее всего; не учитывать стоимость egress-трафика при отправке всех raw-метрик в глобальное хранилище из нескольких регионов; игнорировать отказоустойчивость самого observability-стека, полагая, что "мониторинг не упадёт".