Продолжаем тему о структурированном журналировании. Jonathan Corbet пишет на LWN, что систему журналирования ядра Linux вскоре ожидают сильные изменения (к сожалению, статья за paywall). Разработчик udev и systemd Kay Sievers предложил радикально изменить поведение журналируемой подсистемы ядра.

Напомню, какова-же одна из проблем, которую решает проект Lumberjack. Изначально, из-за малого количества разработчиков и недоговоренности о стандартах, было решено, что журнал будет содержать просто текстовые строчки сообщений (например, "[system] Successfully activated service 'org.freedesktop.PolicyKit1'"). Человек в них может узнать о каких-то событиях, но роботы-то читать не умеют! Им нужна заранее заданная структура сообщений, возможно, что и не человекочитаемая (так напугавшие всех "бинарные логи"), и поэтому каждый или почти каждый сисадмин имеет свои скриптики, которые приходится постоянно переписывать, чтоб извлекать какие-то данные из журнала. Было предложено ввести структурирование журнала - отделить человеко-читаемые данные от тех, что нужны роботам. На уровне user-space это вылилось в проект Lumberjack, и, видимо, стоит ожидать скорого повсеместного внедрения "бинарных логов" в дистрибутивы. К сожалению, в ядре до сих пор журнал ведется с помощью произвольно сформированных строк текста.

Предложение Kay Sievers содержит три пункта. Первое, это вести журнал внутри ядра не в виде некоего буфера фиксированной длины, а в виде очереди объектов. Это даже немного сэкономит память в ряде случаев и поможет предотвратить повреждение сообщений при переполнении очереди (сейчас просто перезаписывается память, занятая старыми сообщениями, что приводило к повреждению некоторых перед отправкой в логгер, работающий на уровне пользователя). Второе, это возможность присовокупить некоего KV-словаря к каждому сообщению (это и есть то самое, что будет читаться роботами - systemd, rsyslog, syslog-ng и т.п.). И, наконец, третье, это радикальное изменение поведения /dev/kmsg. Сейчас, максимум, на что оно годно, это для добавления своего сообщения к журналу событий ядра. Sievers переработал его так, что из него можно будет читать ленту событий ядра программами типа cat и less. Поддерживается одновременное чтение событий несколькими источниками. Таким образом, это устройство становится основным источником событий ядра, которое будет удобно разбирать, и которое будет гарантированно доставлять сообщения в целости или сообщать, что некое-количество сообщений было потеряно.

В целом изменение благосклонно встречено kernel-хакерами. Даже Linus Torvalds высказался одобрительно. Стоит ожидать частичного появления этой функциональности в ядре 3.4, и окончательного - в ядре 3.5.