кстати если для графита уже сделано, то можно push-gateway поставить и с него прометеем пулить

это да.. но пуллер может собирать реже информацию, троттлить. Тогда будет работать хоть что то, с потерянными метриками / нодами.

и это да... в любой системе надо предусмотреть вход через задницу. Без этого не работает :-(

Prometheus поддерживает федерацию: https://prometheus.io/docs/prometheus/latest/federation/ никто не мешает иметь несколько прометеусов на запись, а читать из совсем другого

какая еще задница... амбассадор!

вокруг этих анальных порталов ещё придётся накрутить авторизацию, security группы и прочую амазоновскую лабуду.
а сходу плюсы вот как описаны выше, они значительны, но достаточны ли они чтоб переходить с одного на другое?

а что у вас уже есть?

у пуллера другая проблема есть.
Например ты хочешь собирать метрики своего приложения. Например столько отработал такой то вызов, столько то гарбадж коллектор подчистил и т.д. Тебе прийдется в своём приложении эти метрики где то накопить, а потом отдать их (или даже агрегацию) в прометеус.
С графитом это бы всё сам графит сделал, а тут придется тебе в каждом сервисе писать агрегирующий код. Ну или использовать либу которая это сделает за тебя.
Ну плюс, тебе, получается, нужен вебсервер в приложении. Если у тебя воркер который задачи из кролика берет, то у тебя нет этого сервиса. Или метрики из селери задачи..

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

Сейчас инфлакс с графитовой мордой.
К этой комбинации есть какие-то претензии, но я их не осознал.

для питона точно есть. но я к тому что не всегда можно легко приделать сервис к сервису. Если захочешь мониторить celery задачу (а не саму celery), то тебе нужен сервис который слушает пуши и потом их выдаёт по пулам.  Тот же push gateway нужен (я хз что это такое, ибо ниразу не пользовался).

ну ты узнай что за притензии. Потому что идеологически это тоже самое.  
Вот если бы был чистый графит (да еще и оригинальный питонячий), то тут точно надо было бы бежать с него. А инфлакса, тоже есть метки. Да и язык запросов SQL подобный, кому то проще жить. В прометеусе он свой, не сложный, но свой.

Не очень понятно про агрегацию. Прометей тоже умеет агрегировать

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

https://pypi.org/project/zc.buildout/#history
Но там пока только альфа версия. В гитхабе уже подняли вопрос почему бы не сделать нормальный релиз, раз уж сетуптулз прибил easy_install. Но вроде как там ещё не ответили.

В целом можешь попробовать поюзать альфу - у меня она вроед как даже работала.

Вроде как есть готовое решение - гейтвейты. Ты сам пушишь в него что хочешь, а он уже будет хранить и ждать пока придёт к нему прометей.

И не надо сильно переписывать своё приложение.

угу есть, должны быть, ибо без них никак. Я просто говорю что они нужны не потому что, раньше был графит и мы не хотим менять код, а потому что иногда без них нельзя. Это в тему push vs pull.

Так это все библиотеки прометеуса на себя берут. Ты заводишь метрику, инкрементируешь и тп, а внутренний реестр сам копит такое состояние. И уже относительно реестра генерируется тот самый выхлоп для http эндпоинта

Ребят, какой самый лёгкий способ подключится к домашнему серверу (по совместительству домашнему роутеру) извне?