Мониторинг логов из Journald - История изменений

IKuznetsov: Новая страница: « = Мониторинг логов из Journald = Модуль логов способен читать, обрабатывать и загружать записи из `systemd-journald` — централизованной службы ведения логов в Linux. События и логи обычно хранятся в файлах, расположенных в каталоге `/var/log/journal/'machine-id'/`, где
2026-10-06T17:28:04Z

Новая страница: « = Мониторинг логов из Journald = Модуль логов способен читать, обрабатывать и загружать записи из <code>systemd-journald</code> — централизованной службы ведения логов в Linux. События и логи обычно хранятся в файлах, расположенных в каталоге <code>/var/log/journal/'machine-id'/</code>, где <c...»

Новая страница

= Мониторинг логов из Journald =
Модуль логов способен читать, обрабатывать и загружать записи из <code>systemd-journald</code> — централизованной службы ведения логов в Linux. События и логи обычно хранятся в файлах, расположенных в каталоге <code>/var/log/journal/'machine-id'/</code>, где <code>machine-id</code> — длинная строка цифр, идентифицирующая машину. Эти файлы хранятся в бинарном сжатом формате, которым управляет движок <code>systemd-journald</code> для контроля размера каждого файла и общего объёма, срока хранения, ротации и т. д. в соответствии с его настройками.

== Как работает Journald ==
Чтобы избежать проблем с ручным отслеживанием файлов, таких как ротация, распаковка или парсинг, модуль логов использует системные вызовы '''API''' для доступа ко всей функциональности. Это достигается путём открытия системной библиотеки <code>libsystemd.so</code> и её зависимостей, отображения выбранных функций из библиотеки и создания объекта контекста для связи с системой Journald. Таким образом, модуль логов становится клиентом Journald и может использовать различные его функции. Вначале модуль логов открывает обработчик в месте расположения контекста Journald по умолчанию. Конкретный путь не используется, что позволяет обработчику открыть своё известное расположение. Затем агент читает записи одну за другой, отслеживая текущую позицию.

== Включение поддержки Journald ==
Чтобы включить обнаружение логов Journald, выполните следующие шаги:

# Перейдите в '''Настройки > Мониторинг логов > Флаги функций модуля логов'''.
# Выберите '''Включить детектор логов Journald'''.
# Выберите '''Сохранить изменения'''.

Включение флага функции необходимо для opt-in. Без него даже при настроенных правилах загрузки логи Journald не появятся в Ключ-АСТРОМ.

== Настройка загрузки логов из Journald ==
Вы можете включить загрузку логов из Journald, либо настроив правило загрузки Journald по умолчанию, либо настроив загрузку в хранилище тенанта, например для <code>kubelet.service</code> как <code>Journald.unit</code> из Journald.

=== Включение правила загрузки по умолчанию ===
Для новых учётных записей правило загрузки Journald по умолчанию включено, и описанная в этом разделе настройка не требуется. Выполните следующие шаги, чтобы настроить правило загрузки Journald по умолчанию:

# Перейдите в '''Настройки > Мониторинг логов > Правила загрузки логов'''.
# Включите правило '''[Встроенное] Загружать логи Journald''', чтобы загружать все логи Journald.
# Выберите '''Сохранить изменения'''.

=== Создание пользовательского правила загрузки ===
Выполните следующие шаги, чтобы настроить загрузку в хранилище тенанта для логов <code>kubelet.service</code> из Journald:

# Перейдите в '''Настройки > Мониторинг логов > Правила загрузки логов'''.
# Выберите '''Добавить правило''' и укажите заголовок для вашей конфигурации.
# Выберите '''Добавить сопоставление'''. Это первое сопоставление для соответствия двум указанным группам процессов.
# В списке '''Атрибут''' выберите '''Юнит Journald'''.
# Выберите '''Добавить значение''' и введите <code>kubelet.service</code>.
# Снова выберите '''Добавить сопоставление''', чтобы сопоставить указанный источник данных логов.
# В списке '''Атрибут''' выберите '''Источник лога'''.
# Выберите '''Добавить значение''' и введите <code>Journald</code> в качестве значения.
# Выберите '''Сохранить изменения'''.

== Атрибуты, извлекаемые из Journald ==
Каждая запись обрабатывается для получения следующих атрибутов:
{| class="wikitable"
!Семантическое имя атрибута
!Описание
|-
|<code>timestamp</code>
|Извлекается прямым вызовом '''API''' для временной метки; результат — микросекунды с начала эпохи, преобразованные в разрешение временной области агента.
|-
|<code>content</code>
|Извлечённое значение вызова '''API''' для данных с полем <code>MESSAGE</code> в качестве селектора.
|-
|<code>journald.unit</code>
|Извлечённое значение вызова '''API''' для данных с полем <code>UNIT</code> в качестве селектора. В качестве альтернативы ищется поле <code>SYSTEMD_UNIT</code>. Может случиться, что ни одно из полей не найдено.
|-
|<code>LogEntryLevel</code>
|Извлечённое значение вызова '''API''' для данных с полем <code>PRIORITY</code> в качестве селектора, приоритет. Определения уровней приоритета см. в таблице ниже.
|}

== Уровень приоритета ==
Коды приоритета Journald используются для обозначения важности сообщения. В следующей таблице показано, как эти приоритеты преобразуются в серьёзность Ключ-АСТРОМ:
{| class="wikitable"
!Значение
!Серьёзность
!Описание
|-
|0
|Emergency
|Система неработоспособна.
|-
|1
|Alert
|Требуется немедленное исправление.
|-
|2
|Critical
|Критические условия.
|-
|3
|Error
|Условия ошибки.
|-
|4
|Warn
|Может указывать на то, что ошибка возникнет, если не предпринять действий.
|-
|5
|Notice
|Необычные события, но не условия ошибки.
|-
|6
|Info
|Обычные операционные сообщения, не требующие действий.
|-
|7
|Debug
|Сообщения, которые могут потребовать предварительного включения; полезны только для отладки.
|}