- PVSM.RU - https://www.pvsm.ru -
Все эксперименты проводились на CentOS Linux release 7.2.1511 в качестве основной системы, с последними доступными из стоковой репы systemd (systemd-219-19.el7_2.13). Надеюсь, часть приведенных данных будет неактуальна уже на момент публикации статьи.
Начав захватывать linux-дистрибутивы с выпуска Fedora 15, systemd окончательно победил. Зубры и аксакалы понемногу приучаются к unit'ам и systemctl. Скрежещат зубами последние защитники Старого Доброго. В этих реалиях невозможно обойти дочерние продукты systemd. И сегодня давайте поговорим, например, про journald.
Сам по себе journald (и соответственно journalctl) — прекрасный инструмент. Зародившийся как слегка сторонний к systemd проект, к нынешнему времени journald стал вторым инструментом из семейства systemd, с которым знакомятся системные администраторы. Мне действительно нравится идея рантайм хранилища логов с опциональной возможностью сброса на постоянное хранение, задумка с boot-id journalctl --boot
и machine-id (journalctl --machine
), возможность из единого интерфейса вызывать логи любых зарегистрированных приложений journalctl -u
, а также наличие "из коробки" ротации логов (как по месту, так и по времени) при помощи journalctl --vacuum-size
или journalctl --vacuum-time
. Из хорошего нельзя не упомянуть ещё и параметры since
, until
и priority
, которыми можно "грепать" события по времени и приоритету, и, разумеется, параметр utc
, снимающий огромную головную боль с мульти-таймзонными командами и проектами. Может быть немного спорным бинарный формат хранения файлов, но этот выбор был объяснен авторами ещё при первых анонсах journald (безопасность и дешевизна хранения, интеграция с systemd, принудительный единый формат, переносимость).
К сожалению, не приобрел большого распространения механизм каталогов journald, который позволяет, например, организовать перевод сообщений логов или предоставить конечным пользователям url для решения проблем с конкретными ошибками. Но в целом даже разработчики systemd не пользуются этой возможностью полностью — куда уж нам, смертным.
Это всё реализовано, работает, описано в сотнях мануалов, проверено. Большое спасибо, но я хочу больше.
Не так давно один приятель попросил настроить ему сервер для сбора логов. Хха! — подумал я, — это же прекрасный повод изучить journald в свете его возможностей центрального лог-сервера!
Понятное дело, что инструмент зависит от задачи. Вот и в этот раз был проведен краткий сбор требований:
И общетехническая вводная:
Кажется, что systemd и journald хороший выбор, верно? Ведь все пункты уже реализованы! Поднимаем тестовый стенд!
Ну что же, начнём.
Нас интересуют три компонента:
systemd-journal-gatewayd
— http-демон, открывающий порт для просмотра (или скачивания) записей журналаsystemd-journal-remote
— демон, скачивающий или принимающий записи журналов на центральном сервереsystemd-journal-upload
— демон, дублирующий записи журналов на удаленный серверВсе эти компоненты входят в centos-пакет systemd-journal-gateway
, так что выполняем:
yum -y update && yum -y install systemd-journal-gateway
За получение логов на головной машине используется демон systemd-journal-remote
. С него и начнём.
У remote есть два режима работы: активный (при котором он сам ходит в удаленный журнал и скачивает логи — в том числе в режиме слежения. Для этого режима на всех удаленных машинах нужен systemd-journal-gatewayd
) и пассивный (при котором демон висит и ждёт, пока к нему придут). С учетом неизвестного количества машин — выбираем пассивный режим. Вся настройка, собственно, заключается в том, чтобы сделать директорию /var/log/journal/remote
, назначить ей права нужного пользователя и запустить сервис:
mkdir -p /var/log/journal/remote
chown systemd-journal-remote:systemd-journal-remote /var/log/journal/remote
systemctl start /var/log/journal/remote
Поскольку мы собираем демо-стенд, давайте переключим протокол приёма файлов с https на http. Для этого необходимо отредатировать стартовый сервис-файл /lib/systemd/system/systemd-journal-remote.service
, заменив опцию listen-https
на listen-http
. Также будет полезно поправить /lib/systemd/system/systemd-journal-remote.socket
, указав только интересующий нас адрес для биндинга демона.
Демон стартовал, висит в пассивном режиме, работает по http. Ура!
Во-первых, при создании директории /var/log/journal
все ваши системные логи начнут писаться в директорию /var/log/journal/<uuid>
. Чтобы изменить это поведение и вернуть как было, надо заправить конфигурационный файл /etc/systemd/journald.conf
(а лучше даже /etc/systemd/journald.conf.d/<ваш конфиг>.conf
, т.к. первый может перетереться при обновлениях), а именно строку Storage=
. По умолчанию, значение этого параметра auto
, что означает "если есть директория в var, journald записывает логи туда". В моём случае, параметр надо было принудительно выставить в volatile
.
С upload всё ещё проще: создаём /etc/systemd/journal-upload.d/<ваш конфиг>.conf
, записав туда:
[Upload]
URL=http://<IP-адрес remote>:<порт удаленного демона>
и запустим systemctl start systemd-journal-upload
Во-вторых, демон не запустится благодаря очень старой баге в Centos [1]. Так что делайте usermod руками: usermod -a -G systemd-journal systemd-journal-upload
. После этого демон должен стартовать успешно.
На удаленных клиентах, напомню, стоит Ubuntu 16.04. Так что ставим там apt-get install systemd-journal-remote
и проводим правки /etc/systemd/journal-upload.d/<ваш конфиг>.conf
, аналогичные предыдущему пункту (кроме usermod
).
А тут, собственно, описывать нечего. Текущая версия, представленная в Centos, не позволяет указывать нестандартные директории для указанного демона. Причем стандартная директория для логов с других машин, по логике разработчиков, является нестандартной для просмотрщика логов. В новых версиях systemd это, кажется, исправлено [2], но мы же не будем ставить неродные версии...
Ну что же, давайте хотя бы понаблюдаем за логами:
journalctl -D /var/log/journal/remote --follow
Ну, что-то вроде работает...
В третьих, благодаря старой баге в systemd [3], у вас начнёт дичайше пухнуть директория /var/log/journal/remote
. И тут вам не поможет ничего...
Тем не менее, раз уж мы зашли так далеко, давайте дойдём до конца. Запускаем на головной машине демон systemd-journal-gatewayd
(опять не забываем поправить /lib/systemd/system/systemd-journal-gatewayd.socket
, чтобы ограничить демона, да?) и внимательно изучаем веб-интерфейс просмотрщика:
on mouse over
и on mouse scroll
для логовНда. Возможно, и хорошо, что не получилось его настроить, м?
Для proof of concept за пару дней был написан pet-проект [4], благо journald предоставляет родную библиотеку для питона. Из особенностей:
Этот же проект был раскатан приятелю, с описанием имеющихся проблем, отказом от ответственности и принудительной очисткой журналов.
Но на больших проектах лично я наверное ещё долго не буду использовать journald в качестве центрального хранилища логов. До тех пор, пока не будут убраны приведенные выше баги, мой выбор — однозначно в пользу syslog.
Автор статьи: Степан Карамышев [5]
Автор: Centos-admin.ru
Источник [6]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/sistemnoe-administrirovanie/220274
Ссылки в тексте:
[1] баге в Centos: https://bugzilla.redhat.com/show_bug.cgi?id=1262743
[2] исправлено: https://github.com/systemd/systemd/issues/3871
[3] баге в systemd: https://github.com/systemd/systemd/issues/1387
[4] pet-проект: https://github.com/skob/journal
[5] Степан Карамышев: https://habrahabr.ru/users/skob/
[6] Источник: https://habrahabr.ru/post/317182/?utm_source=habrahabr&utm_medium=rss&utm_campaign=best
Нажмите здесь для печати.