Кстати, как решают проблему user_id, ip или url в лейблах другие системы мониторинга?

Кстати, как решают проблему user_id, ip или url в лейблах другие системы мониторинга?

нет. у меня реально кронджоба. в файлик положить не вижу смысла, для статсд не подходит кейс

Ну, мне было лень разворачивать еще push gateway, выделил для node_exporter отдельную папочку и поехало

укладка в файлик это кронджоба на хосте. а если она в гитлабе ?

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

Там время выполнения, количество ошибок и т.д. Хотя gitlab-runner вроде и сам умеет, но там внутри еще можно поэтапно собирает в каждой джобе

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

Извини за наркоманию, но можно складывать файлик с результатом в S3

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

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

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