Version v13.2 (2012-11-23 19:56) [AUTO]

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{<TAB>}
+\end{Verbatim}
+и оболочка сразу же дополнит:
+\begin{Verbatim}
+$ journalctl _SELINUX_CONTEXT=	
+\end{Verbatim}
+Отлично, и какое там значение нам нужно?
+\begin{Verbatim}[fontsize=\small]
+$ journalctl _SELINUX_CONTEXT=<TAB><TAB>
+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}