Всем привет. Бывают ситуации, когда процесс внутри контейнера убивается OOM'ом на

хосте.
Но при этом это был не основной процесс контейнера, и в кубе это событие вроде никак не регистрируется (pod не перезапускается, OOMKilled не показывается в статусах). Зато в логах ядра можно найти что-то вроде

[16497976.197435] oom-kill:constraint=CONSTRAINT_MEMCG,nodemask=(null),cpuset=cri-containerd-33203b8683eb11c8b1a56e5d075ccdf5a55c9592d038e766532a5e7a374095a8.scope,mems_allowed=0,oom_memcg=/kubepods.slice/kubepods-pod2f326fad_40e2_4817_8d43_da7b51daeb73.slice,task_memcg=/kubepods.slice/kubepods-pod2f326fad_40e2_4817_8d43_da7b51daeb73.slice/cri-containerd-33203b8683eb11c8b1a56e5d075ccdf5a55c9592d038e766532a5e7a374095a8.scope,task=xxxx,pid=3108415,uid=4351
[16497976.197464] Memory cgroup out of memory: Killed process 3108415 (xxx) total-vm:299620kB, anon-rss:23472kB, file-rss:35600kB, shmem-rss:0kB, UID:4351 pgtables:828kB oom_score_adj:-997

Кто как собирает и обрабатывает эти события? Пока не знаю чего конкретно хочу. Возможно обогатить этот лог мета инфой (containerName, pod, имя ns) 🤔. Возможно есть какие-то стандартные вещи для этого. Логером парсить uid, искать его в kubelet API, соденеять по pid процесса эти два лога, кажется для логера слишком сложно

Мы логи хостов как и всего остального кидаем в CloudWatch и там есть встроенный механизм алертинга

залить то не проблема. Но хотелось бы видеть что это относится к какому-то конкретному контейнеру, поду, ns

Смотря чем коллектишь. У флбентД есть парсер

у всех есть парсер, но это не логов pod'а. Это логи ядра

А у самого процесса есть мониторинг? Может стоит реагировать на up == down?

Дим, я знаю что такое оом)

Если напишешь в понедельник в личинку - дам рецепт.

Ты можешь тут дать рецепт. Это может быть всем интересно :)

Дам, но щас куи пинаю и мне лень. Так и быть тут кину позже

У флюентД есть прекрасный хак - юзать руби в парсере. И там можно творить любую дичь, юзая полноценный язык программирования(почти) :)

кароч вот https://github.com/sapcc/kubernetes-oomkill-exporter , и промеетем метрики снимаются. Загоните сударю звездочек что ль

privileged: true Как больно-то(

попробуй без

еще один заброшенный труп

О госпаде. Форкни и коммить каждый день

Да, там по метрикам это и ловлю, от процесса который запускает его. Там типо временный запускается, его грознуло, и по мтреикам видно что оно за фейлилось

заюзать ruby/lua не проблема. Но передавать доступы в этот конфиг чтобы он для определенных сообщений ходил в API куба, доставал все поды, искал с нужным uid, мне кажется прям как-то костыльно и не очень

вот что-то такое

Ну тут или шашечки или ехать 🤷‍♂

так твой reflector на C# такой-же труп, там релизы за последний год для галочки. Чисто чарт поправили и depended bot зависимости обновил. Под категорию релизов каждые 3-4 месяца оно точно не подходит. Ну и для куба, на C#, для куба, на C#, для куба на C# (меня это сломало) Поэтому такой-же труп по твоим сущностным критериям

О круто, что-то такое и искал

мне шашечки и я их нашел

по описанию - вроде ловит только ООМК подов, а не всех процессов в них

Не, всё ловит, что хотели в сабже. Сам юзаю

ключевая фраза депендабот обновляет зависимости. в чем проблема с шарпами и кубом? на самом деле прекрасно все там

А как же манипуляторы набора кода размещенные на поясе?

прикольная штука, я сначала не понял как так мало кода, и они берут это из node problem detector https://github.com/sapcc/kubernetes-oomkill-exporter/blob/master/main.go#LL15C10-L15C31 у которого уже готовый watcher и парсер для kernel логов есть

А ноде проблем детектор нельзя допилить ?

Да можно наверное, я прост не уверен правильно ли это будет. Хотя это же прост допонительная метрика

он там по коду /dev/kmsg парсит затем из лога достает container id, а потом уже из containerd достает всю инфу лейблы, ns, pod и т.д.

всё равно глупо не юзать работающий софт на 128 строчек кода, решающий твою проблему, потому что раз в 3 месяца не обновляют зависимости. Так-то зависимости не только фиксы приносят, а еще новые дыры