fix(stand): поправлены находки ревью — причина дрейфа памяти и отзыв довода ADR 0001

Зачем

Двухосевое ревью нашло в PR фактическую ошибку и одну процессную дыру. Ошибка
того же класса, что уже снималась по ходу разбора: в ADR было записано, будто
RSS ноды полз вверх из-за страниц её бинарника. Замер на живой ноде это
опроверг.

Что

- ADR 0004: причина дрейфа переписана по замеру. За обычную сессию страницы
  бинарника 523 -> 531 МиБ, то есть стоят на месте, а рабочая память
  489 -> 723 МиБ. Бинарник объясняет постоянную часть расхода, а не рост;
  отчего растёт рабочая память, для этого решения знать не нужно. Вывод не
  меняется: одна только постоянная часть занимала больше половины гигабайтной
  коробки.
- ADR 0001: ресурсный довод отозван прямо в файле — и строкой статуса, и
  абзацем после самого довода. Обе оси ревью нашли это независимо друг от
  друга: строка «удерживает стенд в пределе 3,4 ГБ» читалась как действующая,
  хотя предела уже нет.
- stand-smoke.sh: OOMKilled поднимается и тогда, когда ядро убило процесс
  внутри живого контейнера, поэтому сообщение говорит про процесс, а не про
  контейнер. Флаг hurt переименован в problems и считает находки — как passed
  и failed по соседству.
- Формулировки ADR 0004 упрощены: «коробка» объясняется при первом упоминании,
  а метафоры «вход в самонастройку», «предохранители», «бронь», «полка» и
  «бюджет в новой одежде» заменены обычными словами. Правило AGENTS.md —
  сложную мысль пояснять при первом упоминании.

Проверка

make config-test — зелено. make smoke — 25 из 25, проверка выживания отработала
с новым сообщением.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

docs/adr/0001-stand-services.md

@@ -1,6 +1,7 @@
 # ADR 0001. Сервисы каркаса стенда
 
-Дата: 30 июля 2026 года. Статус: принято.
+Дата: 30 июля 2026 года. Статус: принято; ресурсный довод отозван
+[ADR 0004](0004-resource-limits.md).
 
 ## Решение
 
@@ -50,6 +51,13 @@ Prometheus читает встроенные точки метрик двух с
 компьютера. Отказ от triggerer, второго Postgres и внешних сборщиков удерживает
 стенд в пределе 3,4 ГБ.
 
+Ресурсный довод предыдущего абзаца отозван
+[ADR 0004](0004-resource-limits.md): предела 3,4 ГБ у стенда нет, вместо него
+объявлено требование к машине. Сами решения остаются в силе по остальным
+основаниям, названным выше. Отказ от внешних сборщиков вдобавок частично
+пересмотрен [ADR 0002](0002-monitoring-scope.md): сборщик метрик Kafka нужен
+ради отставания чтения.
+
 Тома `clickhouse_*_data` хранят данные keeper и двух нод ClickHouse.
 `kafka_data`, `postgres_metadata_data`, `superset_home`, `prometheus_data` и
 `grafana_data` хранят состояние своих сервисов. `airflow_logs` хранит журналы,

docs/adr/0004-resource-limits.md

@@ -13,12 +13,13 @@
 Проверка суммарного потребления памяти уходит из `scripts/stand-smoke.sh`.
 Вместе с ней уходят зависящая от её сообщения проверка в `tests/docs-guards.sh`
 и описание порога в README. Взамен `make smoke` спрашивает у Docker, не убивало
-ли ядро какой-нибудь долгоживущий контейнер за нехватку памяти и не включалась
-ли политика перезапуска. Это не бюджет в новой одежде: порога у проверки нет,
-она отвечает «да или нет».
+ли ядро что-нибудь в долгоживущих контейнерах за нехватку памяти и не включалась
+ли политика перезапуска. Прежний бюджет она не заменяет: числа, с которым
+что-то сравнивают, у неё нет вовсе — ответ либо «убивало», либо «нет».
 
