Кратко

  • Необязательный timeQuality передаёт собственную оценку отправителя: известен ли часовой пояс, считает ли он часы синхронизированными и какого отклонения ожидает.
  • syncAccuracy — предполагаемая максимальная ошибка между интервалами синхронизации, а не внешняя проверка; её смысл зависит от операционной настройки источника времени.

Временная шкала начинается с утверждений источников

Когда несколько журналов сводят в единый ряд, аналитик видит события в порядке их временных меток. Однако одинаковый формат ещё не означает одинаковую надёжность. Один сервер мог знать свой часовой пояс и поддерживать синхронизацию; другой мог сохранить корректно оформленную дату после потери источника времени. RFC 5424 позволяет отправителю приложить к сообщению timeQuality — описание того, как сам источник оценивает системное время.

В § 6.2.3 спецификация задаёт TIMESTAMP как ограниченную форму RFC 3339 и рекомендует доли секунды, когда точность и производительность часов это допускают. § 7.1 добавляет необязательные структурированные данные о представлении источника. Эти сведения приходят от той же системы, которая поставила метку времени. Коллектор не измеряет её часы, читая параметр.

Именно поэтому видимую точность следует отделять от основания для доверия: дополнительные цифры не подтверждают состояние синхронизации.

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

Поля отвечают на разные вопросы

tzKnown показывает, знает ли отправитель используемую информацию о часовом поясе. Это не зависит от того, написано ли время в UTC: приложение A.7 поясняет, что часовой пояс может быть известен и при записи с суффиксом Z. И обратное тоже верно — UTC само по себе не доказывает, что локальная настройка понятна и верна. RFC рекомендует осторожное значение по умолчанию и предлагает полагаться на настройку или проверку администратора.

isSynced выражает, считает ли источник свои часы синхронизированными с надёжным внешним источником, например NTP. Получатель сообщения не выполняет проверку этого сервиса. Значение отражает решение отправителя, а состояние службы времени должно подтверждаться отдельным мониторингом.

syncAccuracy — целое число микросекунд, обозначающее максимально возможное, по оценке источника, отклонение между периодами синхронизации. Его нельзя указывать при isSynced="0". В примере RFC 5424 используется 60 000 000 микросекунд — одна минута: метка 09:00 трактуется в пределах 08:59–09:01. Это иллюстрация заявленной границы, а не результат независимого измерительного стенда.

Спецификация рекомендует отправлять эту величину, только если источник действительно знает надёжность своей временной службы. Приложение отмечает, что такое знание обычно обеспечивается конфигурацией оператора, и предупреждает против ложного впечатления точности. Если isSynced="1" есть, а syncAccuracy отсутствует, коллектор или ретранслятор может считать указанное время достаточно точным. Такое правило объясняет допустимую интерпретацию сообщения, но не удостоверяет фактическое состояние NTP.

Метаданные нужно сохранить на всём пути

Реестр параметров Syslog в IANA относит все четыре элемента к необязательным. Поэтому система сбора должна принимать сообщения и с ними, и без них. Отсутствие timeQuality не доказывает ошибку часов; оно просто оставляет получателю меньше явных сведений о происхождении времени.

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

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

Декларация и проверка остаются разными слоями

timeQuality — свидетельство о том, что источник сообщил о своём времени. Оно помогает сохранить ограничения при разборе последовательности событий. Оно не подтверждает подлинность события, не устанавливает причинный порядок между машинами и не превращает заявление отправителя в независимое наблюдение.

Заметка Heng Lu о приоритете работающего кода служит здесь только редакционной рамкой: написанная метка не заменяет проверку того, что выполняет развёрнутая система. RFC задаёт форму сообщения, а практическая основа остаётся в настройках и мониторинге источника. Коллектор может сохранить эту границу доказательств, но не может восполнить отсутствующее наблюдение задним числом.

Источники