Комментарии 13
самый критический путь всей библиотеки. Она вызывается для всех событий «запись лога в файл»
Т.е. простое отключение логирования помогло? Значит ошибка была не столько в ядре linux, сколько в сторонняя библиотека логирования под названием glog?
нет. Ошибка не библиотеке glog. А просто неудачное стечение обстоятельств, когда возникала внезапная конкуренция за ресурсы ядра.

Условный контр-пример. Представьте себе, что Вы — пользователь IaaS/PaaS. И Вам нужно развернуть отказоустойчивый кластер hadoop. Вы нарезаете виртуалки, ставите ОСь, устанавливаете софт hadoop. И выясняется, что кластер-то нифига не отказоустойчивый. В чем дело? Ведь и IaaS по паспорту обеспечивает отказоустойчивость (живая миграция ВМ в случае отказа ноды и пр.) и вроде бы hadoop тоже сам по себе отказоустойчивый (он спецом разрабатывался, чтобы быть запущенным на дешевом хламе, которое все время отказывает). А оказывается, что нужно еще выставить виртуалкам правильно antiaffinity, чтобы гипервизор их расталкивал по ВМкам в правильном порядке. При этом не IaaS — плохая и не Хадуп — плохой. А «любая абстракция рано или поздно течет» и приходится разбираться со всем стеком снизу вверх (или сверху вниз).

Вот такая же история с ядром. Никто заранее не объяснил границы применимости той или иной технологии и получили протекшую абстракцию.
НЛО прилетело и опубликовало эту надпись здесь
Тут упор на то, что люди начали использовать контейнеры для CI/CD. У нас в инфраструктуре для этого используются динамически создаваемые виртуалки в openstack, и в подобной ситуации такой проблемы бы не было. Контейнеры мы тоже используем, но только в пределах одной задачи (например, быстрый прогон тестов бэкапов) — между задачами ядро ОС не шарится (а если и шарится, то без привлечения контейнеров, просто на уровне процессов).

Люди попытались использовать контейнеры, но пришлось допиливать, т.к. изоляция не полная.
amarao ну, Вы говорите так, будто VM не конкурируют за ресурсы — CPU time там, IOPS'ы всякие. Причем с ними тоже часть проблем решается. Можно зашейпить IOPS'ы те же. Но! Это, во-первых, не спасет от context switching и вымывания L2/L3 кэшей на процессорах (камни обычно оверселлятся на ура). А, во-вторых, если настроена live миграция виртуалок, то там запросто тоже быстродействие может просесть на ура в случае, если ВМки пошли мигрировать между нодами.
12 факторов — не панацея. В частности, например, некоторые джава-программисты пишут такие программы, которые в лог кидают СЛИШКОМ много всего. Понятно, что всегда можно отфильтровать… но такое себе. А на ходу (без перезапусука сервиса) переключить уровень логирования не всегда возможно.

Еще момент — когда берешь уже готовый контейнер с тем же airflow. Там фактически внутри получается несколько служб/скриптов и из лога получается мешанина, причем которую разбить нельзя. Вот и приходится костылись логирование в файл или во внешний сервис типа эластика. Естественно, уходим от этого, но не все сразу.
Журнал в своём сыром виде обычно представлен текстовым форматом с одним событием на строчку

тоже спорно. А если все-таки нужен multiline? Выход — паковать сообщение в json или типа того?
Буквально на прошлой неделе я сумел устроить OOM на сервере с 8 контейнерами. Каждый контейнер потреблял несколько мегабайт, на сервере было 8Гб (виртуалка). Догадайтесь, сколько kmalloc памяти съедал каждый контейнер? Нет, оно не аккаунтилось cgroup'ами, оно просто прибивало что попало по OOM, в т.ч. за пределами контейнеров.

И я только тронул волшебный вопрос «kernel memory» на всякие объекты.

Контейнеры — коммуналка. Если кто-то решит часто ходить в туалет, остальные будут ждать.
Я не уверен, что это не CVE. Хочу дотестировать в имитации продакшен-среды. Но суть одна и так же — начинаете есть ресурсы ядра из контейнеров, и ядро память ест, а userspace в контейнере — нет.

fd, ip-адреса, mount'ы, namespace'ы, интерфейсы, pid'ы, сокеты, pipe'ы, etc.
Т.е. это вопрос accounting'а ресурсов, которые контейнеры тратят в ядре (и не учитываются в статистике)?
Ага. Причём, иногда может быть, что очень сложно понять, куда относить ресурсы. В принципе, мы можем понять, что в конкретную cgroup'у, но иногда не понятно, через что. Например, вложенные namespace'ы — как их аккаунтить по памяти? Это память процесса? Нет. А память всегда на процесы выделяется. А в tmpfs? А в /sys? А память conntrack'а?
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.