-Нодам ClickHouse — по 4 ГиБ вместо гигабайта. Остальные `mem_limit` не
-меняются.
+Нодам ClickHouse — по 4 ГиБ вместо гигабайта. Дальше в этом тексте предел
+памяти контейнера (`mem_limit`) называется коробкой: сервер живёт внутри неё и
+о самой машине ничего не знает. Остальные `mem_limit` не меняются.
 
 Числа, выставленные ради прежнего бюджета, остаются в силе, но лишаются
 статуса решения: `KAFKA_HEAP_OPTS`, `shared_buffers`, `max_connections`,
@@ -51,35 +52,47 @@
 своей коробки, сумма при этом была в норме — 3181 МиБ из 3242,5, — а красным
 стенд сделал пробник. Механизм оповещения работает и без неё.
 
-Замена не возвращает бюджет через заднюю дверь. Дыра, которую она закрывает,
-другая: убитый за память контейнер Docker поднимает сам, через полминуты его
-проверка состояния снова зелёная, и `make smoke` докладывает, что всё хорошо —
-хотя нода умирала и потеряла всё, что держала в памяти. Новая проверка
-спрашивает у Docker факт, а не величину, и потому нечего подгонять и незачем
-пересматривать при росте стенда.
+Новая проверка — не тот же бюджет под другим именем. Она закрывает другую дыру:
+убитый за память контейнер Docker поднимает сам, через полминуты его проверка
+состояния снова зелёная, и `make smoke` докладывает, что всё хорошо — хотя нода
+умирала и потеряла всё, что держала в памяти. Проверка спрашивает у Docker
+факт, а не величину, поэтому её нечего подгонять и незачем пересматривать,
+когда стенд растёт.
 
 Гигабайт на ноду был неработоспособен, и причина не та, что предполагал
-issue #21. Праздная нода держит `VmRSS` 846 МиБ, из которых 530 МиБ — страницы
-её собственного бинарника: файл `clickhouse` весит 790 МБ, и ядро подгружает
-куски по мере обращения к ним. Учёта памяти в этом почти нет, `MemoryTracking`
-всего 113 МиБ, но отказ по превышению сравнивается с RSS, куда чистые страницы
-кода входят. Значит из гигабайта ноде оставалось около 350 МиБ рабочего места,
-а RSS полз вверх просто потому, что каждый новый прогон пробника трогал новый
-код: 531 → 774 МиБ за сессию. Рестарт возвращал число назад, и это выглядело
-как утечка. Заводские кэши тут ни при чём: в коробке на гигабайт ClickHouse сам
-понижает каждый до 512 МиБ, а на стенде без данных они и вовсе пусты.
+issue #21. У праздной ноды около 530 МиБ RSS — это страницы её собственного
+бинарника: файл `clickhouse` весит 790 МБ, ядро подгружает куски по мере
+обращения к ним, а отказ по превышению памяти сравнивается с RSS, куда такие
+страницы входят. Учёта сервера в них почти нет: `MemoryTracking` при этом
+всего 113 МиБ. Это постоянная часть расхода: меньше неё нода не занимает
+никогда. Из гигабайта на саму работу оставалось около 350 МиБ.
 
