Суть Читайте реальные запросы PromQL, отчёт PSI и сниппеты инструментирования; предсказывайте поведение и выбирайте фикс с наибольшим рычагом, который senior-инженер делает первым.
Высота — путь к senior
НольJuniorMiddleSenior
Ты на senior-высоте — в орбите
◷ 14 min
Проблемы RED и USE диагностируются чтением запросов и отчётов ядра, а не пересказом определений. Прочитайте каждый сниппет, предскажите, что он на самом деле вычисляет или экспонирует, и выберите фикс, к которому senior-инженер тянется первым.
Цель
Отработайте цикл чтения любого триажа: разобрать PromQL или строку PSI, заметить тихий дефект (выпавший label, измерение с высокой cardinality, неправильную агрегацию) и потянуться к верному исправлению.
Панель дашборда использует это для p99 по всему флоту и показывает плоскую подозрительную линию. Что не так и каков фикс?
Heads-up Размер окна — отдельная настройка; 5m нормально. Дефект — пропущенный by (le): без него у histogram_quantile нет вектора бакетов для интерполяции.
Heads-up Агрегация счётчиков по бакетам по репликам — это ровно то, для чего гистограммы, но только при группировке by le. Запрос сломан пропущенной группировкой, а не идеей агрегации.
Heads-up Схлопнутый sum без by (le) даёт бессмысленный результат, а не настоящий стабильный p99. Подсказка — выпавший label le, который histogram_quantile требует.
MemAvailable на этом хосте показывает 600 МБ свободно. Читая отчёт PSI, что происходит и какого уровня алерта это заслуживает?
Heads-up PSI full на 9% прямо это опровергает. MemAvailable показывает то, что свободно сейчас, а не давление reclaim; весь смысл юнита в том, что PSI full может быть высоким, пока free-RAM выглядит здоровым.
Heads-up Всё наоборот: 'full' (все не-idle задачи застопорены) — более серьёзный сигнал и именно page-grade. Memory full, устойчиво выше нуля, требует немедленного пейджа.
Heads-up avg10 на 9% full — это живой сигнал; более низкий avg300 лишь значит, что crunch свежий и нарастает. Вы действуете по короткооконному давлению, а не по остывшему длинному среднему.
Этот счётчик Errors для RED проходил ревью, пока баговый релиз не утроил счёт за метрики за ночь и не вызвал тикет по безопасности. Назовите обе проблемы и единственный фикс.
Heads-up Шаблоны method и route ограничены и actionable — им место на метрике. Неограниченное, несущее PII измерение — это error_message; именно его надо убрать.
Heads-up Инкременты счётчика по сути бесплатны. Хостинговые бэкенды берут плату за активную серию, и убивают уникальные значения error_message, а не число инкрементов.
Heads-up Интервал scrape не влияет на число серий, а утечка PII остаётся. Высокая cardinality и чувствительное содержимое — в логах/трейсах, не в label метрики.
Для сервиса с SLO p99 под 200 мс и трафиком, кластеризующимся между 50 и 250 мс, почему эти дефолтные бакеты — проблема и каков лучший выбор?
Heads-up Одиннадцать границ le — нормальное дешёвое число серий, число бакетов здесь не драйвер стоимости. Проблема — в размещении бакетов: нет разрешения там, где реально живёт SLO.
Heads-up Точность полностью зависит от плотности бакетов около нужного перцентиля. С одним бакетом, покрывающим 100-250 мс, интерполированный p99 — по сути догадка по всему этому диапазону.
Heads-up Среднее маскирует именно тот хвост, ради которого существует SLO — регрессия может толкнуть p99 с 200 до 800 мс, пока среднее едва двинется. Исправьте бакеты (или перейдите на native), а не отказывайтесь от перцентилей.
Итог
Каждый инцидент RED+USE читается в запросах и отчётах: histogram_quantile требует sum by (le), иначе возвращает мусор; PSI memory full выше нуля — это page-grade crunch, даже когда MemAvailable выглядит здоровым; label для RED должны быть ограниченными классами ошибок, никогда не несущим PII свободным текстом; а границы бакетов должны охватывать SLO с реальным разрешением (или используйте native histograms). Прочитайте сниппет, найдите тихий дефект, затем сделайте ограниченный, сохраняющий корректность фикс.