Дак я не против, только если ещё в одну базу влезать - надо сначала понять что в этой сделал все что мог. Если @valyala например скажет "тут такое не сделать" то вопросов не будет :)

Там про всё так написано

Мне кажется, пора расширять фак по прому и вписать, что он тоже говно)

А к там так более менее и написано ж.
Между строк выходит что явно говно этот пром!

С пулреквестами не густо

Что-то в духе:

- Ладно, возьму пром.
- Но и пром говно?
- Да как так?
- Ну вот вкратце:

1. Очень большие проблемы с хранением данных в долгосрочном периоде. Какие-то варианты есть, но они все в итоге заставляют или использовать пром исключительно как сборщик + оповещалку, или строить дашборды по два раза. remote read протокол полное днище
2. Алертинг в начинающей стадии. Нужно городить костыли или колхозы для чего-то, что можно просто найти в другой экосистеме
3. Очень, то есть ОЧЕНЬ чувствителен к корректному использованию  тегов. Решили запихнуть url path в тег? Ну, вас ждет неприятный сюрприз, последствие которого будут еще очень долго вам аукатся.
4. Pull модель. Даже не так, особенная pull модель, которая не обнуляет данные после их получения. Помните пункт 3? Ну так вот, айда перезапускать все сервисы подряд.
5. Офигенный подход к аггрегированию метрик для нескольких процессов в клиентских либах (для веб приложений написанных на python, js, php или тех, кто предпочитает 12factor) приводит к тому, что даже после перезапуска сервисы могут подхватить из какого-то внешнего источника (redis, файлы) все эти метрики и начать свистопляску заново.
6. Очень нордическая модель данных. Вам может показатся, что она какая-то кривая, но, обычно, вам расскажут, что вы неправы. Без вариантов
7, Нет никаких шансов на внятные расширения внутри самого языка. Новые фичи так же внедряются исключительно для цели служения нордической модели данных. Хотите что-то классное? Вас ждет remote read/write протоколы и много страдания, как всегда,

Ах да, из всяких мелочей:
- Очень важно помнить, что вы работаете с временным рядами. И потеря части точек - это не проблема
- Пром не попадает в ваш use case? У вас даже нет шансов его докрутить до какой-то кондиции
- Stateless алертинг. Перезапустили пром? Ну вот все ваши активные алерты и тю-тю. Для алертов с большими for это обычно очень приятно.
- Что бы работать с blackbox expoter нужно убить в себе программиста.

Или слишком бредово?

=) Про блэкбокс даже немного трогательно.

не нордическая а германская, не надо тут наговаривать на нордов

Давай пулом

> - Stateless алертинг. Перезапустили пром? Ну вот все ваши активные алерты и тю-тю. Для алертов с большими for это обычно очень приятно.

устарело несколько версий назад

Примем всем миром

У меня все еще не работает ... Не смотря на последнюю версию

заведи им баг, они это точно делали несколько версий назад

Про викторию метрикс сделайте

Правда я ничего не могу про неё сказать, могу про пром добавить:

N. Отсутствие шардирования. Надеяться на то, что ваши метрики смогут эффективно балансироваться между серверами, равномерно потребляя место на диске и память, бесполезно. Придётся поднять несколько инстансов и собирать на них разные данные
N+1. Отсутствие репликации. Тоже самое, что и с шардированием, поднимайте несколько неинстансов и ходите в эндпоинты дважды. Дробный RF, рид-соломон? Не надейтесь

Кстати, в пром надо про шардирование написать

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

на приложение

На метрику