RFC 5424

RFC 5424 — это запрос комментариев (Request for Comments), опубликованный в 2009 году, который определяет стандартный формат и транспортный протокол для системного журналирования (syslog). Он был разработан рабочей группой IETF (Internet Engineering Task Force) и пришёл на смену более ранним, неформальным спецификациям syslog, в первую очередь RFC 3164, который не был стандартом, а лишь описывал сложившуюся практику. RFC 5424 устанавливает строгую структуру сообщения, поддерживает расширяемость за счёт структурированных данных и обеспечивает надёжную доставку через различные транспортные протоколы.

История и предпосылки

До появления RFC 5424 протокол syslog существовал в виде неформального стандарта, описанного в RFC 3164 (2001 год). Этот документ был информационным (не нормативным) и лишь фиксировал распространённую практику реализации syslog в Unix-системах. Основные недостатки RFC 3164 включали:

Неоднозначность формата: отсутствие чёткой границы между заголовком, структурой и сообщением, что затрудняло автоматический разбор.
Ограниченность метаданных: отсутствие возможности передавать структурированные данные (например, идентификаторы процессов, временные метки с часовыми поясами, пользовательские поля).
Ненадёжность доставки: по умолчанию использовался UDP, который не гарантирует доставку сообщений.

В 2000-х годах с ростом сложности ИТ-инфраструктур (облачные вычисления, кластеры, контейнеризация) потребность в стандартизированном, расширяемом и надёжном формате стала критической. Рабочая группа IETF по syslog начала работу над новым стандартом, результатом которого стал RFC 5424, опубликованный в марте 2009 года. Он был дополнен рядом смежных RFC: RFC 5425 (транспорт через TLS), RFC 5426 (транспорт через UDP), RFC 5427 (назначение кодов объектов).

Структура сообщения

RFC 5424 определяет строгую, иерархическую структуру сообщения syslog, которая состоит из трёх основных частей: заголовка (HEADER), структурированных данных (STRUCTURED-DATA) и сообщения (MSG). Формат представлен в виде строки в кодировке UTF-8.

Заголовок (HEADER)

Заголовок содержит обязательные поля, которые однозначно идентифицируют сообщение и его источник. Он начинается с угловой скобки <, за которой следует числовой код приоритета (PRI), затем версия (VERSION), временная метка (TIMESTAMP), имя хоста (HOSTNAME), имя приложения (APP-NAME), идентификатор процесса (PROCID) и идентификатор сообщения (MSGID).

PRI (Priority): вычисляется по формуле PRI = Facility * 8 + Severity, где Facility — код объекта (например, 0 — ядро, 1 — пользовательский уровень, 16 — локальное использование), а Severity — код важности (0 — авария, 7 — отладка). Это единственное поле, унаследованное из RFC 3164.
VERSION: целое число, указывающее версию протокола. В RFC 5424 версия всегда равна 1.
TIMESTAMP: временная метка в формате ISO 8601 с точностью до миллисекунд и указанием часового пояса (например, 2025-03-15T14:30:00.123+03:00). В отличие от RFC 3164, где метка была необязательной и могла быть локальной, здесь она строго обязательна и стандартизирована.
HOSTNAME: полное доменное имя (FQDN) или IP-адрес источника сообщения. Если хост неизвестен, используется символ - (дефис).
APP-NAME: имя приложения, сгенерировавшего сообщение (например, sshd, nginx). Максимальная длина — 48 символов.
PROCID: идентификатор процесса или потока (например, PID). Позволяет связать сообщение с конкретным экземпляром приложения.
MSGID: идентификатор типа сообщения (например, TCPIN, CHKPT). Используется для классификации сообщений без необходимости разбора тела.

Структурированные данные (STRUCTURED-DATA)

Это ключевое нововведение RFC 5424. Поле STRUCTURED-DATA представляет собой необязательный блок, который может содержать ноль или более элементов, каждый из которых состоит из идентификатора (SD-ID) и набора пар «ключ-значение» (SD-PARAM). Элементы заключаются в квадратные скобки [].

