Удаленное логирование в journald или Всё ещё «это вам не нужно»?

Дисклеймер

Все эксперименты проводились на 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 в свете его возможностей центрального лог-сервера!

Понятное дело, что инструмент зависит от задачи. Вот и в этот раз был проведен краткий сбор требований:

1. Необходимо организовать единую точку логирования
2. Необходимо организовать возможность подключения к единой точке логирования заранее неизвестного количества клиентов (и их отключение, соответственно)
3. Желательно организовать возможность просмотра логов online, с автоматическим получением новых записей
4. При выполнении предыдущего пункта, хранение логов на центральной точке можно ограничить N часами (даже не днями)
5. Формат сообщений непостоянен вплоть до мультилайна
6. Ключевое интересующее ПО пишет в stdout (да, можно изменить поведение или накостылить, но покупаем, что продают), консоль не закрывает

И общетехническая вводная:

1. Данные передаются по паблик-сетям
2. Головная выделенная машина: Centos7.2 (latest)
3. Подключаемые машины: Ubuntu 16.04

Кажется, что systemd и journald хороший выбор, верно? Ведь все пункты уже реализованы! Поднимаем тестовый стенд!

Головной хост

Ну что же, начнём.
Нас интересуют три компонента:

1. systemd-journal-gatewayd — http-демон, открывающий порт для просмотра (или скачивания) записей журнала
2. systemd-journal-remote — демон, скачивающий или принимающий записи журналов на центральном сервере
3. systemd-journal-upload — демон, дублирующий записи журналов на удаленный сервер

Все эти компоненты входят в centos-пакет systemd-journal-gateway, так что выполняем:

yum -y update && yum -y install systemd-journal-gateway

За получение логов на головной машине используется демон systemd-journal-remote. С него и начнём.

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.

systemd-journal-upload

С upload всё ещё проще: создаём /etc/systemd/journal-upload.d/<ваш конфиг>.conf, записав туда:

[Upload]
URL=http://<IP-адрес remote>:<порт удаленного демона>

и запустим 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).

systemd-journal-gatewayd

А тут, собственно, описывать нечего. Текущая версия, представленная в Centos, не позволяет указывать нестандартные директории для указанного демона. Причем стандартная директория для логов с других машин, по логике разработчиков, является нестандартной для просмотрщика логов. В новых версиях systemd это, кажется, исправлено, но мы же не будем ставить неродные версии...

Ну что же, давайте хотя бы понаблюдаем за логами:

journalctl -D /var/log/journal/remote --follow

Ну, что-то вроде работает...

Дьявол в деталях

В третьих, благодаря старой баге в systemd, у вас начнёт дичайше пухнуть директория /var/log/journal/remote. И тут вам не поможет ничего...

Дойдём до конца!

Тем не менее, раз уж мы зашли так далеко, давайте дойдём до конца. Запускаем на головной машине демон systemd-journal-gatewayd (опять не забываем поправить /lib/systemd/system/systemd-journal-gatewayd.socket, чтобы ограничить демона, да?) и внимательно изучаем веб-интерфейс просмотрщика:

• Подкачка логов online фактически отсутствует
• Лютые on mouse over и on mouse scroll для логов
• microhttpd под капотом
• Простите, но ужасающий интерфейс
• Есть возможность фильтрации логов по systemd-unit, но (в связи с количеством неинформативных session-юнитов например от крон-скриптов) невозможность пользоваться фильтрами
• Все юниты пишутся полностью — если вы используете например пароли к базам данных в крон-строках, ваши пароли будут вас ждать

Нда. Возможно, и хорошо, что не получилось его настроить, м?

Итого

Для proof of concept за пару дней был написан pet-проект, благо journald предоставляет родную библиотеку для питона. Из особенностей:

1. Онлайн-просмотр по SSE
2. Возможность фильтровать выводимые юниты администратором на уровне конфигурации
3. Возможность фильтровать хосты/приоритет/юниты пользователем на уровне веб-приложения
4. Ну и немножко бутстрапа

Этот же проект был раскатан приятелю, с описанием имеющихся проблем, отказом от ответственности и принудительной очисткой журналов.

Но на больших проектах лично я наверное ещё долго не буду использовать journald в качестве центрального хранилища логов. До тех пор, пока не будут убраны приведенные выше баги, мой выбор — однозначно в пользу syslog.

Автор статьи: Степан Карамышев