Согласен, "косяк" - не то слово.
Но дико ограничивает в некоторых системах, где рулить закон не дает

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

Согласен, "косяк" - не то слово.
Но дико ограничивает в некоторых системах, где рулить закон не дает

Согласен, "косяк" - не то слово.
Но дико ограничивает в некоторых системах, где рулить закон не дает

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

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

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 нужно убить в себе программиста.

Кстати, вот такой еще вопрос вырос пока писал эту фразу:

"Вам может показатся, что в какой-то момент вам будет нужен pushgateway. На самом деле, это еще одна ловушка для пытливых умов, которые ломают головы, зачем нужно это чудо после существования textcollector в node_exporter и statsd_expoter."

А зачем реально кто-то использует pushgateway?

Меня это всегда несколько развлекало. Вот прям что бы туда кто-то заходил нельзя, а так выноси из хаты что хочешь, всем все равно ...

В смысле получить в буффер 5 минут логов и делать их реплей эмулируя их отправку?

Вроде норм, кроме четвертого пункта. Как вы представляете экспортер с обнулением данных после каждого пулла, когда его скрейпит несколько прометеусов?

ФЗ или из головы?

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

В целом претензия в том, что пром в таком подходе заставляет собирать данные про метрики все время, пока приложение работает, и если где-то лажанули с метками, то пострадает еще и клиентское приложение, потому что будет хранить в памяти кучу счетчиков с условными /user/{user_id} путями. В той же python либе от прома нет никакого expire на эти метрики :(

Кстати, вот такой еще вопрос вырос пока писал эту фразу:

"Вам может показатся, что в какой-то момент вам будет нужен pushgateway. На самом деле, это еще одна ловушка для пытливых умов, которые ломают головы, зачем нужно это чудо после существования textcollector в node_exporter и statsd_expoter."

А зачем реально кто-то использует pushgateway?

для крон джобов

Но ведь там же проще или файлик ложить, или есть уже серьезно, то в statsd отправлять, разве нет?

это отличный вопрос, лично я считаю, что никто и никогда не хочет использовать pushgateway