Все знают о том, как наблюдать за работающими процессами в Linux-системе. Но почти никто не добивается в подобных наблюдениях высокой точности. На самом деле, всем методам мониторинга процессов, о которых пойдёт речь в этом материале, чего-то не хватает.
Давайте, прежде чем приступить к экспериментам, определим требования к системе наблюдения за процессами:
- Логироваться должны сведения обо всех процессах, даже о короткоживущих.
- У нас должны быть сведения о полном пути к исполняемому файлу для всех запущенных процессов.
- У нас, в пределах разумного, не должно возникать необходимости в модификации или перекомпиляции нашего кода для разных версий ядра.
- Дополнительное требование: если хост-система является узлом Kubernetes или использует Docker, то у нас должна быть возможность определить то, к какому именно поду/контейнеру принадлежит процесс. Для этого обычно достаточно знать
cgroup ID процесса. Дело в том, что с точки зрения ядра нет такого понятия, как «контейнер» или «идентификатор контейнера». Ядро оперирует лишь такими понятиями, как «контрольные группы», «сетевые пространства имён», «пространства имён процессов», оно работает с различными независимыми API, с помощью которых средства контейнеризации вроде Docker реализуют механизмы контейнеризации. Если попытаться идентифицировать контейнеры посредством ID уровня ядра, нужен уникальный идентификатор контейнера. В случае с Docker данному требованию удовлетворяют идентификаторы контрольных групп.
Поговорим об обычных API Linux, которые могут помочь в решении этой задачи. Мы, чтобы не усложнять повествование, уделим особое внимание процессам, создаваемым с помощью системных вызовов execve. Если же говорить о более полном решении задачи, то при его реализации нужно, кроме того, мониторить процессы, созданные с помощью системных вызовов fork/clone и их вариантов, а так же — результаты работы вызовов execveat.
Читать полностью »
