Боевые сообщения в Telegram 12.09:
«apps / tradein-browser: 2.684e+11% от mem_limit. Дальше OOM-kill.»
«apps / listings: доля HOT 75.21%.» — при пороге срабатывания «доля < 20%»
Причина общая и она про ФОРМУ выражения, а не про условие: в PromQL `A and B`
возвращает ЗНАЧЕНИЯ ЛЕВОЙ части, отфильтрованные правой. В `$value` попадало A:
- ContainerNearMemoryLimit: слева стоял `container_spec_memory_limit_bytes` —
в сообщение уходил лимит в байтах (2 684 354 560), отрендеренный как
процент. Замер 12.09: настоящее потребление того контейнера — 1.2 % лимита.
- PostgresLowHotUpdateRatio: слева стоял `rate(tup_upd[6h])` — апдейтов в
секунду. Это опаснее: 0.7521 превращалось в «75.21%», попадало в
правдоподобный диапазон и противоречило собственному порогу, но выглядело
настоящим числом. Замер 12.09 по listings: rate(tup_upd[6h]) = 0.0411 →
сообщение сказало бы «4.11%», настоящая доля HOT = 0.00%.
Условия срабатывания в обоих случаях были ВЕРНЫ — врал только текст, поэтому
дефект и прожил незамеченным.
Правка: отношение вынесено влево, а побочное условие — внутрь знаменателя
(`X / (Y > 0)`), где оно и фильтрует серии, и защищает от деления на ноль.
Проверено на живом Prometheus (только чтение): новое выражение памяти отдаёт
доли 0.35–0.71 (топ — gendesign-infra-postgres 70.8 %), новое выражение HOT —
доли 0.00–1.00. `promtool check rules` — SUCCESS, 16 rules.
Третье правило того же семейства (PostgresDeadTuplesHigh) верно, но верно
случайно: печатаемая величина совпала с левым операндом. Помечено комментарием,
чтобы его не «причесали» по образцу двух других.
Гейт: backend/tests/ops/test_alert_value_is_the_described_quantity.py — если
описание рендерит `$value` как долю (`humanizePercentage`), левая часть
выражения обязана содержать деление. Фальсификация: вернул файл правил с
origin/main → красные test_percentage_annotations_come_from_a_ratio и
test_known_two_rules_are_fixed; с правкой — 3 passed.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
