Пишем логи в journald с помощью Logback и FFM API
Способов развернуть веб‑приложение - десятки, и почти под каждый сценарий складывается свой стиль логгирования. Ниже - практичный подход для Java‑бэкенда, который запускается как systemd‑service и пишет события напрямую в journald, используя Logback и Foreign Functions And Memory API (FFM API), появившийся в JDK 22.
Это не попытка "продать" решение как единственно верное. Скорее демонстрация того, что такой путь существует и иногда действительно удобен. Важно помнить: FFM API - это выход в нативный мир, а значит вместе с гибкостью вы получаете и риски. Плюс я не приводил замеры производительности: по ощущениям journald‑API в итоге формирует бинарное сообщение и пишет его в Unix‑сокет, что потенциально должно быть быстро, но проверять это лучше на своей нагрузке.
Предполагается, что вы в целом знакомы с systemd/journald, Java‑разработкой и тем, как настраивается Logback.
Что происходит "по умолчанию": stdout → journald
Типичная схема на VPS выглядит так: Spring Boot (или другое приложение) логирует в stdout через Slf4J/Logback, а systemd подхватывает stdout/stderr процесса и пробрасывает вывод в journald. На первый взгляд удобно: не нужны файлы, не нужна ротация, всё живёт в одном месте и собирается стандартными средствами.
Но у такого "трубопровода" есть неприятная особенность: journald видит не событие логгера, а просто строки вывода. В результате каждая строка stdout превращается в отдельное сообщение journald, и уровень логирования при этом фактически теряется - на практике все сообщения выглядят как события одного уровня (часто INFO).
Если запустить простейшую Java‑программу под systemd и писать в stdout через Slf4J + Logback, то при просмотре через journalctl будет видно именно это "построчное" поведение.
Почему это раздражает в реальной эксплуатации
Проблема №1 - фильтрация по уровню. Когда уровень сообщения "не доезжает" до journald корректно, вы теряете важнейший инструмент: быстро отфильтровать WARN/ERROR и читать только то, что действительно требует внимания. Вместо этого приходится листать весь поток.
Проблема №2 - многострочные сообщения ломаются. Стектрейсы исключений, диагностические дампы и любые сообщения, состоящие из нескольких строк, в journald превращаются в набор независимых записей. В условиях параллельных запросов строки из разных событий могут перемешиваться, и картина происходящего становится не просто шумной - местами её невозможно восстановить.
В "идеальном мире" хочется, чтобы:
- в journald сохранялся реальный уровень сообщения;
- многострочные сообщения отображались как единое событие;
- при желании можно было бы добавлять метаданные (например, место вызова логгера), не превращая это в парсинг текста.
Некоторое время с "stdout‑логами" можно жить, но в определённый момент это начинает мешать поддержке и отладке.
Идея решения: отправлять сообщения в journald напрямую
Попытки "донастроить" systemd unit так, чтобы он magically превращал stdout в структурированные записи journald, обычно быстро упираются в ограничения: systemd читает поток, а не смысл лог‑события.
Зато у systemd есть нативная библиотека libsystemd, и в её документации описаны функции для записи в journald. В частности, есть функция sd_journal_send_with_location - она позволяет отправить сообщение в journald, указав уровень и дополнительные полезные атрибуты, например "локацию" (где именно в коде произошёл вызов логгера).
И примерно в этот же период появился JDK 22, в состав которого вошёл Foreign Functions And Memory API. Это и позволило связать Java‑код с нативным journald‑API без JNI в классическом виде.
Важное предупреждение про FFM API
FFM API - это мост в нативные вызовы. Ошибка при работе с нативной памятью или неверно описанная сигнатура функции может привести к segmentation fault и падению JVM‑процесса. Это принципиальный момент: такое падение не перехватывается try-catch, потому что это не "исключение Java", а авария на уровне процесса.
Это не теоретическая страшилка: приложение вполне реально может начать падать из‑за undefined behavior, которое легко допустить в наивной реализации FFM‑вызова (например, неправильно описали layout структуры или время жизни буфера).
Поэтому подход стоит применять осознанно: аккуратно описывать типы, тщательно тестировать и иметь план "как жить", если нативная часть внезапно ведёт себя не так, как ожидалось.
Общая схема реализации
Концептуально всё складывается в три шага:
1) Пишем Java‑обёртку над sd_journal_send_with_location с помощью FFM API.
Это та часть, где придётся описывать memory layouts, конструировать аргументы, строки, массивы полей и сам метод вызова нативной функции.
2) Делаем кастомный Appender для Logback (наследник `ch.qos.logback.core.Appender`), который на каждое лог‑событие будет вызывать вашу обёртку и отправлять запись прямо в journald.
3) Подключаем appender в конфигурации Logback - и приложение начинает писать в journald "правильными" сообщениями, а не строками stdout.
Если после подключения логов внезапно "нет", частая причина - исключения внутри appender'а. Logback при определённых настройках может не очень заметно проглатывать проблемы, поэтому для диагностики полезно включать режим отладки конфигурации через `debug="true"`.
Что именно приходится аккуратно сделать в обёртке
Сложность здесь не в самой идее, а в точности исполнения. Обёртка сводится к тому, чтобы корректно:
- описать типы данных (int, pointers, строки, структуры, массивы полей);
- обеспечить правильное кодирование строк и их завершение;
- корректно управлять временем жизни памяти (чтобы нативный код не получил ссылку на уже освобождённый буфер);
- собрать аргументы для `sd_journal_send_with_location` в ожидаемом формате.
Звучит довольно прямолинейно, но "ошибиться на один байт" - реально, а цена ошибки, как уже сказано, может быть высокой.
Два подхода к описанию нативных обёрток
Обёртки можно делать по-разному.
Первый способ - описывать всё вручную (или с помощью генерации, в том числе при участии LLM): вы самостоятельно задаёте layouts, сигнатуры и правила подготовки аргументов. Это даёт контроль, но повышает шанс допустить мелкую ошибку.
(Дальше по теме обычно выделяют и второй подход - автоматизацию/генерацию на основе заголовков и описаний, но даже при автоматизации итог всё равно нужно проверять и тестировать на реальном окружении.)
---
Дополнительные практические нюансы, о которых стоит подумать заранее
Ниже - несколько моментов, которые полезно продумать, чтобы решение не выглядело "классно в демо" и не стало источником сюрпризов в продакшене.
1) Сопоставление уровней Logback и приоритетов journald.
В Logback уровни привычные (TRACE/DEBUG/INFO/WARN/ERROR). В journald используются свои приоритеты. В appender'е важно завести понятное и стабильное сопоставление, чтобы `journalctl`‑фильтры работали так, как вы ожидаете.
2) Многострочные сообщения лучше отправлять одним событием.
Если вы уже уходите от stdout‑трубы, имеет смысл собирать итоговый текст (message + stacktrace) и отправлять его в journald единым сообщением. Это как раз лечит проблему "перемешивания строк" при параллельной нагрузке.
3) Добавляйте полезные поля, но не превращайте лог в свалку.
Помимо текста и уровня, часто полезно прикладывать: имя логгера, поток, имя сервиса, окружение, версию сборки. Но чем больше полей, тем важнее дисциплина: договоритесь, какие ключи обязательны, а какие опциональны, иначе читать это будет тяжело.
4) Продумайте деградацию, если journald недоступен.
Сокет journald обычно доступен, но бывают сценарии контейнеризации, минимальных образов или нестандартных окружений. Хорошая идея - предусмотреть режим fallback: например, при ошибке нативного вызова временно писать в stdout или в отдельный аварийный appender (понимая ограничения).
5) Тестируйте на том же дистрибутиве, что и прод.
Поведение и версия systemd/journald могут различаться. Если вы разрабатываете на одном окружении, а разворачиваете на другом, лучше заранее прогнать интеграционный тест: старт systemd‑service, генерация разных уровней логов, проверка отображения многострочных сообщений.
6) Следите за безопасностью и стабильностью процесса.
Раз уж ошибка FFM может уронить JVM, полезно минимизировать риск: изолировать нативный код, ограничить изменения, покрыть тестами и не "усложнять" обёртку без необходимости. Иногда лучше отправлять меньше полей, но надёжно.
7) Учитывайте стоимость форматирования.
Если вы активно логируете и добавляете стектрейсы/поля, значительная часть времени может уходить на форматирование строк и сбор данных, а не на сам journald‑вызов. Настройка уровней и разумная политика логирования всё ещё важны, даже если backend записи быстрый.
---
Итог простой: схема stdout → journald удобна, но ломает уровни и многострочность, что делает диагностику менее эффективной. Прямая отправка событий из Logback в journald через `sd_journal_send_with_location` решает эти проблемы и даёт более "родные" для systemd логи. Цена - аккуратная работа с FFM API и понимание того, что ошибки на нативной границе могут завершить JVM-процесс.
