Gauge-метрика: что это и как применять в Go

После счётчиков мир выглядит неудобно: не всё в системе растёт. Очередь задач то пустеет, то переполняется; память то освобождается, то кончается; пользователи заходят и выходят. Для таких величин у Prometheus есть Gauge — датчик текущего значения. Он обязан быть скучным на фоне драмы с рестартами счётчиков: gauge просто хранит число, которое вы записали последним, и отдаёт его при каждом скрейпе. Сложность gauge не в механике, а в дисциплине: нужно вовремя писать актуальное значение и не пытаться мерить им то, что только растёт. В уроке — NewGauge и все методы, два живых примера: очередь, которая обновляется событиями, и число задач из базы, которое синхронизируется таймером.

Создание зеркально счётчику: prometheus.NewGauge со структурой GaugeOpts из Name и Help. Name — snake_case без суффикса _total: он зарезервирован за счётчиками, и его отсутствие на датчиках — часть конвенции. Регистрация всё та же prometheus.MustRegister, один раз при старте. Дальше четыре метода, и у каждого своя семантика. Set записывает абсолютное значение — это главный метод gauge, им вы говорите «сейчас значение равно вот этому». Inc и Dec — плюс и минус единица для событий: задачу взяли, задачу отдали. Add и Sub меняют значение на произвольную величину с любым знаком: в отличие от счётчика убывание здесь законный основной сценарий. Все методы потокобезопасны — под нагрузкой из горутин значение не порвётся, хотя логику «кто и когда обновляет» библиотека за вас не придумает.

Инцидент, после которого в нашей команде появилось правило «проверяй ноль». В обработчике платежей датчик shop_payments_pending инкрементился на входе и уменьшался на выходе — всё сходилось, пока не появился ранний выход: при невалидной карте функция возвращалась до Dec, и значение навсегда оставалось завышенным на единицу. За три месяца таких выходов набралось сорок: график «в очереди сорок платежей» превратился в константу, на которую никто не смотрел, а настоящий застой очереди заметили по жалобам, а не по метрике. Ловушка в том, что gauge честен ровно настолько, насколько симметричны пары Inc и Dec. Противоядия три: уменьшение в defer, как учит урок про отложенные вызовы; сборка значения из источника правды Set-ом вместо парных вызовов; периодическая сверка с базой. С третьим способом график иногда рисует ступеньку вниз — это не баг, это правда о том, что датчик раньше врал.

Разберём типовую коллекцию. Встроенные метрики, которые вы видели в третьем уроке, по большей части — gauge: go_goroutines — число горутин сейчас, go_memstats_heap_inuse_bytes — занятая куча, process_open_fds — открытые дескрипторы. Это подсказка: если метрика отвечает на вопрос «сколько сейчас», в вашем коде, вероятно, тоже нужен gauge. Собственные датчики типового веб-сервиса: in-flight запросы — сколько обрабатывается прямо сейчас; размер кэша в объектах и в байтах; число активных сессий или WebSocket-соединений — для real-time у нас есть отдельный курс; глубина пула соединений к базе; заполненность дисковой партиции в процентах. Общий признак: значение имеет смысл только в моменте, а ноль — не пустая история, а честное «пусто сейчас».

Соблазн велик: «заказов всего» растёт, значит поставлю gauge и буду Set-ить накопленное. График будет выглядеть правдоподобно ровно до первого вопроса о скорости: у gauge нет понятия сброса при рестарте, поэтому после деплоя линия резко упадёт с сорока тысяч до пяти и так же резко ляжет в новый рост — график честно нарисует гору, которая ничего не означает. rate по gauge не считают: этот запрос рассчитан на монотонность счётчика, и алерты по скорости тоже не построить. Растущее значение — counter, и это не вкусовщина: тип определяет, на какие вопросы метрика умеет отвечать. Обратная ошибка мягче: убывающая величина в counter либо паникует при попытке уменьшения, либо заводится как разность двух счётчиков на уровне запросов — работает, но зачем, если есть gauge.

Типичная ошибка интерпретации датчика начинается после деплоя. График активных сессий падает почти в ноль и снова растёт: половина команды читает «пользователи ушли и вернулись», хотя правдивое чтение — процесс перезапустился, память очистилась, а Set при старте никто не поставил. Отличить одно от другого просто: след рестарта совпадает с моментом выката на графике выкладок, а поведение пользователей так синхронно не ходит. Второе чтение той же ямы — «сервис потерял данные»: если датчик отвечает за очередь, яма выглядит как «очередь разобрана», и все радуются, хотя очередь просто перестала быть видимой. Лечится двумя строками: при старте выставлять актуальное значение из источника правды и держать в дашборде вторую серию — время жизни процесса. Когда обе линии прыгают одновременно, вы смотрите на рестарт, а не на бизнес; лечится это не перезапуском, а инициализацией.

Вариация примера, которую я использую чаще всего: гибрид двух моделей. События двигают датчик Inc и Dec для мгновенной реакции, а фоновая сверка раз в минуту выставляет Set из источника правды, исправляя накопленный дрейф: пропущенный Dec в редкой ветке перестаёт быть вечной ошибкой и превращается в минутную. Спорная сторона гибрида — двойная логика: читатель метрики должен знать, что значение может прыгнуть на сверке, и не искать в этот момент аварию. Моё правило: для короткоживущих сущностей с чёткими входами и выходами хватит чистых Inc и Dec; для долгоживущих состояний с редкими нештатными ветками гибрид честнее. А если источник правды сам дешевле события — например, длина очереди уже хранится в Redis — берите чистую синхронизацию и не поддерживайте два механизма одновременно.

Gauge отдаёт значение в момент опроса: если пик длился две секунды между скрейпами по пятнадцать — Prometheus его никогда не увидит. Для большинства метрик это нормально: очередь длиной десять тысяч, а через две секунды пустая, — событие, а не состояние, и для событий есть счётчики и логи. Но знать про слепые окна надо, иначе вы будете искать «пик, который точно был» по графику, где его физически нет. Вторая особенность — усреднения: avg_over_time по датчику показывает среднее по точкам скрейпа, и результат зависит от интервала. Спорное мнение из практики: in-flight запросы я предпочитаю мерить gauge-ом в middleware, а не вычислять из счётчиков разностью — датчик честен в моменте и не требует бережного обращения с рестартами.