Compare commits
1 Commits
| Author | SHA1 | Date | |
|---|---|---|---|
|
a0a5e1f4ac |
197
s4a.tex
197
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}
|
||||
|
||||
|
||||
Reference in New Issue
Block a user