-Лимит для ClickHouse — не потолок, а вход в самонастройку. Сервер берёт 0,9 от
-того, что видит, под общий предел памяти и 0,5 — под размеры кэшей и пороги
-сброса на диск. Поэтому «поднять потолок ничего не стоит» верно для девяти
-сервисов, которые лимит не читают, и неверно для двух нод: от коробки зависит,
-где у них срабатывают предохранители. Снять лимит с нод по той же причине
-нельзя — без коробки каждая считает свои доли от всей машины, и память у
-машины кончится раньше, чем сервер решит экономить. Панель «не упёрлись ли
-ноды в память» из ADR 0002 тоже требует знаменателя. Сумма всех потолков после
-правки больше восьми гигабайт, и это не противоречие: `mem_limit` — потолок, а
-не бронь, Docker ничего не резервирует, в покое стенд занимает около 3,2 ГБ.
-Восемь гигабайт нужны не сумме потолков, а работе с запасом.
+Дальше нода набирает рабочую память, и вместе с постоянной частью та перестаёт
+помещаться. За обычную сессию стенда замерено: страницы бинарника 523 → 531
+МиБ, то есть стоят на месте, а рабочая память 489 → 723 МиБ. Инцидент 31 июля
+имел ту же форму — 531 → 774 МиБ: та же постоянная часть плюс наросшая работа.
+Рестарт возвращал число назад, и это выглядело как утечка. Отчего именно растёт
+рабочая память, здесь не разбирается — для решения хватает того, что одна
+только постоянная часть занимала больше половины коробки. Заводские кэши тут
+ни при чём: в коробке на гигабайт
+ClickHouse сам понижает каждый до 512 МиБ, а на стенде без данных они и вовсе
+пусты.
+
+Для ClickHouse коробка — не просто верхняя граница: сервер настраивает себя по
+её размеру. При запуске он читает её и берёт 0,9 под общий предел собственной
+памяти, а 0,5 — под размеры кэшей и под порог, после которого промежуточные
+данные запроса уходят на диск. Поэтому «поднять предел ничего не стоит» верно
+для девяти сервисов, которые своей коробки не читают, и неверно для двух нод: от
+её размера зависит, когда сервер начинает себя ограничивать. Снять лимит с нод
+по той же причине нельзя — без коробки каждая нода считает свои доли от всей
+машины, и память кончится у машины раньше, чем сервер решит экономить. Панель
+«не упёрлись ли ноды в память» из ADR 0002 без коробки тоже не работает:
+упираться становится не во что.
+
+Сумма всех пределов после правки больше восьми гигабайт, и это не противоречие.
+`mem_limit` — верхняя граница, а не резерв: Docker ничего не откладывает
+заранее, и в покое стенд занимает около 3,2 ГБ. Восемь гигабайт нужны не сумме
+пределов, а работе с запасом.
 
 Остальные девять лимитов не меняются, потому что ни один из них ни разу не
 сработал. Снять их скопом — то же изменение без свидетельств, каким они были
@@ -111,8 +124,8 @@ has limited RAM`; `cache_size_to_ram_max_ratio` = 0,5; праздный серв
 `max_bytes_ratio_before_external_sort` = 0,5. Тяжёлый `GROUP BY` в коробке не
 получает отказ, а уходит на диск и досчитывается; отказ по памяти остаётся для
 того, что на диск не сбрасывается. Учебный сюжет «тяжёлый запрос — симптом на
-графике памяти» из ADR 0002 выглядит полкой и дисковым вводом-выводом, а не
-обрывом.
+графике памяти» из ADR 0002 выглядит ровной линией у верхней границы и
+дисковой нагрузкой, а не обрывом.
 
 cgroup v2: `docker stats` показывает `memory.current` минус неактивные файловые
 страницы. На праздном контейнере — 1056 МБ при 779 МБ файловых и 234 МБ
@@ -120,8 +133,8 @@ cgroup v2: `docker stats` показывает `memory.current` минус не
 
 `apache/kafka:4.3.1`: `kafka-server-start.sh` при пустой `KAFKA_HEAP_OPTS`
 ставит `-Xmx1G -Xms1G`, а по размеру коробки кучу не подбирает. Поэтому
-переменную не убираем: без неё куча стала бы больше, а не меньше, и с нынешней
-коробкой на гигабайт это был бы прямой OOM-kill.
+переменную не убираем: без неё куча стала бы больше, а не меньше, и в нынешней
+коробке Kafka на гигабайт ядро убивало бы контейнер за нехватку памяти.
 
 На стенде с новой коробкой в 4 ГиБ то же поведение подтвердилось:
 `max_server_memory_usage` = 3,60 ГиБ, в журнале ноды `Lowered mark cache size