полностью переписать деплой и манифесты

Кстати, так, чисто случайно, никто podman не пробовал?

Kompoze

Это вообще куда нить в кубернетис чат. Тут про метрики

Тоже верно, прошу прощения)

microk8s?

Тысячи их. Мне microk8s зашёл как лаба. А k3s типа для не самой критичной задачки.

Alert! Bob Bigsby is a known spammer and is CAS banned. Ban is strongly recommended.

Всем привет.

Не хватает понимания как собирать метрики с удалённых площадок.

Есть несколько датацентров раскиданых по миру. В каждом дц есть несколько виртуалок с web-сервисами и просто сервисами (это винда), в перспективе будет кубер.
По прикидкам на каждом дц будет собираться ~500 метрик.

Есть ещё один дц, там тоже несколько виртуалок с сервисами управления всем этим хозяйством.

Хочется собирать все метрики в центр и там принимать решение об алертинге и т.п.

Вижу несколько вариантов:
1. Prometheus в центре, и на каждом ДЦ с web-сервисами тоже prometheus. Дальше настроить федерацию и собирать.
 Из плюсов:
 -  всё уже придумано
 Из минусов:
 - каналы связи не всегда дают возможность достучаться до ДЦ
 - prometheus не поддерживает аутентификацию, нужно будет придумывать что-то перед ним

2. Prometheus в центре, на веб-сервисных ДЦ метрики пушить в Azure EventHub (кто не знает, это типа кафки), в центре принимать метрики из EventHub и пушить в Prometheus.
 Из минусов:
 - городить костыль.
 Из плюсов:
 - доступ к своим региональным azure есть из всех регионов и он получше, чем наши каналы связи.
 - судя по всему похожий механизм  всё равно нужен будет для передачи трассировок и логов в центр, так что плюсом будет являться единый механизм для передачи данных.


Может есть идеи получше?

я бы сначала попробовал федерацию - оно проще, если не будет устраивать, то можно уже костыли доставать

если позволяет среда, то аутентификацию можно заменить ограничением на подключение к порту с определённых адресов

да и сетевые задержки/иные проблемы - региональный пром всё равно будет собирать у себя, а центр должен подцепить в любом случае, пусть даже и с небольшими задержками

а почему не алертить с региональных дц?

поясняю. Предположим, у вас нарушилась связность между ДЦ, но при этом оба ДЦ работают. В региональном падает сервис - алерта в Вашей топологии не будет

т.е. центральный пром нужен только лишь для двух вещей
1. централизованное хранение метрик, а дальше передавать их в какое-то хранилище для статистики
2. алертинг, в случае, если накрылись каналы до региональных ДЦ или они попросту отключились

они вне всей нашей инфраструктуры, сходу кажется сложно организовать алертинг с тех площадок. Но вопрос хороший, может и действительно можно так организовать. Я подумаю над этим.

сорри. У меня в башке щелкнуло. Гусаров. Ажур. Мы знакомы? Нет. вряд ли )

совпадение

Обычно если связность прям совсем нарушилась, то мы регион убираем из раздачи.
Т.е. остро такая проблема не стоит.

Ещё и хочется всю систему видеть в одном месте.

Это наверное ты про Владимира Гусарова :) Он рассказывает много про TFS и т.п.