Четыре типа метрик: Counter, Gauge, Histogram, Summary

Counter — счётчик, который может только расти и сбрасывается в ноль при рестарте процесса: запросы, ошибки, обработанные байты. Gauge — датчик текущего значения, который двигается в обе стороны: длина очереди, занятая память, активные сессии. Histogram — распределение: каждое измерение падает в заранее заданные бакеты, из которых уже на стороне Prometheus считаются доли и перцентили — про латентность и размеры. Summary — второй способ считать квантили, но на стороне клиента: сервис сам агрегирует наблюдения и отдаёт готовые квантильные значения. Первые два типа — про «сколько всего» и «сколько сейчас», третий и четвёртый — про «как распределено». Типичный сервис на Go большую часть времени живёт на Counter и Histogram: рост и латентность — главные сигналы здоровья; Gauge добавляется под очереди и пулы, Summary — точечно. Дальше по карте — два самых ходовых типа в деталях, а гистограммы с summary получат собственные уроки после темы лейблов.

Разницу удобно держать в голове через пару «пробег автомобиля» и «спидометр». Counter — пробег: число с запуска, убывать не может физически, даже когда события закончились, значение просто стоит на месте. Gauge — спидометр: сейчас сто двадцать, через минуту ноль, и оба показания честные. Отсюда рабочая проверка при выборе типа: спросите себя, что означает ноль. Для счётчика ошибок ноль — «с запуска ошибок не было», нормально. Для числа активных пользователей ноль — «прямо сейчас никто не онлайн», тоже нормально, но смысл другой: это состояние, а не накопление. Самая живая ловушка — рестарт: счётчик обнуляется, датчик начинает с того, что вы в него записали. Prometheus знает про поведение счётчика и в запросах умеет склеивать сбросы; датчику склейка не нужна — у него нет истории, есть момент. Итого: растущее — Counter, текущее состояние — Gauge, и никогда наоборот.

Ошибка интерпретации, на которой я ловлю почти каждого новичка. Счётчик запросов рисуют сырым значением: линия ползёт вверх, после деплоя падает в ноль и снова растёт. Человек, привыкший к датчикам, читает это как «трафик упал до нуля и восстановился» — и начинается поиск аварии, которой не было. На деле провал в ноль — рестарт процесса, а скорость по такой линии на глаз не оценить: рост с тысячи до двух тысяч за сутки и за год выглядит одинаково круто. Правильная картинка — прирост: в PromQL это rate, который сглаживает и сбросы, и рваный ритм событий. Пока PromQL не изучен, держите простое правило: сырое значение счётчика годится для лога, для графика — только скорость. Тот же принцип встретите у гистограмм: сырые бакеты там тоже никто не рисует, рисуют доли и квантили.

Гистограмма не хранит каждое измерение — это разорвало бы кардинальность. Вместо этого вы заранее задаёте бакеты, пороги времени: сто миллисекунд, двести, пятьсот, секунда, две, пять. Каждое наблюдение увеличивает счётчики бакетов, чей порог превышен: ответ за триста миллисекунд добавит единицу в бакеты пятьсот, секунду, две и пять. Плюс копятся сумма и число наблюдений. Красота схемы в том, что клиентская часть дёшево стоит, а математика происходит в Prometheus: из накопленных бакетов считается, какая доля запросов быстрее порога, и оцениваются перцентили — медиана и девяносто девятый. Цена — приближённость: значение p99 вычисляется по границам бакетов, и при плохом выборе порогов оценка плывёт. Зато гистограммы агрегируются между инстансами: суммировать бакеты двадцати подов — нормальная операция. Это делает histogram выбором по умолчанию для латентности HTTP — в седьмом уроке соберём её руками и подберём бакеты.

Summary решает ту же задачу, что гистограмма, но с другой стороны: сервис сам держит скользящее окно наблюдений и отдаёт готовые квантили — скажем, медиану и девяносто девятый перцентиль — просто числами. Плюс честный: значение квантиля точнее, чем оценка по бакетам, и пороги угадывать не надо. Минус один и жирный: квантили нельзя агрегировать. Медиана двух подов — не сумма медиан, и Prometheus не может собрать p99 по кластеру из summary двадцати инстансов; каждая метрика замыкается на своём процессе. Плюс окно квантилей зашито в конфигурацию клиента и не меняется на лету. Поэтому в типичном Go-сервисе summary занимает нишу точечных метрик одного процесса — скажем, латентность внутреннего вызова конкретного инстанса, — а для HTTP-латентности и всего, что надо смотреть по кластеру, выбирают histogram. Сравнение с кодом и выводами — в восьмом уроке, где оба типа лягут рядом.

Спорное мнение, к которому я пришёл после пары лет с квантилями: в прикладном Go-сервисе summary почти не нужен. Его честные аргументы — точный квантиль и отсутствие подбора сетки — звучат весомо, пока сервис один. Но практически каждый сервис, доживший до успеха, обрастает вторым инстансом: горизонтальное масштабирование, выкатка в два региона, canary-релиз. С этого момента клиентские квантили замыкаются в себе, рядом всё равно появляется гистограмма, и два типа для одной величины содержать дороже, чем один. Граница, при которой я меняю мнение: фоновый процесс без горизонтального масштабирования и с тяжёлым, плохо предсказуемым хвостом — там summary с одной целью и окном MaxAge действительно проще, чем угадывать бакеты. Встроенный go_gc_duration_seconds к спору не относится: его писали не мы, и убрать его из реестра никто не просил.