diff --git a/s4a.tex b/s4a.tex index bf21800..dcc39d1 100644 --- a/s4a.tex +++ b/s4a.tex @@ -3687,7 +3687,204 @@ $ journalctl /usr/sbin/vpnc /usr/sbin/dhclient \end{Verbatim} Отлично, мы нашли причину проблемы! +\subsection{Продвинутые методы выборки} +Да, это все, конечно, здорово, но попробуем подняться еще на ступеньку выше. +Чтобы понять описанные ниже приемы, нужно знать, что systemd добавляет к +каждой лог-записи ряд скрытых метаданных. Эти метаданные по структуре напоминают +набор переменных окружения, хотя на самом деле дают даже больше возможностей: +во-первых, метаданные могут включать большие бинарные блоки данных (впрочем, это +скорее исключение~--- обычно они содержат текст в кодировке UTF-8), и во-вторых, +в пределах одной записи поле метаданных может содержать сразу несколько +значений (и это тоже встречается нечасто~--- обычно поля содержат по одному +значению). Эти метаданные автоматически собираются и добавляются для каждой +лог-записи, безо всякого участия пользователя. И вы легко можете их использовать +для более тонкой выборки записей. Посмотрим, как они выглядят: +\begin{Verbatim} +$ journalctl -o verbose -n1 +Tue, 2012-10-23 23:51:38 CEST [s=ac9e9c423355411d87bf0ba1a9b424e8;i=4301;b=5335e9cf5d954633bb99aefc0ec38c25;m=882ee28d2;t=4ccc0f98326e6;x=f21e8b1b0994d7ee] + PRIORITY=6 + SYSLOG_FACILITY=3 + _MACHINE_ID=a91663387a90b89f185d4e860000001a + _HOSTNAME=epsilon + _TRANSPORT=syslog + SYSLOG_IDENTIFIER=avahi-daemon + _COMM=avahi-daemon + _EXE=/usr/sbin/avahi-daemon + _SYSTEMD_CGROUP=/system/avahi-daemon.service + _SYSTEMD_UNIT=avahi-daemon.service + _SELINUX_CONTEXT=system_u:system_r:avahi_t:s0 + _UID=70 + _GID=70 + _CMDLINE=avahi-daemon: registering [epsilon.local] + MESSAGE=Joining mDNS multicast group on interface wlan0.IPv4 with address 172.31.0.53. + _BOOT_ID=5335e9cf5d954633bb99aefc0ec38c25 + _PID=27937 + SYSLOG_PID=27937 + _SOURCE_REALTIME_TIMESTAMP=1351029098747042 +\end{Verbatim} +(Чтобы не~утомлять вас огромным количеством текста, ограничимся одной записью. +Ключ +-n+ позволяет задать число выводимых записей, в нашем случае 1. Если +указать его без параметра, будут показаны 10 последних записей.) + +Задав параметр +-o verbose+, мы переключили формат вывода~--- теперь, вместо +скупых строчек, копирующих +/var/log/messages+, для каждой записи выводится +полный перечень всех метаданных. В том числе, информация о пользователе и +группе, контекст SELinux, идентификатор компьютера и т.д. Полный список +общеизвестных полей метаданных приведен на соответствующей +\href{http://www.freedesktop.org/software/systemd/man/systemd.journal-fields.html}% +{странице руководства}. + +И база данных Journal индексируется по \emph{всем} этим полям! И мы можем +использовать любое из них в качестве критерия выборки: +\begin{Verbatim} +$ journalctl _UID=70 +\end{Verbatim} +Как нетрудно догадаться, в результате будут выведены все сообщения от +процессов пользователя с UID 70. При необходимости, критерии можно +комбинировать: +\begin{Verbatim} +$ journalctl _UID=70 _UID=71 +\end{Verbatim} +Указание двух значений для одного и того же поля эквивалентно логическому ИЛИ. +Таким образом, будут выведены записи как от процессов с UID 70, так и от +процессов с UID 71. +\begin{Verbatim} +$ journalctl _HOSTNAME=epsilon _COMM=avahi-daemon +\end{Verbatim} +А указание двух \emph{различных} полей дает эффект логического И. В результате, +будут выведены записи только от процесса +avahi-daemon+, работающего на хосте с +именем +epsilon+. + +Но мы этим не~ограничимся! Мы же суровые компьютерщики, мы хотим использовать +сложные логические выражения! +\begin{Verbatim} +$ journalctl _HOSTNAME=theta _UID=70 + _HOSTNAME=epsilon _COMM=avahi-daemon +\end{Verbatim} +При помощи плюса мы можем явно задать логическое ИЛИ, применяя его к разным +полям и даже И-выражениям. Поэтому наш пример выведет как записи с хоста ++theta+ от процессов с UID 70, так и с хоста +epsilon+ от процесса ++avahi-daemon+\footnote{Прим. перев.: Стоит отметить, что приоритет логических +операций стандартный: сначала выполняются операции И, и только потом~--- +операции ИЛИ. Используемая в +journalctl+ система записи выражений аналогична +принятой в классической алгебре: умножение (имеющее более высокий приоритет) +не~указывается знаком операции, а обозначается просто последовательной +записью величин.}. + +\subsection{И немного магии} + +Уже неплохо, правда? Но есть один недостаток~--- мы же не~сможем запомнить все +возможные значения все полей журнала! Для этого была бы нужна очень хорошая +память. Но +journalctl+ вновь приходит к нам на помощь: +\begin{Verbatim} +$ journalctl -F _SYSTEMD_UNIT +\end{Verbatim} +Эта команда выведет все значения поля +_SYSTEMD_UNIT+, зарегистрированные в базе +данных журнала на текущий момент. То есть, имена всех юнитов +systemd+, которые +писали что-либо в журнал. Аналогичный запрос работает для всех полей, так что +найти точное значение для выборки по нему~--- уже не~проблема. Но тут самое +время сообщить вам, что эта функциональность встроена в механизм автодополнения +оболочки\footnote{Прим. перев.: В исходной статье речь идет только о bash, +однако, начиная с релиза systemd 196, аналогичная функциональность доступна и +для zsh.}! Это же просто прекрасно~--- вы можете просмотреть перечень значений +поля и выбрать из него нужно прямо при вводе выражения. Возьмем для примера +метки SELinux. Помнится, имя поле начиналось с букв SE\ldots{} +\begin{Verbatim}[commandchars=\\\{\}] +$ journalctl _SE\textbf{} +\end{Verbatim} +и оболочка сразу же дополнит: +\begin{Verbatim} +$ journalctl _SELINUX_CONTEXT= +\end{Verbatim} +Отлично, и какое там значение нам нужно? +\begin{Verbatim}[fontsize=\small] +$ journalctl _SELINUX_CONTEXT= +kernel system_u:system_r:rtkit_daemon_t:s0 +system_u:system_r:accountsd_t:s0 system_u:system_r:syslogd_t:s0 +system_u:system_r:avahi_t:s0 system_u:system_r:system_cronjob_t:s0-s0:c0.c1023 +system_u:system_r:bluetooth_t:s0 system_u:system_r:system_dbusd_t:s0-s0:c0.c1023 +system_u:system_r:chkpwd_t:s0-s0:c0.c1023 system_u:system_r:systemd_logind_t:s0 +system_u:system_r:chronyd_t:s0 system_u:system_r:systemd_tmpfiles_t:s0 +system_u:system_r:crond_t:s0-s0:c0.c1023 system_u:system_r:udev_t:s0-s0:c0.c1023 +system_u:system_r:devicekit_disk_t:s0 system_u:system_r:virtd_t:s0-s0:c0.c1023 c0.c1023 +system_u:system_r:dhcpc_t:s0 system_u:system_r:vpnc_t:s0 sd_t:s0-s0:c0.c1023 +system_u:system_r:dnsmasq_t:s0-s0:c0.c1023 system_u:system_r:xdm_t:s0-s0:c0.c1023 +system_u:system_r:init_t:s0 unconfined_u:system_r:rpm_t:s0-s0:c0.c1023 +system_u:system_r:local_login_t:s0-s0:c0.c1023 unconfined_u:system_r:unconfined_t:s0-s0:c0.c1023 +system_u:system_r:lvm_t:s0 unconfined_u:system_r:useradd_t:s0-s0:c0.c1023 +system_u:system_r:modemmanager_t:s0-s0:c0.c1023 unconfined_u:unconfined_r:unconfined_dbusd_t:s0-s0:c0.c1023 +system_u:system_r:NetworkManager_t:s0 unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 +system_u:system_r:policykit_t:s0 +\end{Verbatim} +Ага, нас интересуют записи с меткой PolicyKit! Пользуясь дополнением, вводим: +\begin{Verbatim} +$ journalctl _SELINUX_CONTEXT=system_u:system_r:policykit_t:s0 +\end{Verbatim} +Очень просто, не~правда ли! Пожалуй, самое простое из действий, связанных с +SELinux ;-) Разумеется, такое дополнение работает для всех полей Journal. + +На сегодня все. Впрочем, на странице руководства +\href{http://www.freedesktop.org/software/systemd/man/journalctl.html}% +{journalctl(1)} можно узнать и о многих других возможностях, не~описанных здесь. +Например, о том, что +journalctl+ может выводить данные в формате JSON, или в +формате +/var/log/messages+, но с относительными метками времени, как в dmesg. + +\section{Управление ресурсами} + +Важную роль в современных компьютерных системах играют механизмы управления +использованием ресурсов: когда вы запускаете на одной системе несколько +программ, возникает необходимость распределять между ними ресурсы системы, +в соответствии с некоторыми правилами. В частности, это особенно актуально на +маломощных встраиваемых и мобильных системах, обладающих очень скудными +ресурсами. Но та же задача актуальна и для очень мощных вычислительных +кластеров, которые располагают огромными ресурсами, но при это несут и огромную +вычислительную нагрузку. + +Исторически, в Linux поддерживался только одна схема управления ресурсами: все +процессы получают примерно равные доли процессорного времени или потока +ввода-вывода. При необходимости соотношение этих долей можно изменить при +помощи значения \emph{nice}, задаваемого для каждого процесса. Такой подход +очень прост, и на протяжении долгих лет покрывал все нужды пользователей Linux. +Но у него есть существенный недостаток: он оперирует лишь отдельными процессами, +но не~их группами. В результате, например, веб-сервер Apache с множеством +CGI-процессов при прочих равных получает гораздо больше ресурсов, чем служба +syslog, у которой не~так много процессов. + +В процессе проектирования архитектуры systemd, мы практически сразу поняли, что +управление ресурсов должно быть одной из его базовых функций, заложенных в +основы его структуры. В современной системе~--- неважно, серверной или +встраиваемой~--- контроль использования процессора, памяти и ввода-вывода для +различных служб нельзя добавлять задним числом. Такая функциональность должна +быть доступна изначально, через базовые настройки запуска служб. При этом, +ресурсы должны распределяться на уровне служб, а не~процессов, как это делалось +при помощи значений nice или \href{http://linux.die.net/man/2/setrlimit}{POSIX +Resource Limits}. + +В этой статье я попробую рассказать о методах управления механизмами +распределения ресурсов между службами systemd. Эта функциональность присутствует +в systemd уже долгое время, и давно пора рассказать о ней пользователям и +администраторам. + +В свое время я +\href{http://0pointer.de/blog/projects/cgroups-vs-cgroups.html}{пояснял}, что +контрольные группы Linux (cgroups) могут работать и как механизм группировки и +отслеживания процессов, и как инструмент управления использованием ресурсов. Для +функционирования systemd необходим только первый из этих режимов, а второй +опционален. И именно этот опциональный второй режим дает вам возможность +распределять ресурсы между службами. (А сейчас очень рекомендую вам, прежде чем +продолжать чтение этой статьи, ознакомиться с +\href{https://en.wikipedia.org/wiki/Cgroups}{базовой информацией о cgroups}. +Хотя дальнейшие рассуждения и не~будут затрагивать низкоуровневые аспекты, все +же будет лучше, если у вас сформируется некоторое представление о них.) + +Основными контроллерами cgroups, отвечающими за управление ресурсами, являются +\href{http://www.kernel.org/doc/Documentation/scheduler/sched-design-CFS.txt}{cpu}, +\href{http://www.kernel.org/doc/Documentation/cgroups/memory.txt}{memory} и +\href{http://www.kernel.org/doc/Documentation/cgroups/blkio-controller.txt}{blkio}. +Для их использования необходимо, чтобы они были включены на этапе сборки ядра; +большинство дистрибутивов (в том числе и Fedora), включают их в штатных ядрах. +systemd предоставляет ряд высокоуровневых настроек, позволяющих использовать эти +контроллеры, не~вникая в технические детали их работы. \end{document}