Синхронизация часов сервера: источники chrony и проверка отклонений

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

В этой статье на примере chrony в Debian 12 выстроен порядок действий: проверить источники, разобраться в отклонениях, настроить проверку готовности и подтвердить восстановление. После оплаты выделенного сервера AmdMetal учетные данные можно посмотреть в панели управления и подключиться по SSH; если адресов IPv4 несколько, используйте первый. Описанные ниже действия не меняют сетевые адреса и не требуют открывать порты управления для публичного доступа.

1. Зафиксируйте исходное состояние: отображение времени и его коррекция — не одно и то же

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

date --iso-8601=seconds
date -u --iso-8601=seconds
timedatectl status
uname -r
systemctl is-active chrony systemd-timesyncd

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

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

sudo apt-get update
sudo apt-get install chrony
systemctl status chrony --no-pager

Скачки системного времени могут повлиять на работающие базы данных, службы аутентификации и планировщики задач. Пока поведение приложений не оценено, не выполняйте date -s и chronyc makestep и не пытайтесь «починить время» многократными перезапусками службы синхронизации.

2. Проверьте источники: доступность не означает достоверность

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

sudo grep -R -E \
'^[[:space:]]*(server|pool|peer|sourcedir|confdir|include|makestep|local|offline)' \
/etc/chrony
chronyc activity
chronyc sources -v
chronyc sourcestats -v

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

В выводе sources -v символ * обозначает выбранный источник синхронизации, + — источник, участвующий в объединении данных, а ? — источник, который сейчас нельзя использовать для выбора. Причиной могут быть недоступность, недостаточное число измерений и другие обстоятельства. Reach — это история доступности в восьмеричном виде. Значение 377 означает, что на последние восемь опросов получены ответы, но не подтверждает точность времени.

Порядок диагностики проблем с источниками

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

3. Разберитесь в показателях отклонения: одного поля недостаточно

chronyc tracking
journalctl -u chrony -b --no-pager -n 100

Значение Reference time должно регулярно обновляться. Если в поле Leap status указано Not synchronised, проверка не может считаться пройденной. System time — это оценка оставшейся коррекции, рассчитанная chrony. Близкое к нулю значение не является независимым подтверждением малой ошибки относительно истинного UTC.

Поля Last offset и RMS offset характеризуют измерения и их статистику, а Root delay и Root dispersion дают представление о пути до опорных часов и неопределенности. Эти показатели нужно рассматривать вместе с состоянием источников, а не использовать одно число с дробной частью как доказательство исправности.

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

4. Настройте проверку синхронизации с ограниченным ожиданием

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

chronyc waitsync 12 0.05 0 5

Команда выполняет не более двенадцати проверок с интервалом пять секунд. Она требует перехода в синхронизированное состояние и уменьшения оставшейся коррекции до значения менее 0.05 секунды. Третий параметр, равный нулю, означает отсутствие дополнительного ограничения на skew. Успешное завершение подтверждает выполнение этих условий, но не гарантирует ошибку относительно истинного UTC менее пятидесяти миллисекунд.

Автоматизация должна проверять код завершения, а не скрывать сообщение об ошибке:

if chronyc waitsync 12 0.05 0 5; then
    printf '%s\n' 'Clock gate passed'
else
    printf '%s\n' 'Clock gate failed' >&2
    exit 1
fi

Неудачная проверка должна блокировать соответствующий этап запуска и уведомлять эксплуатационную команду, а не автоматически исправлять время скачком. network-online.target относится только к готовности сети и также не подтверждает завершение синхронизации часов.

Проверьте сценарий отказа

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

5. Проверьте результат восстановления и сохраните объяснимые свидетельства

Если источники были вручную переведены в состояние offline, выполняйте chronyc online только после подтверждения восстановления сети. Если нужны дополнительные измерения, можно один раз выполнить chronyc burst 4/4 для настроенных источников, а затем снова проверить выбор источника и вывод tracking. Не запускайте команду в цикле, создавая бессмысленные запросы.

При проверке makestep особенно внимательно отнеситесь к настройкам вида makestep 1.0 3: они разрешают скачком корректировать отклонения выше порога в течение первых нескольких обновлений часов после запуска. Перезапуск службы может снова включить этот режим, поэтому «просто перезапустить» — не безрисковое действие. Если большой скачок времени действительно необходим, сначала изолируйте затрагиваемые приложения и подготовьте план восстановления.

Итоговая проверка должна включать следующее:

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

Для измерения длительности и управления тайм-аутами предпочтительны монотонные часы, а для временных меток приложения — системное календарное время. Проверку способа измерения времени в приложении следует отделять от проверки синхронизации хоста. Это позволит избежать отрицательной длительности после коррекции часов и сохранить возможность объяснить записи о последующих сбоях.

Часто задаваемые вопросы