вообщето занимаются...

Да, но ему нужен кастомный экспортер на каждый сервис запустить рядом. Меня это смущает. Допустим тот же java имеет jmx и может все метрики отдавать уже, но надо запустить рядом агента который будет переводить в понятный прометеусу формат. Почему тогда я не могу просто прометеусу сказать, что вот точка jmx, забери оттуда метрики. Вместо этого, я запускаю рядом с java агента прометеус и потом уже прометеусу говорю откуда брать метрики.

потому что jmx сложный. а пром хочет быть простым

если в механике сбора данных с jmx будет баг надо будет чинить его в проме. зачем им это ?

Вынести в плагин?

так и вывели

считайте что все экспортеры это плагины

да, но вместо того, чтобы запустить один плагин для 10 jmx, мне надо запустить 10 плагинов, для 10 jmx

Вот что больше всего смущает.

вообще вам не нужно их запускать. сходите к девпелоперам и попросите что бы отдавали сразу в формате прома.

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

к примеру https://marketplace.atlassian.com/apps/1218015/prometheus-exporter-for-confluence?

Так там же просто агент, он в той же JVM работает

И перекладывает метрики из JMX в Prom dashboard

Попробую понять модель. По сути прометеус, хочет только забирать метрики в стандартном формате (для себя). Если сервис не может отдать, то рядом мы запускаем экспортер, который будет их переводить в данный формат. В этом суть заключается?

Глобальный концепт?

Потому что метрики должны отдаваться в формате прома.
Метрики в jmx - херня

ага именно так

и надо сказать этот подход работает довольно не плохо. всякие циски начали подтягиваться

ибо всех солидно задалбал snmp