SD-ID: уникальный идентификатор элемента (например, timeQuality, origin, meta). Может быть зарегистрирован в IANA или быть частным (начинаться с @).
SD-PARAM: пары вида key="value", где значение экранируется кавычками, а специальные символы (например, \, ", ]) экранируются обратной косой чертой.

Пример структурированных данных: `` [timeQuality tzKnown="1" isSynced="1" syncAccuracy="100"][origin ip="192.168.1.1" software="MyApp"] ``

Это позволяет передавать произвольные метаданные, такие как точность синхронизации времени, географические координаты, идентификаторы транзакций, теги безопасности и т.д.

Сообщение (MSG)

Поле MSG содержит собственно текст сообщения. Оно отделяется от структурированных данных пробелом. Сообщение может быть любой длины (в отличие от RFC 3164, где ограничение было 1024 байта) и кодируется в UTF-8. Если структурированные данные отсутствуют, поле MSG может быть пустым или начинаться с символа - (дефис) для обозначения пустого сообщения.

Транспортные протоколы

RFC 5424 не привязан к конкретному транспортному протоколу, но определяет, как сообщение должно передаваться. Для этого были разработаны отдельные RFC:

RFC 5425 (TLS): определяет передачу syslog через защищённое соединение TLS (Transport Layer Security). Обеспечивает шифрование, аутентификацию и целостность данных. Рекомендуется для использования в открытых сетях и для критически важных систем.
RFC 5426 (UDP): описывает передачу syslog через UDP-дейтаграммы. Сохраняет совместимость со старыми системами, но не гарантирует доставку. Максимальный размер сообщения — 65535 байт (с учётом заголовка UDP).
RFC 5428 (TCP): неофициально используется, но стандартизирован как часть RFC 5424. Обеспечивает надёжную доставку, но требует управления сессиями.

Сообщение передаётся как одна строка, заканчивающаяся символом перевода строки (LF, ASCII 10). Для TCP и TLS используется фрейминг — перед сообщением указывается его длина в байтах (в виде десятичного числа, за которым следует пробел).

Классификация и коды

RFC 5427 (Mapping of Syslog Facility Codes) стандартизирует коды объектов (Facility) и важности (Severity). Коды Facility (0–23) включают:

0 — ядро (kernel)
1 — пользовательский уровень (user-level)
2 — почтовая система (mail)
3 — системные демоны (daemon)
4 — безопасность/авторизация (security/authorization)
16–23 — локальное использование (local0–local7)

Коды Severity (0–7) соответствуют стандарту POSIX:

0 — авария (Emergency)
1 — тревога (Alert)
2 — критическая (Critical)
3 — ошибка (Error)
4 — предупреждение (Warning)
5 — уведомление (Notice)
6 — информационное (Informational)
7 — отладка (Debug)

Применение и значение

RFC 5424 стал основой для современных систем централизованного сбора и анализа логов (SIEM-системы, такие как Splunk, ELK Stack, Graylog). Он используется в:

Операционных системах: Linux (через rsyslog, syslog-ng), BSD, macOS (частично).
Сетевом оборудовании: маршрутизаторы и коммутаторы Cisco, Juniper, Huawei поддерживают RFC 5424 в своих реализациях syslog.
Облачных платформах: AWS CloudWatch Logs, Azure Monitor, Google Cloud Logging могут принимать сообщения в формате RFC 5424.
Промышленных системах: SCADA, PLC, системы управления технологическими процессами.

Основные преимущества RFC 5424 перед RFC 3164:

Стандартизация: строгий синтаксис, который можно разобрать программно без эвристик.
Расширяемость: структурированные данные позволяют добавлять произвольные поля без нарушения совместимости.
Интернационализация: поддержка UTF-8.
Надёжность: поддержка TLS и TCP.

Критика и ограничения

Несмотря на широкое распространение, RFC 5424 имеет ряд недостатков:

Сложность реализации: строгий синтаксис требует от разработчиков точного соблюдения правил экранирования и форматирования, что увеличивает вероятность ошибок.
Избыточность: для простых систем (например, встроенных устройств) использование структурированных данных может быть избыточным.
Обратная совместимость: многие старые системы по-прежнему генерируют сообщения в формате RFC 3164, что требует от приёмников поддержки обоих форматов.
Размер сообщения: хотя ограничение на длину снято, в UDP-транспорте (RFC 5426) сохраняется ограничение в 65535 байт, что может быть недостаточно для очень длинных сообщений.

Источники

RFC 5424 — The Syslog Protocol (IETF, 2009)
RFC 5425 — Transport Layer Security (TLS) Transport Mapping for Syslog (IETF, 2009)
RFC 5426 — Transmission of Syslog Messages over UDP (IETF, 2009)
RFC 5427 — Textual Conventions for Syslog Management (IETF, 2009)
RFC 3164 — The BSD Syslog Protocol (IETF, 2001)

BFOmetr — база данных и аналитика по компаниям России.

На главную BFOmetr →