Какие типы метрик есть в Prometheus и для чего они используются

Что проверяют

Знаете ли вы четыре типа метрик не по названиям, а по тому, какой выбрать под задачу в Go-сервисе. Почти всегда следом спрашивают, чем Histogram отличается от Summary и как посчитать 99-й перцентиль задержки по всем подам.

Как отвечать

Каждый тип опишите через client_golang:

• Counter: только растёт и сбрасывается при рестарте процесса. Запросы, ошибки, отправленные сообщения. Смотрят не на значение, а на rate() или increase(), которые сами учитывают сбросы. Имя по соглашению заканчивается на _total;
• Gauge: текущее значение, которое ходит вверх и вниз: длина очереди, число горутин, открытые соединения. Методы Set, Inc, Dec;
• Histogram: раскладывает наблюдения по бакетам и отдаёт серии _bucket{le="..."}, _sum и _count. Перцентиль считается на сервере через histogram_quantile(), поэтому гистограммы разных инстансов можно суммировать. prometheus.DefBuckets рассчитаны на секунды, под свою задержку бакеты лучше задать самим;
• Summary: квантили считаются в самом процессе по скользящему окну и задаются полем Objectives. Серверу дёшево, но квантили разных подов нельзя сложить или усреднить.

Вывод для ответа: для задержек в распределённом сервисе почти всегда Histogram, Summary остаётся для точного квантиля одного процесса. Плюсом будут нативные гистограммы с автоматическими бакетами, в HistogramOpts для них есть NativeHistogramBucketFactor.

Добавьте про метки: NewCounterVec с лейблами method и status, время в секундах, а не в миллисекундах.

Где спотыкаются

Кладут в лейбл user_id, URL с параметрами или текст ошибки. Каждое значение порождает новый временной ряд, и Prometheus захлёбывается по памяти.

Усредняют p99 из Summary по всем подам и получают число, которое ничего не значит.

Считают запросы через Gauge или строят график по сырому значению Counter. После рестарта пода на графике провал, а rate() над Gauge выдаёт мусор.