Все эксперименты проводились на 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 хороший выбор, верно? Ведь все пункты уже реализованы! Поднимаем тестовый стенд! Ну что же, начнём.
Нас интересуют три компонента: Все эти компоненты входят в centos-пакет systemd-journal-gateway, так что выполняем: За получение логов на головной машине используется демон systemd-journal-remote. С него и начнём. У remote есть два режима работы: активный (при котором он сам ходит в удаленный журнал и скачивает логи — в том числе в режиме слежения. Для этого режима на всех удаленных машинах нужен systemd-journal-gatewayd) и пассивный (при котором демон висит и ждёт, пока к нему придут). С учетом неизвестного количества машин — выбираем пассивный режим. Вся настройка, собственно, заключается в том, чтобы сделать директорию /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, записав туда: и запустим systemctl start systemd-journal-upload Во-вторых, демон не запустится благодаря очень старой баге в Centos. Так что делайте 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 это, кажется, исправлено, но мы же не будем ставить неродные версии... Ну что же, давайте хотя бы понаблюдаем за логами: Ну, что-то вроде работает... В третьих, благодаря старой баге в systemd, у вас начнёт дичайше пухнуть директория /var/log/journal/remote. И тут вам не поможет ничего... Тем не менее, раз уж мы зашли так далеко, давайте дойдём до конца. Запускаем на головной машине демон systemd-journal-gatewayd (опять не забываем поправить /lib/systemd/system/systemd-journal-gatewayd.socket, чтобы ограничить демона, да?) и внимательно изучаем веб-интерфейс просмотрщика: Нда. Возможно, и хорошо, что не получилось его настроить, м? Для proof of concept за пару дней был написан pet-проект, благо journald предоставляет родную библиотеку для питона. Из особенностей: Этот же проект был раскатан приятелю, с описанием имеющихся проблем, отказом от ответственности и принудительной очисткой журналов. Но на больших проектах лично я наверное ещё долго не буду использовать journald в качестве центрального хранилища логов. До тех пор, пока не будут убраны приведенные выше баги, мой выбор — однозначно в пользу syslog. Автор статьи: Степан Карамышев CEO в Southbridge