RFC: 5424
Оригинал: The Syslog Protocol
Предыдущие версии: RFC 3164
Категория: Предложенный стандарт
Дата публикации:
Автор:
Перевод: StLeutnant

Статус данного документа

Настоящий документ описывает спецификацию протокола из семейства Стандартов Интернет для сообщества Интернет, требует обсуждения и внесения предложений для улучшения. Пожалуйста, обратитесь к действующей редакции «Internet Official Protocol Standards» (STD 1), чтобы отследить состояние и статус этого протокола. Распространение данного документа не ограничено.

Уведомление об авторских правах

Copyright (C) 2009. Все права принадлежат IETF Trust и лицам, определенным как авторы документа. Все права защищены.

Данный документ подпадает под действие BCP 78 и Правовых Положений IETF Trust в Отношении Документов IETF (http://trustee.ietf.org/license-info), действующих на дату публикации этого документа. Пожалуйста, тщательно просмотрите эти документы, так как они описывают ваши права и ограничения в отношении настоящего документа.

Этот документ может содержать материалы из документов, частично или полностью принадлежащих IETF, опубликованных или ставших доступными публично до 10 ноября 2008 года. Лица, которым принадлежат права на некоторые из таких материалов, могли не переуступить IETF Trust права, позволяющие модифицировать эти материалы вне процесса стандартизации IETF. Без получения соответствующей лицензии от лиц, управляющих авторскими правами таких материалов, не только данный документ не может быть изменен вне процесса стандартизации IETF, но и производные от этого документа материалы не могут быть созданы вне процесса стандартизации IETF, за исключением подготовки его для публикации в качестве RFC или перевода на другие языки, отличные от английского.

Аннотация

Представленный документ описывает протокол системного журнала (далее, Syslog), который применяется для передачи сообщений, уведомляющих о произошедших событиях. Этот протокол базируется на многоуровневой архитектуре, которая позволяет использовать множество транспортных протоколов для передачи сообщений Syslog. Здесь также предлагается формат сообщений, который позволяет представлять информацию, специфичную для конкретного производителя расширений протокола, в структурированном виде.

Этот документ был написан с учетом исходных проектных задач традиционного Syslog. Потребность в новой многоуровневой спецификации возникла потому, что усилия по стандартизации для надежных и безопасных расширений Syslog наталкиваются на отсутствие в семействе стандартов независимого от транспорта RFC. Без такого документа каждый стандарт вынужден определять свой собственный формат пакетов Syslog и транспортный механизм, что со временем приводит к возникновению проблем совместимости. Настоящий документ пытается обеспечить фундамент, на который могут опираться расширения Syslog. Такой многоуровневый архитектурный подход обеспечивает прочную основу, позволяющую писать код один раз для каждой функции системного журнала, а не всякий раз для каждого вида транспорта.

Настоящий документ отменяет действие RFC 3164.

Оглавление

1. Введение

Настоящий документ описывает многоуровневую архитектуру, предлагаемую для системного журнала (далее, Syslog). Целью введения этой архитектуры является отделение содержимого сообщений от механизма их доставки, что позволяет упростить внедрение изменений и улучшений на каждом уровне.

В данном документе предложен стандартный формат для сообщений Syslog и сделан набросок концепции транспортных механизмов. Здесь же описаны элементы структурированных данных, которые можно использовать для передачи легко анализируемой информации, доступной для обработки в различных реализуемых расширениях протокола.

В документе не обсуждаются какие-либо форматы хранения сообщений Syslog, поскольку это находится вне сферы действия протокола и не требуется для межсистемного взаимодействия.

Этот документ был написан с учетом исходных проектных задач традиционного Syslog. Потребность в новой многоуровневой спецификации возникла потому, что усилия по стандартизации для надежных и безопасных расширений Syslog наталкиваются на отсутствие в семействе стандартов независимого от транспорта RFC. Без такого документа каждый стандарт вынужден определять свой собственный формат пакетов Syslog и транспортный механизм, что со временем приводит к возникновению проблем совместимости. Настоящий документ пытается обеспечить фундамент, на который могут опираться расширения Syslog. Такой многоуровневый архитектурный подход обеспечивает прочную основу, позволяющую писать код один раз для каждой функции системного журнала, а не всякий раз для каждого вида транспорта.

Документ отменяет действие информационного RFC 3164, который изложил сложившуюся к моменту его издания спецификацию протокола Syslog, фактически использовавшуюся в существовавших реализациях.

2. Соглашения, принятые в этом документе

Ключевые слова «ДОЛЖЕН», «НЕ ДОЛЖЕН», «ТРЕБУЕТСЯ», «МОЖЕТ», «РЕКОМЕНДУЕТСЯ», «НЕ РЕКОМЕНДУЕТСЯ» и «НЕОБЯЗАТЕЛЬНЫЙ» в настоящем документе должны интерпретироваться в соответствии с RFC 2119.

3. Определения

Syslog использует три уровня:

  • на уровне «содержимого» (content) находится управляющая информация, помещаемая в сообщения Syslog или извлекаемая из них,
  • на уровне «приложений» (application) осуществляется создание, интерпретация, маршрутизация и сохранение сообщений Syslog,
  • на уровне «транспорта» (transport) выполняется прием и передача сообщений Syslog по каналам связи.

Некоторые типы функций, исполняющихся на этих концептуальных уровнях:

  • «источник» (originator) генерирует содержимое, которое будет помещено в отправляемые сообщения Syslog,
  • «коллектор» (collector) собирает содержимое сообщений Syslog для последующего анализа,
  • «ретранслятор» (relay) пересылает сообщения Syslog, принимая их от источников или других ретрансляторов и направляя их коллекторам или другим ретрансляторам,
  • «отправитель» (transport sender) посылает сообщения Syslog по указанному транспортному протоколу,
  • «получатель» (transport receiver) получает сообщения Syslog по указанному транспортному протоколу.

На рисунке 1 показано распределение этих функций по уровням.

+---------------------+    +---------------------+
|  содержимое         |    |  содержимое         |
|---------------------|    |---------------------|
|  приложения syslog  |    |  приложения syslog  | (источник,
|                     |    |                     |  коллектор,
|                     |    |                     |  ретранслятор)
|---------------------|    |---------------------|
|  транспорт syslog   |    |  транспорт syslog   | (отправитель,
|                     |    |                     |  получатель)
+---------------------+    +---------------------+
           ^                          ^
           |                          |
            --------------------------
           Рисунок 1.  Уровни Syslog

4. Основные принципы

При обмене сообщениями Syslog применяются следующие принципы:

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

4.1. Примеры сценариев развертывания

Примеры сценариев развертывания показаны на рисунке 2. Другие комбинации этих примеров также являются приемлемыми. Как отмечено на следующем рисунке, ретрансляторы могут пересылать получателям все или некоторые из полученных сообщений, а также отправлять сообщения, сгенерированные самим ретранслятором. Прямоугольниками на рисунке изображены приложения Syslog.

+--------+         +---------+
|Источник|---->----|Коллектор|
+--------+         +---------+
+--------+         +------------+         +---------+
|Источник|---->----|Ретранслятор|---->----|Коллектор|
+--------+         +------------+         +---------+
+--------+   +------------+        +------------+   +---------+
|Источник|->-|Ретранслятор|->-..->-|Ретранслятор|->-|Коллектор|
+--------+   +------------+        +------------+   +---------+
+--------+         +------------+         +---------+
|Источник|---->----|Ретранслятор|---->----|Коллектор|
|        |-+       +------------+         +---------+
+--------+  \
             \     +------------+         +---------+
              +->--|Ретранслятор|---->----|Коллектор|
                   +------------+         +---------+
+--------+         +---------+
|Источник|---->----|Коллектор|
|        |-+       +---------+
+--------+  \
             \     +------------+         +---------+
              +->--|Ретранслятор|---->----|Коллектор|
                   +------------+         +---------+
+--------+         +------------+            +---------+
|Источник|---->----|Ретранслятор|---->-------|Коллектор|
|        |-+       +------------+        +---|         |
+--------+  \                           /    +---------+
             \     +------------+      /
              +->--|Ретранслятор|-->--/
                   +------------+
+--------+         +------------+              +---------+
|Источник|---->----|Ретранслятор|---->---------|Коллектор|
|        |-+       +------------+           +--|         |
+--------+  \                              /   +---------+
             \     +--------------+       /
              \    |+------------+|      /
               +->-||Ретранслятор||->---/
                   |+------------||    /
                   ||Источник    ||->-/
                   |+------------+|
                   +--------------+
Рисунок 2.  Некоторые возможные сценарии развертывания Syslog

5. Протокол транспортного уровня

Данный документ не определяет какой-либо протокол транспортного уровня. Вместо этого он описывает формат сообщений Syslog в форме, независимой от транспортного уровня. Транспортные механизмы Syslog определяются в других документах. Один из таких транспортов описан в RFC 5426 и соответствует традиционному транспорту UDP. Этот транспорт необходим для поддержания совместимости, поскольку транспорт UDP исторически использовался для передачи сообщений Syslog.

Любой транспортный протокол Syslog НЕ ДОЛЖЕН сознательно изменять сообщения Syslog. Если транспортному протоколу требуется выполнять временные преобразования на стороне отправителя, то эти преобразования ДОЛЖНЫ быть отменены транспортным протоколом на стороне получателя так, чтобы ретранслятор или коллектор увидели точную копию сообщения, поступившего от источника или предыдущего ретранслятора. В противном случае будет нарушена возможность криптографической верификации сообщения (например, с помощью подписи). Конечно, изменение сообщения может произойти из-за ошибок при передаче или других проблем. Защита от таких изменений не входит в задачи данного документа.

5.1. Минимально требуемое соответствие транспорта

Все реализации данной спецификации ДОЛЖНЫ поддерживать транспорт TLS, как это описано в RFC 5425.

Всем реализациям данной спецификации РЕКОМЕНДУЕТСЯ поддерживать транспорт UDP, как это описано в RFC 5426.

При практическом развертывании систем по данной спецификации РЕКОМЕНДУЕТСЯ использовать транспорт TLS.

6. Формат сообщений

Описание формата сообщений Syslog приводится с помощью обозначений ABNF (Augmented Backus-Naur Form) в соответствии с RFC 5234:

SYSLOG-MSG      = HEADER SP STRUCTURED-DATA [SP MSG]
HEADER          = PRI VERSION SP TIMESTAMP SP HOSTNAME SP
                  APP-NAME SP PROCID SP MSGID
PRI             = "<" PRIVAL ">"
PRIVAL          = 1*3DIGIT
                  в диапазоне 0 .. 191
VERSION         = NONZERO-DIGIT 0*2DIGIT
HOSTNAME        = NILVALUE / 1*255PRINTUSASCII
APP-NAME        = NILVALUE / 1*48PRINTUSASCII
PROCID          = NILVALUE / 1*128PRINTUSASCII
MSGID           = NILVALUE / 1*32PRINTUSASCII
TIMESTAMP       = NILVALUE / FULL-DATE "T" FULL-TIME
FULL-DATE       = DATE-FULLYEAR "-" DATE-MONTH "-" DATE-MDAY
DATE-FULLYEAR   = 4DIGIT
DATE-MONTH      = 2DIGIT
                  в диапазоне 01-12
DATE-MDAY       = 2DIGIT
                  в диапазонах 01-28, 01-29, 01-30, 01-31,
                  в зависимости от количества дней в месяце
FULL-TIME       = PARTIAL-TIME TIME-OFFSET
PARTIAL-TIME    = TIME-HOUR ":" TIME-MINUTE ":" TIME-SECOND
                  [TIME-SECFRAC]
TIME-HOUR       = 2DIGIT
                  в диапазоне 00-23
TIME-MINUTE     = 2DIGIT
                  в диапазоне 00-59
TIME-SECOND     = 2DIGIT
                  в диапазоне 00-59
TIME-SECFRAC    = "." 1*6DIGIT
TIME-OFFSET     = "Z" / TIME-NUMOFFSET
TIME-NUMOFFSET  = ("+" / "-") TIME-HOUR ":" TIME-MINUTE
STRUCTURED-DATA = NILVALUE / 1*SD-ELEMENT
SD-ELEMENT      = "[" SD-ID *(SP SD-PARAM) "]"
SD-PARAM        = PARAM-NAME "=" %d34 PARAM-VALUE %d34
SD-ID           = SD-NAME
PARAM-NAME      = SD-NAME
PARAM-VALUE     = UTF-8-STRING
                  одиночные символы %d34 ("), '\' и ']'
                  ДОЛЖНЫ быть экранированы предшествующим
                  символом '\'
SD-NAME         = 1*32PRINTUSASCII
                  исключая '=', %d32 (пробел), ']', %d34 (")
MSG             = MSG-ANY / MSG-UTF8
MSG-ANY         = *OCTET
                  начинается не с метки порядка байтов
                  (BOM - Byte Order Mask)
MSG-UTF8        = BOM UTF-8-STRING
BOM             = %xEF.BB.BF
UTF-8-STRING    = *OCTET
                  строка символов UTF-8, как определено в RFC 3629
OCTET           = %d00-255
SP              = %d32
PRINTUSASCII    = %d33-126
NONZERO-DIGIT   = %d49-57
DIGIT           = %d48 / NONZERO-DIGIT
NILVALUE        = "-"

6.1. Длина сообщения

Ограничения на размер сообщений Syslog диктуются используемым транспортным механизмом. Не существует верхнего предела как такового. Каждый транспортный механизм сам определяет наименьший максимум длины сообщения, который необходимо поддерживать, и эта наименьшая максимальная длина ДОЛЖНА быть не меньше 480 октетов.

Любой получатель ДОЛЖЕН быть в состоянии принимать сообщения длиной до 480 октетов включительно. Во всех реализациях РЕКОМЕНДУЕТСЯ обеспечить получателям возможность приема сообщений длиной до 2048 октетов включительно. Получатели МОГУТ получать сообщения длиной больше 2048 октетов. Если получателю приходит сообщение, длина которого больше, чем он поддерживает, то РЕКОМЕНДУЕТСЯ обрезать полезную нагрузку сообщения на приеме. С другой стороны, получатель МОЖЕТ отбросить такое сообщение.

Если получатель обрезает сообщения, то отсекаться ДОЛЖНЫ данные в конце сообщения. После усечения в сообщении МОГУТ появиться символы с недействительной кодировкой UTF-8 или стать недействительным содержимое полей STRUCTURED-DATA (структурированные-данные). Получатель МОЖЕТ отбросить такое сообщение или попытаться обработать его настолько, насколько это возможно в данном случае.

6.2. HEADER (заголовок)

Данные в поле HEADER ДОЛЖНЫ быть представлены в 7-битной ASCII-кодировке, как это описано в RFC 5234 (в 8-битном байте используются младшие 7 бит, старший бит всегда равен 0). Символы в такой кодировке еще называют «ASCII-кодами» в соответствии с определением, данным в «USA Standard Code for Information Interchange» [ANSI.X3-4.1968].

Формат поля HEADER спроектирован таким образом, чтобы обеспечить некоторую совместимость со старым Syslog, основанном на BSD. Подробности изложены в Приложении A.1.

6.2.1. PRI (приоритет)

Поле PRI МОЖЕТ быть три, четыре или пять байтов длиной и должно содержать символы угловых скобок в первой и последней позициях. Поле PRI начинается с символа < (знак «меньше», %d60), за которым следует некое число, и заканчивается символом > (знак «больше», %d62). Число, заключенное в угловые скобки, называется полем PRIVAL (значение-приоритета) и отображает одновременно Субъект (Facility) и Важность (Severity) сообщения. Поле PRIVAL содержит одну, две или три десятичных цифры (DIGIT, в терминах ABNF), используя символы с кодами от %d48 (для 0 ) до %d57 (для 9 ) в диапазоне числовых значений от 0 до 191.

Значения Субъекта и Важности не нормированы, но часто используются. Они приведены в следующих таблицах просто для информации. Субъект ДОЛЖЕН иметь значение в диапазоне от 0 до 23 включительно.

Код Категория субъекта
0 сообщения ядра
1 сообщения пользовательского уровня
2 почтовая система
3 системные службы (daemons)
4 сообщения безопасности/авторизации
5 внутренние сообщения, сгенерированные syslogd
6 подсистема печати
7 подсистема новостных групп (телеконференций, NNTP)
8 подсистема UUCP
9 служба времени
10 сообщения безопасности/авторизации
11 служба FTP
12 подсистема NTP
13 сообщения аудита
14 аварийные сообщения
15 служба времени
16 локального происхождения 0 (local0)
17 локального происхождения 1 (local1)
18 локального происхождения 2 (local2)
19 локального происхождения 3 (local3)
20 локального происхождения 4 (local4)
21 локального происхождения 5 (local5)
22 локального происхождения 6 (local6)
23 локального происхождения 7 (local7)
Таблица 1. Коды категорий субъектов сообщений Syslog

Это же поле в каждом сообщении отображает и десятичный индикатор уровня Важности. В следующей таблице представлено описание его числовых значений. Уровень Важности ДОЛЖЕН иметь значение в диапазоне от 0 до 7 включительно.

Код Уровни важности
0 Авария (Emergency): система неработоспособна
1 Тревога (Alert): система требует немедленного вмешательства
2 Критический (Critical): состояние системы критическое
3 Ошибка (Error): сообщения о возникших ошибках
4 Предупреждение (Warning): предупреждения о возможных проблемах
5 Замечание (Notice): сообщения о нормальных, но важных событиях
6 Информационный (Informational): информационные сообщения
7 Отладка (Debug): отладочные сообщения
Таблица 2. Уровни важности сообщений Syslog

Вычисление значения приоритета производится умножением числового кода Субъекта на 8 и последующим прибавлением числового уровня Важности. Например, сообщения ядра (Субъект=0) с уровнем важности «Авария» (Важность=0) получат приоритет 0. А сообщения «локального происхождения 4» (Субъект=20) с уровнем важности «Замечание» (Важность=5) получат приоритет 165. Данное числовое значение будет помещено в поле PRI соответствующих сообщений Syslog внутри угловых скобок в виде подстроки <0> в первом случае и <165> во втором. Символ 0 может следовать сразу за символом < только в одном случае — если приоритет равен 0. Во всех остальных случаях лидирующие 0 НЕ ДОЛЖНЫ использоваться.

6.2.2. VERSION (версия)

В поле VERSION объявляется версия поддерживаемой спецификации протокола Syslog. Номер версии ДОЛЖЕН увеличиваться для каждой новой спецификации протокола Syslog, изменяющей формат поля HEADER в любой его части. Изменения включают как добавление и удаление полей, так и изменение синтаксиса и семантики существующих полей. Данный документ использует значение 1 для поля VERSION. Это значение назначено IANA с помощью Процедуры Стандартизации (Standarts Action), как это описано в RFC 5226 (см. раздел 9.1. настоящего документа).

6.2.3. TIMESTAMP (отметка-времени)

В поле TIMESTAMP помещается формализованная отметка времени, наследуемая из RFC 3339.

Поскольку RFC 3339 допускает широкое синтаксическое разнообразие, то здесь на синтаксис накладываются ограничения. Данные в поле TIMESTAMP ДОЛЖНЫ соответствовать следующим ограничениям:

  • символы T и Z ДОЛЖНЫ использоваться в верхнем регистре,
  • использование символа T ТРЕБУЕТСЯ,
  • корректировочные секунды НЕ ДОЛЖНЫ использоваться[перевод] .

Источнику РЕКОМЕНДУЕТСЯ заполнять поле TIME-SECFRAC (доли-секунды) с той точностью, насколько позволяет это сделать точность и производительность его часов. Элемент структурированных данных SD-ID timeQuality , описанный в Разделе 7.1, позволяет источнику указать точность и степень доверия к отметке времени.

Приложения Syslog должны использовать NILVALUE (пропуск) в качестве TIMESTAMP, если они неспособны получить системное время.

6.2.3.1. Примеры
  • Пример 1:
  • 1985-04-12T23:20:50.52Z

    Здесь представлена запись отметки времени, соответствующая 23 часам 20 минутам 50 целым 52 сотым секунды 12 апреля 1985 года в UTC.

  • Пример 2:
  • 1985-04-12T19:20:50.52-04:00

    Та же самая отметка времени, что и в предыдущем примере, но по Восточному Стандартному Времени США (с учетом перехода на летнее время).

  • Пример 3:
  • 2003-10-11T22:14:15.003Z

    Здесь представлена запись отметки времени, соответствующая 22 часам 14 минутам 15 секундам 3 миллисекундам 11 октября 2003 года в UTC. Отметка предоставлена в миллисекундном разрешении. В действительности, источник мог иметь лучшее разрешение, но предоставил только три действующие цифры в дробной части секунд.

  • Пример 4:
  • 2003-08-24T05:14:15.000003-07:00

    Здесь представлена запись отметки времени, соответствующая 5 часам 14 минутам 15 секундам 3 микросекундам 24 августа 2003 года по Тихоокеанскому Времени США с учетом летного времени. Отметка предоставлена в микросекундном разрешении (поле TIME-SECFRAC).

  • Пример 5 — неправильное значение TIMESTAMP:
  • 2003-08-24T05:14:15.000000003-07:00

    Отметка, подобная предыдущему примеру, но в наносекундном разрешении, является неправильной, поскольку в поле TIME-SECFRAC допустимо не больше 6 цифр.

6.2.4. HOSTNAME (имя-узла)

Поле HOSTNAME идентифицирует машину, сгенерировавшую сообщение Syslog.

Для заполнения поля HOSTNAME РЕКОМЕНДУЕТСЯ использовать имя узла и имя домена источника в формате, изложенном в STD 13 [RFC1034]. Этот формат в данном документе называется полностью квалифицированным доменным именем (FQDN).

На практике, не все приложения Syslog в состоянии предоставить FQDN. В этих случаях поле HOSTNAME МОЖЕТ быть заполнено другими значениями, определенными в данном документе для такой ситуации. Приложениям Syslog РЕКОМЕНДУЕТСЯ использовать первое из возможных значений в порядке выбора. Порядок выбора значений для заполнения поля HOSTNAME следующий:

  • FQDN
  • постоянный IP-адрес
  • имя узла
  • динамически выделяемый IP-адрес
  • NILVALUE

Если используются адреса IPv4, то они ДОЛЖНЫ быть представлены в десятично-точечной нотации, как это изложено в STD 13 [RFC1035]. Для адресов IPv6 ДОЛЖНО быть использовано любое допустимое текстовое представление, как это изложено в Разделе 2.2 RFC 4291.

Приложениям Syslog РЕКОМЕНДУЕТСЯ использовать однажды выбранное значение так долго, насколько это возможно.

Значение NILVALUE РЕКОМЕНДУЕТСЯ использовать только тогда, когда у приложения Syslog нет никакой возможности получить другие значения, характеризующие узел. Эта ситуация считается крайне маловероятной.

6.2.5. APP-NAME (имя-приложения)

В поле APP-NAME РЕКОМЕНДУЕТСЯ идентифицировать устройство или приложение, сгенерировавшее сообщение. Строка, использующаяся для заполнения, не имеет строгой семантики. Поле предназначено для отфильтровывания сообщений ретранслятором или коллектором.

Значение NILVALUE МОЖЕТ использоваться тогда, когда приложение Syslog не знает своего имени или не может его предоставить. Может случиться так, что устройство неспособно предоставить эту информацию из-за локальной политики или потому, что информация не доступна, а может и не применима для устройства.

Значение для заполнения этого поля МОЖЕТ быть присвоено оператором.

6.2.6. PROCID (идентификатор-процесса)

Значение, помещаемое в поле PROCID сообщения, не имеет особого значения за исключением того, что его изменение сигнализирует о перерыве в генерации потока сообщений Syslog. Это поле не имеет строгого синтаксиса или семантики; значение его зависит от реализации и/или назначения оператора. Значение NILVALUE МОЖЕТ быть использовано тогда, когда данные не предоставляются.

Поле PROCID часто применяется для указания имени процесса, общающегося с системой Syslog, или его идентификатора. Значение NILVALUE может использоваться, если ID процесса недоступен. Встраиваемые системы, где в операционных системах не существует ID процессов, могут использовать ID перезагрузки.

Поле PROCID позволяет во время анализа записей журнала выявить перерывы в потоке генерации сообщений Syslog по изменению значения в этом поле. С другой стороны, поле PROCID не достаточно надежно идентифицирует рестарт процессов, поскольку после рестарта новому процессу, общающемуся с Syslog, может быть назначено то же самое значение, что и предыдущему.

Поле PROCID также может применяться для разделения сообщений по группам. Например, почтовый агент SMTP может помещать в поле PROCID свой идентификатор транзакции SMTP, что позволяет ретранслятору или коллектору сгруппировать сообщения по транзакциям SMTP.

6.2.7. MSGID (идентификатор-сообщения)

В поле MSGID РЕКОМЕНДУЕТСЯ идентифицировать тип сообщения. Например, межсетевой экран может использовать в этом поле значение TCPIN для входящего и TCPOUT для исходящего трафика TCP. Сообщения с одним и тем же значением поля MSGID должны отражать события с одинаковым смыслом. Строковое значение поля MSGID не имеет строгой семантики. Поле предназначено для отфильтровывания сообщений ретранслятором или коллектором.

Значение NILVALUE РЕКОМЕНДУЕТСЯ использовать, если приложение Syslog не может предоставить какое-либо значение.

Значение этого поля МОЖЕТ быть назначено оператором.

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

Поле STRUCTURED-DATA предоставляет механизм быстрого информирования в строго определенном, легко разбираемом грамматически и легко интерпретируемом формате. Существует множество сценариев его использования. Это может быть информация о свойствах сообщения Syslog или специфичная для приложения информация, например, счетчики трафика или IP-адресов.

Поле STRUCTURED-DATA может содержать один или несколько элементов структурированных данных, которые обозначаются как SD-ELEMENT в данном документе, или не содержать ни одного элемента данных.

В случае, если поле STRUCTURED-DATA не содержит ни одного элемента данных, то ему ДОЛЖНО быть присвоено значение NILVALUE.

Данные в поле STRUCTURED-DATA представляются в 7-битной ASCII-кодировке, как это описано в RFC 5234. Символы в такой кодировке еще называют «ASCII-кодами» в соответствии с определением, данным в «USA Standard Code for Information Interchange» [ANSI.X3-4.1968]. Исключением является поле PARAM-VALUE (см. Раздел 6.3.3), данные в котором ДОЛЖНЫ быть представлены в кодировке UTF-8.

Коллектор МОЖЕТ игнорировать поврежденные или несоответствующие формату элементы поля STRUCTURED-DATA. Ретранслятор ДОЛЖЕН перенаправлять получателю всё сообщение целиком без каких-либо изменений, включая поврежденные или несоответствующие формату элементы поля STRUCTURED-DATA.

6.3.1. SD-ELEMENT (элемент-данных)

Элемент данных SD-ELEMENT состоит из имени элемента данных и одной или нескольких пар полей «имя-значение», определяющих параметры элемента данных. Имя элемента данных обозначается как SD-ID, а пары, задающие параметры, обозначаются как SD-PARAM.

6.3.2. SD-ID (идентификатор-данных)

Поля SD-ID представляют собой регистрозависимые уникальные идентификаторы назначения и типа элемента данных SD-ELEMENT. Один и тот же SD-ID НЕ ДОЛЖЕН присутствовать в сообщении больше, чем один раз.

Существуют два формата поля SD-ID:

  • Имена, которые не содержат символ «коммерческое at» (@ , %d64 ABNF) зарезервированы для назначения IETF, как это описано в BCP26 [RFC5226]. В настоящий момент эти имена перечислены в Разделе 7. Имена в данном формате допустимы, если только они сперва зарегистрированы в IANA. Зарегистрированные имена НЕ ДОЛЖНЫ содержать следующие символы: «коммерческое at» (@ , %d64 ABNF), знак равенства (= , %d61 ABNF), закрывающая квадратная скобка (] , %d93 ABNF), двойная кавычка (" , %d34 ABNF), пробел (%d32 ABNF) и управляющие символы (%d127 ABNF и символы с кодами меньше %d32 ABNF).
  • Любой может определить дополнительные имена для SD-ID в формате имя@личный-номер , например, [email protected] . Формат части имени, предшествующей знаку @ , не определен, за исключением того, что эта часть ДОЛЖНА быть строкой из набора символов US-ASCII и НЕ ДОЛЖНА содержать следующие символы: «коммерческое at» (@ , %d64 ABNF), знак равенства (= , %d61 ABNF), закрывающая квадратная скобка (] , %d93 ABNF), двойная кавычка (" , %d34 ABNF), пробел (%d32 ABNF) и управляющие символы (%d127 ABNF и символы с кодами меньше %d32 ABNF). Часть имени после знака @ ДОЛЖНА быть личным номером производителя, как это определено в Разделе 7.2.2. Отметим, что личный номер 32473 используется в данном документе во всех примерах, поскольку он зарезервирован IANA именно для применения в документации. Разработчикам будет необходимо использовать свой собственный личный номер производителя в параметре enterpriseID при создании локальных расширений имен для SD-ID.

6.3.3. SD-PARAM (параметр-данных)

Каждое поле SD-PARAM состоит из имени параметра, обозначаемом как PARAM-NAME, и значения, обозначаемом как PARAM-VALUE.

Поле PARAM-NAME регистрозависимо. IANA управляет всеми именами параметров PARAM-NAME, исключая используемые в элементах данных, имена которых в SD-ID содержат символ @ . Область действия конкретного PARAM-NAME ограничена соответствующим SD-ID. Таким образом одинаковые имена параметров в PARAM-NAME не говорят о том, что они имеют одинаковое значение в разных SD-ID.

Для поддержки интернациональных символов поле PARAM-VALUE ДОЛЖНО использовать кодировку UTF-8. Приложения Syslog МОГУТ создавать любые допустимые последовательности UTF-8. Приложения Syslog ДОЛЖНЫ признавать любые допустимые последовательности UTF-8 в их «кратчайшей форме». Наличие управляющих символов в PARAM-VALUE НЕ ДОЛЖНО приводить к ошибке. Приложения Syslog МОГУТ изменять сообщения, содержащие управляющие символы (например, заменять октеты, имеющие значение 0 (NUL в US-ASCII), на четырехсимвольную строку #000 ). По причинам, изложенным в Разделе 3.1 UNICODE TR36, при создании сообщения источник ДОЛЖЕН использовать «кратчайшую форму», а коллекторы и ретрансляторы НЕ ДОЛЖНЫ интерпретировать сообщения в «не кратчайшей форме».

Чтобы избежать ошибок грамматического разбора, одиночные символы двойная кавычка (" , %d34 ABNF), закрывающая квадратная скобка (] , %d93 ABNF) и обратная наклонная черта (\ , %d92 ABNF), встречающиеся в поле PARAM-VALUE, ДОЛЖНЫ быть экранированы, то есть предваряться символом обратной наклонной черты — \" , \] и \\ соответственно. Экранирование закрывающей квадратной скобки (] , %d93 ABNF) не является строго обязательным, но ТРЕБУЕТСЯ во избежание ошибок грамматического разбора со стороны приложений, реализующих данный протокол Syslog. По принятым соглашениям символ обратной наклонной черты используется для экранирования управляющих символов и в других частях сообщения Syslog, также как и в традиционном Syslog.

Последовательность, в которой за символом обратной наклонной черты (\ ) следует любой другой символ, отличный от трех вышеперечисленных, считается недопустимой. В этом случае, как сам символ обратной наклонной черты, так и следующий за ним символ ДОЛЖНЫ рассматриваться как отдельные символы в соответствии с правилами грамматического разбора. Недопустимая последовательность НЕ ДОЛЖНА рассматриваться иным способом.

В одном SD-ELEMENT МОЖЕТ присутствовать несколько полей SD-PARAM.

6.3.4. Изменение управляющих элементов

Синтаксис и семантика однажды определенных SD-ID и PARAM-NAME НЕ ДОЛЖНЫ изменяться. Если требуется изменить существующий объект, то необходимо создать новые SD-ID или PARAM-NAME, оставив неизменными старые. ДОПОЛНИТЕЛЬНО новые PARAM-NAME МОГУТ быть добавлены в существующий SD-ID.

6.3.5. Примеры

Во всех примерах данного раздела представлена только та часть сообщения, которая содержит структурированные данные. Данные в примерах должны бы быть записаны в одну строку. Разбиение на несколько строк сделано здесь только с целью удобочитаемости. Описание следует после каждого примера.

  • Пример 1 — допустимо:
  • [[email protected]
 iut="3" eventSource="Application"
 eventID="1011"]

    В этом примере показан элемент структурированных данных, которым IANA не управляет, с SD-ID [email protected] и тремя параметрами.

  • Пример 2 — допустимо:
  • [[email protected]
 iut="3" eventSource="Application"
 eventID="1011"][[email protected]
 class="high"]

    Тот же самый пример, что и предыдущий, но содержащий два элемента структурированных данных. Отметим, что второй элемент структурированных данных следует непосредственно за первым (пробелом не отделяется).

  • Пример 3 — недопустимо:
  • [[email protected]
 iut="3" eventSource="Application"
 eventID="1011"] [[email protected]
 class="high"]

    Пример, практически идентичный предыдущему, но содержащий одну из трудноуловимых ошибок — второй элемент структурированных данных отделяется от первого пробелом. В данном случае будет считаться, что поле STRUCTURED-DATA завершилось сразу после первого элемента, а второй элемент будет интерпретирован как часть поля MSG.

  • Пример 4 — недопустимо:
  • [ [email protected]
 iut="3" eventSource="Application"
 eventID="1011"][[email protected]
 class="high"]

    В данном примере показана другая трудноуловимая ошибка — в первом элементе после открывающей квадратной скобки находится пробел. Поле SD-ID элемента структурированных данных ДОЛЖНО располагаться непосредственно после открывающей квадратной скобки; имеющийся пробел делает поле STRUCTURED-DATA недопустимым. Приложение Syslog МОЖЕТ отбросить данное сообщение.

  • Пример 5 — допустимо:
  • [sigSig ver="1" rsID="1234" ... signature="..."]

    Это допустимый пример. Здесь показан SD-ID, гипотетически поддерживаемый IANA. Многоточия подставлены вместо содержимого, которое для краткости пропущено в данном примере.

6.4. MSG (сообщение)

Поле MSG содержит информацию о событии в свободной форме.

Данные в поле MSG РЕКОМЕНДУЕТСЯ представлять в UNICODE, используя кодировку UTF-8, как это описано в RFC 3629. Если приложение Syslog не в состоянии применять UNICODE, то оно МОЖЕТ использовать любую другую кодировку.

Приложениям Syslog РЕКОМЕНДУЕТСЯ избегать использования октетов, имеющих значение меньше 32 (традиционно, для US-ASCII в диапазоне от 0 до 31, включительно, находятся управляющие символы, за исключением символа DEL). Хотя октеты с такими значениями и являются допустимыми, но приложения Syslog МОГУТ заменять такие символы при приеме сообщений, например, последовательностями символов, использующих экранирование с помощью символа обратной наклонной черты \ . Например, октеты со значением 0 могут быть заменены на символьные последовательности \0 . Октеты, имеющие значение вне этого диапазона, приложениям Syslog изменять НЕ РЕКОМЕНДУЕТСЯ.

Если приложение Syslog использует кодировку UTF-8, то строка ДОЛЖНА начинаться с метки порядка байтов (Byte Order Mask, BOM — %xEF.BB.BF в терминах ABNF), являющейся признаком использования UTF-8. Приложения Syslog ДОЛЖНЫ применять кодировку UTF-8 в ее «кратчайшей форме» и МОГУТ использовать любые допустимые последовательности UTF-8.

Если приложение Syslog обнаруживает, что поле MSG начинается с BOM, но содержит строку не в «кратчайшей форме» кодировки UTF-8, то оно НЕ ДОЛЖНО интерпретировать его, как сообщение в кодировке UTF-8, по причинам, изложенным в разделе 3.1 UNICODE TR36 (см. Приложение A.8).

Таким образом, согласно UNICODE TR36, приложение Syslog вообще НЕ ДОЛЖНО интерпретировать сообщения, представленные не в «кратчайшей форме». Оно также НЕ ДОЛЖНО интерпретировать недопустимые последовательности UTF-8.

6.5. Примеры

Далее следуют примеры и описания допустимых сообщений Syslog. Они основаны на подобных примерах из RFC 3164 и, возможно, знакомы читателям. Метка порядка байтов, не имеющая представления в виде отображаемого символа, изображается последовательностью из 3 символов BOM .

  • Пример 1 — без STRUCTURED-DATA.
  • <34>1 2003-10-11T22:14:15.003Z mymachine.example.com
 su - ID47 - BOM'su root' failed for lonvick on /dev/pts/8

    В этом примере представлено сообщение, соответствующее протоколу Syslog версии 1. Оно сгенерировано субъектом с типом 4 (безопасность/авторизация) и получило уровень важности 2 (критический). Событие, описываемое сообщением, произошло 11 октября 2003 года в 22 часа 14 минут 15 секунд и 3 миллисекунды по UTC на машине, которая идентифицирует себя FQDN mymachine.example.com . Сообщение создано приложением (процессом) с именем su , идентификатор процесса неизвестен (- в поле PROCID). Сообщению присвоен идентификатор ID47 . Текст сообщения 'su root' failed for lonvick on /dev/pts/8 представлен в кодировке UTF-8 (BOM в начале текста). Сообщение не содержит структурированных данных (- в поле STRUCTURED-DATA).

  • Пример 2 — без STRUCTURED-DATA.
  • <165>1 2003-08-24T05:14:15.000003-07:00 192.0.2.1
 myproc 8710 - - %% It's time to make the do-nuts.

    В этом примере также представлено сообщение, соответствующее протоколу Syslog версии 1. Оно сгенерировано субъектом с типом 20 (локальный 4) и получило уровень важности 5 (замечание). Событие, описываемое сообщением, произошло 24 августа 2003 года в 5 часов 14 минут 15 секунд и 3 микросекунды по времени часового пояса, имеющего сдвиг -7 часов относительно UTC на машине, которая смогла идентифицировать себя только динамически выделяемым IP-адресом 192.0.2.1 . Сообщение создано приложением (процессом) с именем myproc и идентификатором 8710 (например, в UNIX это может быть PID). Идентификатора у сообщения нет (- в поле MSGID). Также отсутствуют структурированные данные (- в поле STRUCTURED-DATA). В какой кодировке представлен текст сообщения %% It's time to make the do-nuts. неизвестно (BOM в начале текста отсутствует).

  • Пример 3 — со STRUCTURED-DATA.
  • <165>1 2003-10-11T22:14:15.003Z mymachine.example.com
 evntslog - ID47 [[email protected]
 iut="3" eventSource="Application"
 eventID="1011"] BOMAn application event log entry...

    В этом примере представлено сообщение, аналогичное сообщению из Примера 1, но содержащее еще и структурированные данные, состоящие из единственного элемента [[email protected] iut="3" eventSource="Application" eventID="1011"] . Текст сообщения An application event log entry... представлен в кодировке UTF-8 (BOM в начале текста).

  • Пример 4 — только STRUCTURED-DATA.
  • <165>1 2003-10-11T22:14:15.003Z mymachine.example.com
 evntslog - ID47 [[email protected]
 iut="3" eventSource="Application"
 eventID="1011"][[email protected]
 class="high"]

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

7. Идентификаторы структурированных данных

В этом разделе дано определение SD-ID, первоначально зарегистрированных IANA. Определение элементов структурированных данных можно найти в разделе 6.3. Все SD-ID определены как НЕОБЯЗАТЕЛЬНЫЕ.

В некоторых случаях требуется количественное определение максимальной длины параметра. В каждом таком случае приложение Syslog ДОЛЖНО подготовить необходимое количество октетов, достаточное для размещения любых допустимых символов в кодировке UTF-8. Поскольку каждый символ может занимать до 6 октетов, то РЕКОМЕНДУЕТСЯ при подготовке выделять не менее 6 октетов на символ.

7.1. timeQuality

SD-ID timeQuality МОЖЕТ использоваться источником для описания своего понимания системного времени. Этот SD-ID ДОЛЖЕН быть использован, если источник не синхронизирован должным образом с внешними надежными источниками точного времени или он не уверен в правильности информации о своём поясном времени. Основное назначение данного элемента структурированных данных состоит в том, чтобы дать некоторую информацию об уровне доверия к данным, находящимся в поле TIMESTAMP (см. раздел 6.2.3). Все параметры определены как НЕОБЯЗАТЕЛЬНЫЕ.

7.1.1. tzKnown

Значение параметра tzKnown показывает известно ли источнику его поясное время. Если известно, то ДОЛЖНО использоваться значение 1 . Если информация о поясном времени вызывает сомнения, то ДОЛЖНО использоваться значение 0 . Если поясное время известно, но источник решил применять значения времени в UTC, то также ДОЛЖНО использоваться значение 1 (поскольку поясное время известно).

7.1.2. isSynced

Значение параметра isSynced показывает синхронизируются ли локальные часы источника с внешними надежными источниками точного времени, например, с помощью NTP. Если синхронизируются, то ДОЛЖНО использоваться значение 1 . Если нет, то ДОЛЖНО использоваться значение 0 .

7.1.3. syncAccuracy

Значение параметра syncAccuracy показывает, что источник думает о точности синхронизации времени своих локальных часов. Передаваемое число отображает количество микросекунд, на которое могут отклоняться локальные часы источника между интервалами синхронизации.

Если параметру isSynced присвоено значение 0 , то параметр syncAccuracy НЕ ДОЛЖЕН присутствовать. Если параметру isSynced присвоено значение 1 , а параметр syncAccuracy отсутствует, то коллектор или ретранслятор в праве предположить, что точность предоставляемой информации о времени достаточна, чтобы считаться правильной. Параметр syncAccuracy ДОЛЖЕН использоваться только в том случае, если источнику действительно известна информация о надежности внешнего источника точного времени. В большинстве случаев он может получить эту углубленную информацию из конфигурации, подготовленной администратором.

7.1.4. Примеры

Пример заполнения параметров источником, не имеющим информации о поясном времени и не знающем синхронизируются ли его локальные часы с внешним надежным источником точного времени:

[timeQuality tzKnown="0" isSynced="0"]

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

В следующем примере источник знает собственное поясное время и уверен, что его локальные часы синхронизируются с внешним надежным источником точного времени:

[timeQuality tzKnown="1" isSynced="1"]

Последний пример демонстрирует источник, который не только знает собственное поясное время и уверен, что его локальные часы синхронизируются с внешним надежным источником точного времени, но и имеет информацию о точности синхронизации:

[timeQuality tzKnown="1" isSynced="1" syncAccuracy="60000000"]

Различие между этим и предыдущим примером в том, что в последнем случае источник рассчитывает, что указанное им время не будет отличаться от официального более, чем на 60 секунд. Таким образом, если источник указывает время события 09:00:00, то значит оно произошло не ранее 08:59:00 и не позднее 09:01:00 официального времени.

7.2. origin

SD-ID origin МОЖЕТ использоваться для описания происхождения сообщения Syslog. Все перечисленные ниже параметры определены как НЕОБЯЗАТЕЛЬНЫЕ.

Применение этих параметров в первую очередь направлено на облегчение работы анализаторов системного журнала и других подобных приложений.

7.2.1. ip

В качестве значения параметра ip источник использует свой IP-адрес, известный ему на момент генерации сообщения. Он ДОЛЖЕН быть представлен в текстовом виде, как это описано в разделе 6.2.4.

Этот параметр может использоваться для предоставления идентифицирующей информации в дополнение к представленной в поле HOSTNAME. Особенно полезно таким способом включать IP-адрес в сообщение, когда поле HOSTNAME содержит FQDN или имя узла. Этот параметр также пригоден для описания всех IP-адресов узла, если у источника их несколько.

Такой источник МОЖЕТ поместить в качестве значения параметра ip список всех своих адресов или МОЖЕТ указать несколько параметров ip , содержащих разные адреса, в одном и том же элементе структурированных данных origin .

7.2.2. enterpriseId

Значение параметра enterpriseId ДОЛЖНО быть личным цифровым кодом предприятия (Network Management Private Enterprise Code), зарегистрированным в Структуре Управляющей Информации (SMI — Structure of Management Information), управляемой IANA в поддереве с префиксом iso.org.dod.internet.private.enterprise (1.3.6.1.4.1). Этот цифровой код ДОЛЖЕН быть уникальным и ДОЛЖЕН быть зарегистрирован в IANA на данное предприятие в соответствии с RFC 2578. При регистрации предприятию только предоставляются полномочия для присвоения значений субидентификаторов внутри поддерева iso.org.dod.internet.private.enterprise.<личный номер>, назначенного IANA для данного предприятия.

Параметру enterpriseId ДОЛЖНЫ присваиваться значения только из существующих в поддереве iso.org.dod.internet.private.enterprise.<личный номер>. Как правило, требуется только назначенный IANA личный номер предприятия (единственное число). Предприятие может решить использовать субидентификаторы, разместив их в поддереве ниже своего личного номера. Если субидентификаторы используются, то они ДОЛЖНЫ разделяться точками и быть представлены в виде десятичного числа, например, 32473.1.2 . Отметим, что значение 32473.1.2 — это просто пример и НЕ ДОЛЖНО использоваться в реализациях. IANA поддерживает полный список личных номеров предприятий (PEN — Private Enterprise Numbers) актуальным на текущую дату.

При указании личного номера предприятия производитель позволяет выполнить более специфичную обработку сообщения.

7.2.3. software

Параметр software уникальным образом идентифицирует программное обеспечение, которое сгенерировало сообщение. Если этот параметр используется, то также ДОЛЖЕН присутствовать параметр enterpriseId , чтобы можно было идентифицировать специфичное для производителя программное обеспечение. Параметр software — не то же самое, что и поле APP-NAME в заголовке. Этот параметр всегда ДОЛЖЕН содержать в качестве значения имя программного обеспечения, сгенерировавшего сообщение, в то время как поле APP-NAME может содержать что-нибудь другое, включая значение, указанное оператором в конфигурации.

Значением параметра software является строка. Её длина НЕ ДОЛЖНА превышать 48 символов.

7.2.4. swVersion

Параметр swVersion уникальным образом идентифицирует версию программного обеспечения, которое сгенерировало сообщение. Если этот параметр используется, то также ДОЛЖНЫ присутствовать параметры software и enterpriseId .

Значением параметра swVersion является строка. Её длина НЕ ДОЛЖНА превышать 32 символа.

7.2.5. Примеры

Ниже следует пример источника с несколькими IP-адресами:

[origin ip="192.0.2.1" ip="192.0.2.129"]

В данном примере источник указывает, что ему принадлежат два IP-адреса, один из которых — 192.0.2.1, а другой — 192.0.2.129.

7.3. meta

SD-ID meta МОЖЕТ использоваться для предоставления информации о характеристиках сообщения. Все перечисленные ниже параметры определены как НЕОБЯЗАТЕЛЬНЫЕ. Однако, если SD-ID meta используется, то хотя бы один из параметров ДОЛЖЕН присутствовать.

7.3.1. sequenceId

Параметр sequenceId отслеживает последовательность, в которой источник предоставляет сообщения транспортному механизму Syslog для передачи. Значением параметра является целое число. Это значение ДОЛЖНО быть установлено равным 1 при старте процесса Syslog и ДОЛЖНО увеличиваться на 1 для каждого следующего сообщения вплоть до максимального значения 2147483647. По достижении этого максимального значения, в следующем сообщении значение параметра sequenceId снова должно быть установлено равным 1.

7.3.2. sysUpTime

Параметр sysUpTime МОЖЕТ использоваться для включения в сообщение параметра SNMP sysUpTime , синтаксис и семантика которого описаны в RFC 3418.

Поскольку Syslog не поддерживает синтаксис SNMP «INTEGER» напрямую, то значение ДОЛЖНО быть представлено в виде десятичного целого (без десятичной точки) только с помощью цифровых символов: 0 , 1 , 2 , 3 , 4 , 5 , 6 , 7 , 8 и 9 .

Отметим, что определение sysUpTime изложено в RFC 3418, как «время (в сотых долях секунды), прошедшее после последней инициализации части системы, отвечающей за сетевое управление». Это, конечно, относится к SNMP-зависимой части системы управления, которая может отличаться от относящейся к Syslog части системы.

7.3.3. language

Параметр language МОЖЕТ использоваться источником для предоставления информации о языке, на котором написан текст сообщения в поле MSG. Если параметр указан, то значением его ДОЛЖЕН быть один из идентификаторов языка в соответствии с BCP 47 [RFC4646].

8. Вопросы безопасности

8.1. UNICODE

Настоящий документ предписывает использовать кодировку UTF-8 при заполнении поля PARAM-VALUE. Также предлагается преимущественно её использовать и при заполнении поля MSG. В связи с этим возникают некоторые вопросы безопасности, касающиеся UNICODE. Всем разработчикам и операторам рекомендуется прочитать UNICODE TR36 для ознакомления с этими вопросами, чтобы избежать изложенных в нем технических проблем при реализации ТРЕБУЮЩЕЙСЯ для приложений Syslog "кратчайшей формы" кодировки. Тем не менее, возможность путаницы визуально одинаковых символов все ещё сохраняется. Настоящий документ пытается свести к минимуму последствия визуальной подмены символов, допуская кодировку UNICODE только в тех местах, где она необходима и ожидаема. Во всех других местах ТРЕБУЕТСЯ применять US-ASCII. Кроме того, поля PARAM-VALUE и MSG не должны рассматриваться как первичный источник идентифицирующей информации, чтобы в дальнейшем снизить риски, связанные с визуальной подменой символов.

8.2. Управляющие символы

Настоящий документ не накладывает каких-либо обязательных ограничений на содержимое полей MSG и PARAM-VALUE. Таким образом, эти поля могут содержать любые управляющие символы, включая NUL (%d00 ABNF).

В некоторых языках программирования (прежде всего, C и C++) символ NUL (%d00 ABNF) традиционно имеет специальное назначение, применяясь в качестве завершающего символа строки. В большинстве реализаций этих языков предполагается, что строка, использующаяся в качестве значения переменной, заканчивается на первом же встреченном NUL. В первую очередь, это ограничение относится к библиотекам времени выполнения таких языков, но часто переносится на программы и скриптовые языки, написанные на них. Таким образом, символы NUL должны рассматриваться с большой осторожностью и использоваться надлежащим образом. Злоумышленник может намеренно вставлять символы NUL, чтобы скрыть информацию, находящуюся после них. Неправильное обращение с символами NUL также может привести к тому, что криптографические контрольные суммы, передаваемые внутри сообщения, станут недействительными.

Многие популярные текстовые редакторы также написаны на языках с этим ограничением. При записи текстовых файлов целесообразно кодировать символы NUL, записывая их с помощью экранирующих последовательностей. Если сохранить текст, содержащий символы NUL без кодирования, то файл может стать нечитаемым.

Другие управляющие символы также могут вызывать проблемы. Например, злоумышленник может намеренно вставлять символы BACKSPACE, чтобы сделать нечитаемыми какие-либо части сообщения Syslog. Аналогичные проблемы существуют почти для всех управляющих символов.

Наконец, поврежденные последовательности UTF-8 могут быть использованы злоумышленником для инъекции управляющих символов ASCII.

Настоящая спецификация позволяет приложениям Syslog переформатировать полученные управляющие символы. Среди прочего, риски безопасности, связанные с управляющими символами, были важной движущей силой, стоящей за принятием такого решения. Источникам сообщений рекомендуется принять во внимание, что использование любой другой кодировки, кроме ASCII и UTF-8, может привести к повреждению сообщения получателем, пытающимся отфильтровать управляющие символы ASCII.

8.3. Усечение сообщений

Усечение сообщений может быть использовано злоумышленником для сокрытия жизненно важной информации журнала. Сообщения, превышающие максимально допустимый для транспортного механизма получателя размер, могут быть усечены или отброшены им. Таким образом, жизненно важная информация журнала может быть потеряна.

С целью предотвращения потери информации, сообщения не должны превышать минимальный максимум длины сообщения в соответствии с требованиями Раздела 6.1. Для достижения наилучшей производительности и надежности, сообщения должны быть настолько короткими, насколько это возможно. Важная информация должна размещаться как можно ближе к началу сообщения, так как, в этом случае, менее вероятно, что она будет отброшена из-за ограничений транспортного механизма получателя.

Источник должен ограничивать размеры любых пользовательских данных в сообщениях Syslog. Если этого не делать, то злоумышленник может попытаться передавать большие объемы данных в надежде на использование потенциальной уязвимости.

8.4. Повторное воспроизведение

В протоколе Syslog не существует механизма, позволяющего обнаруживать повторное воспроизведение сообщений. Злоумышленник может перехватить и записать набор сообщений, характеризующий нормальную работу какой-либо машины. Позднее, этот злоумышленник может заблокировать доступ атакуемой машины к сети и от ее имени начать воспроизводить ранее записанные сообщения Syslog, передавая их ретранслятору или коллектору. Даже при наличии поля TIMESTAMP в области HEADER, злоумышленник может просто изменять ранее записанные пакеты, чтобы отразить текущее время при воспроизведении. Администраторы могут не найти ничего необычного в полученных сообщениях и будут обмануты, посчитав, что данная машина функционирует нормально.

Криптографическое подписывание сообщений позволяет выявить несанкционированное изменение полей, в том числе и TIMESTAMP, и обнаружить атаку «повторного воспроизведения».

8.5. Надежная доставка

Поскольку данный документ не описывает механизмы, обеспечивающие доставку сообщений, а транспортные протоколы могут быть ненадежными (например, UDP), то некоторые сообщения могут быть потеряны. Они могут быть отброшены сетевыми устройствами из-за перегруженности каналов связи или злонамеренно перехвачены и уничтожены. Последствия потери одного или нескольких сообщений Syslog непредсказуемы. Если утрачены просто сообщения об изменении состояния, то их неполучение может быть не замечено или будет вызывать раздражение системных операторов. С другой стороны, если утрачены более важные сообщения, то администраторы, возможно, не узнают о возникновении и развитии потенциально опасной проблемы. Также сообщения могут быть перехвачены и уничтожены злоумышленником для сокрытия несанкционированных действий.

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

Надежная доставка не всегда может быть желательна, поскольку подразумевает, что отправитель (источник или ретранслятор) должен блокироваться, когда получатель (ретранслятор или коллектор) больше не в состоянии принимать сообщения. В некоторых операционных системах, а именно Unix/Linux, источник сообщений и ретранслятор работают внутри высокоприоритетного системного процесса (Syslogd). Если этот процесс заблокировать, то дело доходит блокирования системы целиком. То же самое происходит, когда возникает взаимная блокировка между Syslogd и, например, сервером DNS.

Для предотвращения этих проблем надежная доставка может быть организована таким образом, чтобы намеренно отбрасывать сообщения, которые могли бы заблокировать приложение Syslog в противном случае. Преимуществом надежной доставки в данном случае является то, что отправитель (источник или ретранслятор) сознательно отбрасывает сообщение и имеет возможность уведомить об этом факте получателя (ретранслятор или коллектор). Таким образом, получатель (ретранслятор или коллектор) станет обладать информацией о том, что что-то потерялось. В случае ненадежной доставки, сообщение будет просто потеряно без какого-либо оповещения о произошедшем.

8.6. Управление нагрузкой

Поскольку Syslog может генерировать неограниченные объемы данных, то передача их по UDP, как правило, вызывает проблемы, так как в UDP отсутствуют механизмы управления нагрузкой. Эти механизмы, призванные реагировать на перегруженность каналов ограничением трафика и созданием справедливого распределения емкости канала между потоками, использующими одни и те же пути, имеют жизненно важное значение для стабильной работы Интернет [RFC2914]. Именно поэтому для Syslog ТРЕБУЕТСЯ реализовывать транспорт TLS, который и РЕКОМЕНДУЕТСЯ для общего пользования.

Транспорт UDP для Sylog МОЖЕТ быть использован в качестве альтернативы транспорту TLS, только если оборудованием, управляющим сетями, для трафика UDP Syslog явно предусмотрен отдельный маршрут через инженерные механизмы управления трафиком, такие как ограничение скорости или резервирование емкости канала. Во всех других случаях ДОЛЖЕН быть использован транспорт TLS.

В любой реализации может возникнуть ситуация, в которой отправитель (источник или ретранслятор) должен заблокировать отправку сообщений, например, как общий случай, при переполнении внутренних очередей. Это может произойти из-за ограничений скорости или медленной работы приложения Syslog. В любом случае, настоятельно РЕКОМЕНДУЕТСЯ не терять сообщения, а организовать их временное хранение до тех пор, пока они не смогут быть переданы. Однако, если потеря сообщений неизбежна, то РЕКОМЕНДУЕТСЯ сначала удалять сообщения низкой важности, а только потом — высокой. Сообщения с меньшим числовым значением уровня важности имеют большую практическую ценность, чем с большим. В такой ситуации, сообщения, которые приходится терять, ДОЛЖНЫ быть просто отброшены. Приложение Syslog может уведомить получателя (коллектор или ретранслятор) о факте потери сообщений.

8.7. Целостность сообщений

Помимо потери, сообщения Syslog могут быть повреждены в процессе доставки или их может злонамеренно изменить злоумышленник. В любом случае, исходное содержимое сообщения не будет доставлено получателю. Дополнительно, если злоумышленник расположится между отправителем и получателем сообщений Syslog, то он может перехватывать и изменять сообщения, чтобы скрыть несанкционированные действия.

8.8. Несанкционированный просмотр сообщений

Хотя существуют нестрогие соглашения относительно формата поля MSG, но большинство сообщений Syslog создается в удобочитаемой форме, исходя из того, что администраторы должны быть способны прочитать и понять текст сообщения. У протокола Syslog не существует механизмов, обеспечивающих конфиденциальность сообщений в пути. В большинстве случаев, передача сообщений открытым текстом является преимуществом для операционного персонала, если они отлавливают пакеты прямо из канала связи. Операционный персонал может прочитать сообщения и связать их с прочими событиями, замеченными в других пакетах, проходящих по каналу связи, чтобы отыскать и исправить проблемы. К сожалению, злоумышленник также может наблюдать удобочитаемое содержание сообщений Syslog. Он может использовать полученную из этих сообщений информацию для того, чтобы поставить под угрозу машину или нанести иной ущерб.

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

8.9. Ошибки конфигурирования

В виду отсутствия управляющей информации о сообщениях или конфигурациях, ответственность за то, что сообщения действительно будут направлены предполагаемому получателю, полностью ложится на администратора сети. Однако, отмечались случаи, когда приложения Syslog были непреднамеренно сконфигурированы так, чтобы отправлять сообщения неправильному получателю. Во многих случаях такой получатель может не быть сконфигурирован для получения сообщений Syslog и, вероятно, отбросит их. В некоторых других случаях, получение неожидаемых сообщений Syslog, как известно, вызывало проблемы у получателя. Если сообщения не попадают к предполагаемому получателя, то они не могут быть им просмотрены или обработаны.

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

8.10. Зацикливание пересылок

Как показано на рисунке 2, машины могут быть настроены так, что сообщения Syslog пройдут через один или несколько промежуточных ретрансляторов прежде, чем достигнут коллектора. Известны случаи неправильной конфигурации соседних ретрансляторов, когда им предписывалось пересылать сообщения с определенными значениями уровня важности друг другу. Когда любая из этих машин получала или генерировала сообщение данного типа, то пересылала его соседней. Та, в свою очередь, отправляла это сообщение обратно. Этот бесконечный цикл действительно вызвал перегрузку участка сети и отказ от обслуживания на этих двух устройствах. Администраторы сети должны заботиться о том, чтобы конфигурация не позволяла образовываться таким «мертвым петлям».

8.11. Оценка нагрузки

Администраторы сети должны найти время для оценки ресурсов получателей сообщений Syslog. Злоумышленник может выполнить атаку «отказ от обслуживания», переполнив диск коллектора ложными сообщениями. Помещение записей в циклические файлы с последующим удалением наиболее старых записей может облегчить ситуацию, но у такого решения существует опасность того, что администратор не сможет пересмотреть удаленные записи в будущем. Сетевой интерфейс получателя или коллектора должен быть способен получать все сообщения, отправленные ему.

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

Для того, чтобы уменьшить влияние этой проблемы, рекомендуется использовать транспорт с гарантированной доставкой.

8.12. Отказ от обслуживания

Злоумышленник может нарушить работу получателя, отправляя ему больше сообщений, чем получатель (сам или его инфраструктура) может обработать. Разработчикам РЕКОМЕНДУЕТСЯ минимизировать такие угрозы, дополнительно ограничив прием сообщений множеством известных IP-адресов отправителей.

9. Роль IANA

9.1. Реестр значений поля VERSION (версия)

IANA создала реестр, озаглавленный «Версии Syslog», содержащий допустимые значения поля VERSION, описание которого находится в разделе 6.2.2. Номер версии ДОЛЖЕН увеличиваться на 1 для каждой новой спецификации протокола Syslog, изменяющей любую часть поля HEADER. Изменения могут включать как добавление и удаление полей, так и изменение синтаксиса или семантики полей.

Номера версий должны быть зарегистрированы с помощью Процедур Стандартизации, изложенных в RFC 5226. Допустимые значения поля VERSION (зарегистрированные номера версий) приведены в следующей таблице:

Значение VERSION Формат
1 Изложен в [RFC5424]
Таблица 3. Номера версий, зарегистрированные в IANA.

9.2. Реестр значений поля SD-ID (ид-данных)

IANA создала реестр, озаглавленный «Идентификаторы структурированных данных Syslog», содержащий допустимые значения полей SD-ID и связанных с ними полей SD_PARAM, описание которых находятся в разделе 7.

Новые SD-ID и SD-PARAM должны быть зарегистрированы с помощью Процедур Пересмотра IETF, изложенных в RFC 5226.

Синтаксис и семантика однажды определенных SD-ID и SD-PARAM НЕ ДОЛЖНЫ изменяться. Если требуется изменение существующего объекта, то ДОЛЖЕН быть создан новый SD-ID или SD-PARAM, а старый оставлен без изменений.

Однако, здесь сделана оговорка для локально расширяемых имен. IANA не будет регистрировать и управлять именами, содержащими символ «коммерческое at» (@ ABNF %d64).

Зарегистрированные в IANA SD-ID и соответствующие им PARAM-NAME приведены в таблице 4:

SD-ID PARAM-NAME
timeQuality Необязательный
tzKnown Необязательный
isSynced Необязательный
syncAccuracy Необязательный
origin Необязательный
ip Необязательный
enterpriseId Необязательный
software Необязательный
swVersion Необязательный
meta Необязательный
sequenceId Необязательный
sysUpTime Необязательный
language Необязательный
Таблица 4. Идентификаторы структурированных данных Syslog.

10. Рабочая группа

С рабочей группой можно связаться с помощью списка почтовой рассылки:

  • [email protected]

Руководителями рабочей группы являются:

  • Chris Lonvick, Cisco Systems
  • David Harrington, Huawei Technologies USA

11. Благодарности

Авторы благодарят Chris Lonvick, Jon Callas, Andrew Ross, Albert Mietus, Anton Okmianski, Tina Bird, Devin Kowatch, David Harrington, Sharon Chisholm, Richard Graveman, Tom Petch, Dado Colussi, Clement Mathieu, Didier Dalmasso и других людей, которые комментировали различные версии данного документа.

12. Список литературы

12.1. Нормативные документы

[ANSI.X3-4.1968] American National Standards Institute, «USA Standard Code for Information Interchange», ANSI X3.4, 1968
[RFC 1034] Mockapetris, P., «Domain Names — Concepts and Facilities», STD 13, RFC 1034, Ноябрь 1987.
[RFC 1035] Mockapetris, P., «Domain names — Implementation and Specification», STD 13, RFC 1035, Ноябрь 1987.
[RFC 2119] Bradner, S., «Ключевые слова для обозначения уровня требований в RFC», RFC 2119, BCP 14, Март 1997.
[RFC 2578] McCloghrie, K., Ed., Perkins, D., Ed., and J. Schoenwaelder, Ed., «Structure of Management Information Version 2 (SMIv2)», STD 58, RFC 2578, Апрель 1999.
[RFC 2914] Floyd, S., «Congestion Control Principles», BCP 41, RFC 2914, Сентябрь 2000.
[RFC 3339] Klyne, G., Ed. и C. Newman, «Date and Time on the Internet: Timestamps», RFC 3339, Июль 2002.
[RFC 3418] Presuhn, R., «Management Information Base (MIB) for the Simple Network Management Protocol (SNMP)», STD 62, RFC 3418, Декабрь 2002.
[RFC 3629] Yergeau, F., «UTF-8, a transformation format of ISO 10646», STD 63, RFC 3629, Ноябрь 2003.
[RFC 4291] Hinden, R. и S. Deering, «Архитектура шестой версии протокола межсетевого обмена в Internet (IPv6-адресация)», RFC 4291, Февраль 2006.
[RFC 4646] Phillips, A. и M. Davis, «Tags for Identifying Languages», BCP 47, RFC 4646, Сентябрь 2006.
[RFC 5226] Narten, T. и H. Alvestrand, «Guidelines for Writing an IANA Considerations Section in RFCs», BCP 26, RFC 5226, Май 2008.
[RFC 5234] Crocker, D. и P. Overell, «Расширенная спецификация синтаксиса Бэкуса-Наура (ABNF)», RFC 5234, STD 68, Январь 2008.
[RFC 5425] Fuyou, M., Yuzhi, M., and J. Salowey, «TLS Transport Mapping for Syslog», RFC 5425, Март 2009.
[RFC 5426] Okmianski, A., «Передача сообщений Syslog через UDP», RFC 5426, Март 2009.
[UNICODE-TR36] Davis, M. и M. Suignard, «UNICODE Security Considerations», Июль 2005.

12.2. Дополнительная литература

[RFC 3164] Lonvick, C., «The BSD Syslog Protocol», RFC 3164, Август 2001.

13. Приложение А. Руководство для реализации протокола

Информация в этом разделе подана в виде рекомендаций разработчикам. Авторы полагают, что они полезны, хотя и не являются нормативными. Реализациям НЕ ТРЕБУЕТСЯ жестко следовать им, чтобы соответствовать данной спецификации.

13.1. Приложение А.1. Совместимость с BSD Syslog

Хотя BSD Syslog широко используется в настоящее время, его формат никогда не был формально стандартизирован. В RFC 3164 описываются распространённые существующие форматы. Этот информационный RFC практически показал как много существует различных реализаций. Исследование, проведенное во время создания этого документа, показало, что есть очень мало общего между различными реализациями Syslog на различных платформах. Единственная вещь, в которой все они согласуются, состоит в том, что сообщения начинаются с последовательности < PRIVAL > . Всё остальное содержимое сообщений Syslog не отформатировано непротиворечивым способом. И RFC 3164, соответственно, не описывает определенных элементов в сообщении Syslog. Это подтверждается тем, что любой пакет, предназначенный для порта UDP Syslog, должен быть обработан как сообщение Syslog, независимо от того, каковы его формат или содержимое.

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

Большинство существующих реализаций поддерживает UDP в качестве транспортного протокола для Syslog. Данная спецификация также поддерживает транспорт UDP, но не рекомендует его. Рекомендуется развертывание требуемой поддержки TLS. Также могут использоваться дополнительные транспортные протоколы.

RFC 3164 описывает поведение ретрансляторов сообщений. Настоящий документ не определяет поведение ретрансляторов. Это могло бы быть сделано в отдельном документе.

Поле TIMESTAMP, описанное в RFC 3164, предполагает меньшую точность, чем метка времени, определенная в настоящем документе. Также в этом поле отсутствуют год и информация о часовом поясе. Если сформированное согласно настоящему документу сообщение должно быть преобразовано в формат RFC 3164, то предлагается использовать местное поясное время источника сообщения, а информацию о часовом поясе и годе отбрасывать. Если полученное в формате RFC 3164 сообщение должно быть преобразовано так, чтобы соответствовать настоящей спецификации, то при добавлении информации о годе и часовом поясе МОЖЕТ использоваться текущий год и часовой пояс ретранслятора или коллектора.

Поле HOSTNAME в RFC 3164 менее представительно, но такой формат все ещё поддерживается в настоящей спецификации, как одно из альтернативных представлений имени узла.

Часть сообщения, обозначаемая MSG, согласно RFC 3164, состоит из полей TAG и CONTENT. В настоящей редакции, MSG — это то, что называлось CONTENT в RFC 3164. Теперь TAG — это часть заголовка и если раньше он был простым полем, то теперь TAG разделен на поля APP-NAME, PROCID и MSGID. Это не полностью напоминает использование TAG, но обеспечивает ту же самую функциональность для большинства случаев.

Поле STRUCTURED-DATA не было описано в RFC 3164. Если сформированное согласно настоящему документу сообщение содержит STRUCTURED-DATA и должно быть преобразовано в формат RFC 3164, то STRUCTURED-DATA просто становятся частью поля CONTENT RFC 3164, содержащим данные в свободной форме.

В целом этот документ пытается обеспечить легко анализируемый заголовок с четким разделением полей, тогда как традиционный BSD Syslog страдает от некоторых исторически разработанных, трудно анализируемых правил разделения полей.

13.2. Приложение А.2. Длина сообщения

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

Причина того, что транспортным механизмам получателей сообщений Syslog требуется поддерживать прием сообщений длиной только до 480 октетов включительно, кроется ещё в том, что им необходимо справляться с трудными проблемами доставки пакетов в поврежденных сетях. Для доставки сообщений Syslog может применяться транспортный механизм, использующий UDP, который как раз ограничивает длину сообщения 480 октетами во избежание фрагментации пакетов и увеличения издержек сеанса связи. В низкокачественных сетях вероятность успешной доставки сообщения, состоящего из одного единственного пакета, существенно выше, чем вероятность успешной доставки сообщения, состоящего из двух и более пакетов. Поэтому использование сообщений большого размера может не позволить доставить оператору некоторую критическую информацию о проблеме, тогда как маленькие сообщения позволили бы оператору получить ту же самую информацию. Рекомендуется ограничивать 480 октетами длину сообщений об ошибках и неполадках. Чтобы еще больше заострить на этом внимание, отметим, что некоторые реализации UDP не поддерживают сообщения с размерами больше, чем 480 октетов. Но такое поведение встречается крайне редко и может уже не быть проблемой.

Существуют другие варианты, когда сообщения Syslog используются для передачи объёмной информации, например, контрольных данных. Поскольку не установлен верхний предел размера сообщений, то приложения Syslog могут быть реализованы для обработки сообщений любой необходимой длины, что всё ещё соответствует требованиям настоящего документа. В таких случаях, обязанность оператора состоит в том, чтобы удостовериться, что все компоненты инфраструктуры Syslog поддерживают требуемые размеры сообщений. Транспортные механизмы могут накладывать определенные ограничения на размеры сообщения, которые должны соблюдаться для обеспечения совместимости.

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

Нужно отметить, что в IPv6 размер полезной нагрузки для минимально необходимого MTU приблизительно в 2.5 раза больше 480. Реализации, предназначенные для использования только в среде IPv6, могли бы таким образом, принять его в качестве большего минимального размера.

13.3. Приложение А.3. Приоритеты сообщений

Данный раздел содержит инструкции по использованию значения Важности, как это было обрисовано в общих чертах в Разделе 6.2.1.

Во всех реализациях следует пытаться присвоить наиболее подходящее значение Важности своим сообщениям. Особенно важно то, что сообщениям, разработанным для отладки или тестирования программного обеспечения, должно быть присвоено значение, равное 7. Значение, равное 0, должно быть зарезервировано для сообщений очень высокой значимости, таких как серьезные отказы оборудования или угрожающий сбой питания. Реализации могут использовать значения Важности 0 и 7 и для других целей, если это сконфигурировано администратором.

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

13.4. Приложение А.4. Точность TIME-SECFRAC

Отметка времени в поле TIMESTAMP, описанном в Разделе 6.2.3, может указываться с точностью до долей секунды, что создает опасность возникновения очень общей ошибки кодирования, когда из значения долей секунды отбрасываются лидирующие нули. Например, значение 2003-10-11T22:13:14.003 может быть ошибочно записано как 2003-10-11T22:13:14.3 и тогда отметка времени будет указывать на 300 миллисекунд вместо имевшихся в виду 3 миллисекунд.

13.5. Приложение А.5. Соглашения о наименованиях

Имена используются в различных местах настоящего документа, например, в качестве значений полей SD-ID и PARAM-NAME. Для их написания в данном документе последовательно применяется «горбатый стиль с нижнего регистра» (lower camel case). При этом каждое имя начинается со строчной буквы, а каждое новое встроенное слово имени — с прописной буквы без дефиса или другого разделителя, например, timeQuality .

Хотя реализации вольны использовать любые другие правила написания экспериментальных имен, все же предлагается придерживаться в таких случаях соглашения, изложенного выше.

13.6. Приложение А.6. Приложения Syslog, не имеющие представления о времени

В разделе 6.2.3 отмечено, что источникам сообщений, не имеющим представления о времени, позволяется использовать значение NILVALUE в качестве отметки времени. Это допущение сделано только для особых случаев, когда приложение Syslog вообще не знает о времени. Можно спорить о том удастся ли обнаружить такое приложение Syslog в сегодняшней инфраструктуре ИТ, но обсуждение показало, что такие реализации могут существовать практически и инструкция, установленная для этого случая, должна быть таковой.

Однако, реализация ДОЛЖНА создавать допустимые TIMESTAMP, если базовая операционная система, система программирования и аппаратные средства поддерживают функцию часов. Надлежащие TIMESTAMP должны быть установлены, даже если есть трудности с получением системного времени. Значение NILVALUE должно использоваться только тогда, когда действительно невозможно получить информацию о времени, и не может использоваться для оправдания лени в разработке.

13.7. Приложение А.7. Замечания о SD-ID timeQuality

Рекомендуется сделать значение 0 значением по умолчанию для параметра tzKnown (Раздел 7.1.1). Оно должно быть изменено на 1 только после того, как администратор специально укажет часовой пояс в конфигурации. Значение 1 может использоваться в качестве значения по умолчанию, если базовая операционная система предоставляет точную информацию о часовом поясе. Администратору, всё таки, рекомендуется проверить правильность информации о часовом поясе.

Важно не создавать ложное впечатление о точности SD-ID timeQuality (Раздел 7.1). Источник сообщения должен указывать значение точности, если только он действительно знает, что она находится в данных границах. Обычно предполагается, что источник сообщения получает эту информацию из конфигурации, созданной оператором. По умолчанию, точность не должна указываться.

13.8. Приложение А.8. Кодировка UTF-8 и метка порядка байтов (BOM)

В настоящем документе зафиксировано, что значение полей SD-PARAM всегда должно быть представлено в кодировке UTF-8. Кроме того, для достижения соответствия данной спецификации, устройствам не рекомендуется использовать другие кодировки, включая ASCIIPRINT, для сообщений в области MSG. Однако, здесь необходимо сделать два замечания. Во-первых, приложение Syslog, соответствующее этой спецификации, может быть не в состоянии установить, что информация, полученная от источника, закодирована в UTF-8. Если приложение Syslog не может уверенно это определить, то оно может принять решение не включать BOM в MSG. Если же у приложения Syslog есть надёжный индикатор, что содержимое сообщения закодировано в UTF-8, то оно должно включить BOM в MSG. Во-вторых, ретранслятор может передавать сообщения от устройства, которое не соответствует этой спецификации. В этом случае устройство, скорее всего, не будет включать BOM в MSG, если только оно не удостоверилось, что полученное сообщение было закодировано в UTF-8.

2007 - 2022 © Русские переводы RFC, IETF, ISOC.