Ну с каунтером потом работать проще, хочешь rate на него накручивай, хочешь increase. Ну и в приложение эту логику засовывать и поддерживать не надо, прометей сам все считает (если мы про него сейчас)

да про прометей речь
спасибо

я смотрю просто на примеры и вижу, что трафик например, меряют как Gauge хотя можно же интерпретировать его показания и как счетчик количества отданных/принятых байт со времени старта сервиса?

node_exporter считает counter как раз: node_network_receive_bytes и node_network_transmit_bytes

# HELP node_network_receive_bytes_total Network device statistic receive_bytes.
# TYPE node_network_receive_bytes_total counter
node_network_receive_bytes_total{device="br-4fe7b92ccc42"} 2.1829778e+07
node_network_receive_bytes_total{device="docker0"} 3.111547025e+09

понял, спасибо

Хотя остался один вопрос, что кроме температуры, еще должно быть Gauge? )

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

текущее количество можно из counter получить, не так ли?

а вот время рендера страницы - что это?
а время наступления события DomContentLoaded на клиенте?

каунтер может только расти, а текущее количество может и падать (ночью например)

время рендера страницы это гистограмма (или саммари), время до наступления DomContentLoaded - тоже гистограмма

т.к. температура или текущее потребление памяти - общее на всех скалярное значение, а лейтенси конкретной операции у каждого своя и ее нужно аггрегировать

но ведь rate(counter) отображает текущее значение счетчика в определенный момент, верно?

rate - это дифференциал, производная по времени - так rate(request_count)[interval] это скорость поступления запросов, но не их количество

т.е. totalRequests counter не поможет мне понять сколько запросов в секунду у меня обрабатывает сервер, для этого нужен gauge activeRequests - правильно я понял?

totalRequest каунтер как раз для этого, это монотонно возрастающий скаляр подходящий для функции rate - количество выполненных запросов в секунду

activeRequests может быть gauge но с другим смыслом - количество запросов в обработке (начатых, но не законченных)

с этим вроде понятно спасибо!

остались еще вопросы по временным метрикам - если известно что очень широкий разброс временных характеристик - как подобрать корзину временных интервалов для histogramm?

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

или для таких случаев лучше использовать summary?

Если сомневаетесь всегда каунтер

Суммари лучше использовать для алертинга. Для дом контентлоадед лучше логировать все результаты и строить по ним. Можно ещё брать для такого не промовские гистограммы а из Виктории.

Спасибо

Всегда гистограмма с большим количеством бакетов)

Проблема summary - их нельзя агрегировать