В этом материале
Counter может сброситься при restart, поэтому разницу сырых значений нельзя безусловно считать скоростью. В PromQL применяйте rate к отдельным рядам до sum. Иначе перезапуск одной реплики способен скрыться внутри общей суммы и исказить результат.
Counter может сброситься при restart, поэтому разницу сырых значений нельзя безусловно считать скоростью. В PromQL применяйте rate к отдельным рядам до sum. Иначе перезапуск одной реплики способен скрыться внутри общей суммы и исказить результат.
Подтвердите тип метрики
Сохраните имя, HELP/TYPE из exposition и смысл измеряемой величины. Counter накапливает события, gauge может свободно расти и уменьшаться. Rate предназначен для counter; применение к gauge способно выдать бессмысленную интерпретацию обычного падения значения как reset. Суффикс total помогает, но не заменяет проверку реализации exporter. Убедитесь, что series labels действительно соответствуют независимым экземплярам, иначе смешивание нескольких источников уже нарушило смысл ряда до выполнения PromQL.
Сохраните границу рестарта
Сопоставьте raw samples с временем restart процесса и identity instance. При сохранении labelset новый процесс может начать counter с нуля. При смене labels появится другая серия, а старая станет неактуальной по своим правилам. Эти сценарии выглядят по-разному и требуют отдельного чтения. Prometheus rate учитывает нарушения монотонности как resets и экстраполирует в пределах окна; единичное число не следует принимать за точную побитовую историю всех событий между scrape.
Разберите две реплики
В учебном примере у одной реплики counter падает с 100 до 0 после restart, у другой продолжает расти. Если сначала сложить значения, рост второй может частично скрыть сброс первой. Sum(rate(counter[5m])) сохраняет анализ каждого исходного ряда до агрегации. Пятиминутное окно служит примером синтаксиса, а не универсальной настройкой. Выбор окна зависит от scrape frequency и того, какой временной масштаб нужен наблюдателю.
| Проверка | Зачем нужна |
|---|---|
| Raw counter | Видны исходные значения |
| Resets за окно | Обнаружены падения отдельных рядов |
| Rate каждого instance | Сохранена граница reset |
| Sum после rate | Получена осмысленная общая скорость |
Исправьте выражение адресно
Сначала проверьте запрос без агрегации и оставьте нужные labels. Затем примените sum по выбранной области. Не удаляйте instance до вычисления rate и не заменяйте counter произвольным абсолютным difference. Если exporter перезапускается часто, выясните причину отдельно: исправленная формула не устраняет crash loop. Пропуски scrape и короткие окна также влияют на результат. Сохраните исходный expression, чтобы изменение dashboard можно было объяснить без утверждения, что все прежние значения были точными.
Проверьте контролируемый restart
На тестовом exporter создайте известный поток событий, перезапустите одну реплику и сравните raw values, resets и обе формы запроса. Артефакт должен показывать ожидаемую интерпретацию, а не вымышленный benchmark. Повторите опыт после смены label policy. Эта статья касается эксплуатационных скоростей и наблюдаемости, а не денежных расчётов usage: Prometheus counter и интерполяция rate сами по себе не задают договорный учёт токенов. Сохраняйте эту границу при использовании графика в отчёте.
Связанные разборы: gpu monitoring scorecard; model update canary.