Scrape-интервалы и прочие грабли

Завершающий урок про выбор scrape-интервалов и сборник типичных граблей мониторинга.

scrape_interval — частота опроса целей; он влияет и на детализацию графиков, и на объём данных, и на корректность rate() и алертов.

Кажется, что мелочь, но именно неудачные интервалы дают «дырявые» графики, ложные алерты и раздутый диск. Сведём правила выбора воедино.

Как выбрать интервал

Слишком частый scrape множит объём данных и нагрузку, слишком редкий — теряет детали и опаздывает с алертами. Разумная отправная точка — 15–30 секунд для большинства сервисов и более редкий интервал для медленно меняющихся целей.

Правило интервала в rate

Диапазон в rate() должен быть минимум в 4 раза больше scrape_interval, иначе на части шагов в окно попадёт слишком мало точек и появятся пропуски.

# при scrape_interval=15s
rate(metric[15s])   # плохо: всего ~1 точка, пропуски
rate(metric[1m])    # хорошо: ~4 точки в окне

Согласование с for в алертах

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

Как работает под капотом

Каждый scrape ставит точку с меткой времени. Функции вроде rate() аппроксимируют наклон по точкам внутри окна и экстраполируют на края. Если точек в окне одна-две, наклон считать не из чего — отсюда пустоты. Поэтому окно rate(), scrape_interval и шаг отрисовки графика в Grafana нужно согласовывать между собой.

scrape_interval = 15s
   |  |  |  |  |  |   <- точки каждые 15с
   [-------- 1m -------]  <- окно rate(): 4 точки, наклон считается надёжно

Сводка типичных граблей

• Кардинальность — главный убийца памяти (см. прошлый урок).
• Слишком короткое окно rate() относительно scrape_interval — пропуски на графиках.
• Алерты без for — шквал ложных срабатываний.
• Публичный /metrics — утечка внутренней информации.
• Вечное хранение в локальном TSDB — для долгого хранения нужны внешние системы.
• Метрики, не отражающие опыт пользователя — зелёные графики при недовольных пользователях.

Частые ошибки

• Один интервал на всё. Медленные хост-метрики не нужно скрейпить так же часто, как горячий сервис.
• Менять scrape_interval, забыв про окна rate(). Запросы с фиксированным [5m] могут «поплыть».
• Игнорировать пропущенные scrape. Сетевые сбои дают дыры; закладывайте запас в for.

Итог

• 15–30 секунд — разумная отправная точка для scrape_interval.
• Окно rate() берите минимум вчетверо больше интервала.
• Главные грабли: кардинальность, короткие окна, алерты без for и вечное хранение.