прометеус конфигурируется списком адресов, которые он будет слать GET с указанной периодичностью(scrape interval). Прометеус будет ожидать в ответе plain/text ответ со списком метрик и значений в определнном формате.
Вот список экспортеров(приложений читающих системные метрики или метрики конкретных приложений) метрик:
https://prometheus.io/docs/instrumenting/exporters/

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

Самая популярная библиотека для го-приложений - https://github.com/prometheus/client_golang
Она немного громоздкая, с кучей зависимостей. Если нужен вариант по!легче и по-проще, то лучше использовать эту:
https://github.com/VictoriaMetrics/metrics

Найти библиотеки под любой другой язык тоже не проблема.

я вашу либо даже в канали пиарил вроде)

В 99% случаев прометеус сетапят вместе с Grafana для визуализации. В таком случае очень удобно пользоваться уже готовыми дашбордами: https://grafana.com/dashboards
Там можно отсоритровать дашборды по прииложениям и экспортерам. Позволяет очень быстро построить приемлимую визуализацию и посмотреть хорошие примеры по построению графиков

VictoriaMetrics полностью поддерживает PromQL, поэтому отлично интегрируется с графаной через прометеусовский datasource

ограничения по памяти выставлены опытным путем, поэтому они могут подходить не всем и может потребоваться индивидуальная подгонка. Большинство ограничений по памяти зависят от флага командной строки -memory.allowedPercent. Есть еще и другие ограничения, которые настраиваются индивидуально с помощью других флагов. Если их всех отключить, то вероятность OOM сильно возврастает, особенно при "тяжелых" запросах, сканирующих сотни тысяч временных рядов с сотнями миллионов отдельных точек

ребят, а есть какие-то ограничения по кардинальности метрик? Драматическое падение скорости и всякое такое?

если расматривается сбор метрик в кубренетесе(при недолгой жизни пода и частому появлению новых соотвественно с новыми лейблами) то с версии 1.17 сделали некоторые шаги в эту сторону а имеено ввели внутренний индекс и кардинальность не ощущается в этом случае

ну мне просто интересно когда ощущается. Например я буду собирать метрику с nginx логов и в качестве лейбла укажу remote_ip

ну или с других штук, например, то есть если метрик будет в итоге там тыщ 200-300-400

А не проблема

и делать сумарные запросы по ним будет не тяжело?

надо будет проверить

это вообще детская кардинальность для VM. У нас есть пользователи с кардинальностью больше 300М на single-node версии VM

Скорость вставки может упасть при нехватке памяти для кэша активных метрик, т.е. по которым приходят новые данные. Для кэша одного миллиона активных метрик нужно где-то 400 мегабайт памяти. Кроме этого кэша память потребляется другими кэшами и объектами, поэтому вставка на такой кардинальности не должна тормозить на компе с гигабайтом памяти с настройками по умолчанию. При желании можно увеличить процент памяти под кэш с помощью опции -memory.allowedPercent

суммарные запросы по большому количеству метрик должны работать быстрее, чем у всех конкурентов. Тяжелые запросы распараллеливаются на имеющиеся ядра проца, поэтому время их выполнения уменьшается с увеличением количества ядер. См. https://medium.com/@valyala/measuring-vertical-scalability-for-time-series-databases-in-google-cloud-92550d78d8ae

ну я очень верю что у вас быстрее чем у конкурентов. Но есть же разница относительно всяких эластиков?

как бы немного разные вещи

я знаю, поэтому и спрашиваю

эластик - поиск и агрегированние по высококардинальным данным, то есть каждая запись может быть уникальной. На это и заточен. Метрики обычно это снижение кардинальности данных в угоду скорости. Но теги\лейблы позволяют опять нарастить кардинальность и мне интересно насколько сильно можно её наращивать на VM

Все tsdb заточены под работу с временными рядами, в каждом из которых добавляются точки с регулярным интервалом, не превышающем пару минут. Если у тебя будут временные ряды с малым количеством точек, которые добавляются туда с рандомным интервалом, превышающем десятки минут, то лучше посмотреть в сторону ClickHouse :)
Поэтому лучше не злоупотреблять кардинальностью и следовать советам от прометеуса:

Remember that every unique combination of key-value label pairs represents a new time series, which can dramatically increase the amount of data stored. Do not use labels to store dimensions with high cardinality (many different label values), such as user IDs, email addresses, or other unbounded sets of values.

Спасибо большое за ответы. 300m кардинальность это то что надо