fix(observability): cadvisor перестаёт сканировать overlay-слои — упирался в лимит памяти #3135

Merged

lekss361 merged 1 commit from fix/3078-cadvisor-disk-metrics into main

2026-08-27 10:53:32 +00:00

lekss361 commented

2026-08-27 10:52:19 +00:00

Owner

Замечено владельцем, подтверждено метриками за сутки.

Замер

Хост	Динамика `container_memory_working_set_bytes`
продуктовый	21 → 165 МиБ (стабильно много часов) → после перезагрузки 305 → 359 МиБ из 384 = 93 % лимита
инфраструктурный	105 МиБ стабильно → за два часа 228 → 291 МиБ

До OOM не дошло — на продуктовом откатилось к 212 МиБ. Но запас оставался 25 МиБ, и на инфраструктурном рост продолжается.

Причина — в собственном логе cadvisor

fsHandler.go:135] fs: disk usage and inodes count on following dirs took 1.35s: [/var/lib/docker/rootfs/overlayfs/2d455f…]
fsHandler.go:135] fs: disk usage and inodes count on following dirs took 1.85s: [/var/lib/docker/rootfs/overlayfs/f75c85…]

Обход overlay-слоёв docker на каждом цикле housekeeping. Память растёт вместе с числом слоёв — а слои копятся от сборок образов, то есть тем быстрее, чем активнее идёт разработка. Отсюда и скачок именно сегодня: за день собрано много образов.

Что отключается и что при этом теряется

Добавлены disk,diskIO к уже отключённым метрикам.

Теряем использование диска по контейнерам. Проверено, что их не использует никто: ни правила Prometheus, ни дашборды (grep container_fs_ / container_blkio по ops/metrics/ — пусто).

Алерты по диску — DiskSpaceLow, DiskSpaceCritical, DiskWillFillIn24h — построены на node_exporter, на уровне файловой системы хоста. Это и есть нужное измерение: кончающееся место видно именно там, а не в разбивке по контейнерам.

Не тронуты CPU, память, сеть и рестарты контейнеров — на них держатся ContainerRestartLoop и ContainerNearMemoryLimit.

Почему не просто поднять лимит

Подъём лимита отложил бы проблему: расход растёт от числа слоёв, а не стоит на месте. Сначала убираем то, что этот расход создаёт и чем никто не пользуется; если после выката память всё равно поползёт — тогда лимит, уже осознанно.

Проверю расход после деплоя и отпишусь.

Refs #3078, #3030

Замечено владельцем, подтверждено метриками за сутки. ## Замер | Хост | Динамика `container_memory_working_set_bytes` | |---|---| | продуктовый | 21 → 165 МиБ (стабильно много часов) → после перезагрузки **305 → 359 МиБ из 384** = **93 % лимита** | | инфраструктурный | 105 МиБ стабильно → за два часа **228 → 291 МиБ** | До OOM не дошло — на продуктовом откатилось к 212 МиБ. Но запас оставался **25 МиБ**, и на инфраструктурном рост продолжается. ## Причина — в собственном логе cadvisor ``` fsHandler.go:135] fs: disk usage and inodes count on following dirs took 1.35s: [/var/lib/docker/rootfs/overlayfs/2d455f…] fsHandler.go:135] fs: disk usage and inodes count on following dirs took 1.85s: [/var/lib/docker/rootfs/overlayfs/f75c85…] ``` Обход overlay-слоёв docker на каждом цикле housekeeping. Память растёт вместе с числом слоёв — а слои копятся от сборок образов, то есть **тем быстрее, чем активнее идёт разработка**. Отсюда и скачок именно сегодня: за день собрано много образов. ## Что отключается и что при этом теряется Добавлены `disk,diskIO` к уже отключённым метрикам. **Теряем использование диска по контейнерам.** Проверено, что их не использует никто: ни правила Prometheus, ни дашборды (`grep container_fs_ / container_blkio` по `ops/metrics/` — пусто). Алерты по диску — `DiskSpaceLow`, `DiskSpaceCritical`, `DiskWillFillIn24h` — построены на `node_exporter`, на уровне файловой системы хоста. Это и есть нужное измерение: кончающееся место видно именно там, а не в разбивке по контейнерам. **Не тронуты** CPU, память, сеть и рестарты контейнеров — на них держатся `ContainerRestartLoop` и `ContainerNearMemoryLimit`. ## Почему не просто поднять лимит Подъём лимита отложил бы проблему: расход растёт от числа слоёв, а не стоит на месте. Сначала убираем то, что этот расход создаёт и чем никто не пользуется; если после выката память всё равно поползёт — тогда лимит, уже осознанно. Проверю расход после деплоя и отпишусь. Refs #3078, #3030

lekss361 added 1 commit 2026-08-27 10:52:20 +00:00

fix(observability): cadvisor перестаёт сканировать overlay-слои — упирался в лимит памяти

CI Trade-In / changes (pull_request) Successful in 10s

Details

CI Trade-In / backend-tests (pull_request) Has been skipped

Details

CI Trade-In / browser-tests (pull_request) Has been skipped

Details

CI Trade-In / frontend-checks (pull_request) Has been skipped

Details

CI / backend-tests (pull_request) Has been skipped

Details

CI / openapi-codegen-check (pull_request) Has been skipped

Details

CI / changes (pull_request) Successful in 12s

Details

CI / frontend-tests (pull_request) Has been skipped

Details

668f15913d

Замер по метрикам за сутки:

  продуктовый хост:  21 → 165 МиБ (стабильно) → после перезагрузки 305 →
                     359 МиБ из 384, то есть 93 % лимита
  инфраструктурный:  105 МиБ стабильно → за два часа 228 → 291 МиБ

До OOM не дошло, но запас оставался 25 МиБ. Причина видна в собственном
логе cadvisor: «fs: disk usage and inodes count on following dirs took
1.3-1.8s» — обход overlay-слоёв docker на каждом цикле housekeeping.
Память растёт вместе с числом слоёв, а слои копятся от сборок образов,
то есть тем быстрее, чем активнее идёт разработка.

Отключаем disk/diskIO. Теряем использование диска ПО КОНТЕЙНЕРАМ —
проверено, что этих метрик не используют ни правила Prometheus, ни
дашборды: алерты по диску (DiskSpaceLow / DiskSpaceCritical /
DiskWillFillIn24h) построены на node_exporter, на уровне файловой системы
хоста. Это и есть нужное измерение — кончающееся место видно именно там,
а не в разбивке по контейнерам.

Остальные метрики контейнеров (CPU, память, сеть, рестарты) не тронуты:
на них держатся ContainerRestartLoop и ContainerNearMemoryLimit.