Точная синхронизация времени: chrony на VDS, NTP‑сервер и мониторинг дрейфа

Если время на сервере «поплыло», вы очень быстро это заметите по странным логам, ошибкам TLS, развалившейся репликации, нестабильному расписанию cron и проблемам с подписью писем. На виртуальных серверах смещения часов встречаются чаще из‑за особенностей гипервизора и нагрузки. Хорошая новость: chrony умеет быстро сходиться, аккуратно сглаживать дрейф и надёжно обслуживать клиентов по NTP. Дальше показано, как настроить это на VDS; а если вы контролируете срок действия сертификатов, пригодятся и наши SSL‑сертификаты.

Почему chrony на VDS

Исторически для NTP использовали ntpd, позже появился systemd-timesyncd как лёгкий клиент. Но для виртуальных машин chrony чаще всего выигрывает:

• Быстрая сходимость после старта и резких скачков времени.
• Устойчивость к нестабильным сетям, потере пакетов и изменчивым задержкам.
• Точная оценка частоты кристалла (drift) и аккуратная коррекция.
• Возможность работать NTP‑сервером для ваших узлов.

Важный момент: держите активным только один механизм синхронизации. Если переходите на chrony, отключите systemd-timesyncd и любые «агенты времени» от гипервизора, чтобы избежать конфликтов.

Облачный VDS-сервер в России

Аренда виртуальных серверов с моментальным развертыванием инфраструктуры от 195₽ / мес

Подробнее

Подготовка системы

Отключаем другие демоны времени

sudo timedatectl set-ntp false
sudo systemctl stop systemd-timesyncd
sudo systemctl disable systemd-timesyncd

На некоторых образах могут быть установлены пакеты ntp или openntpd — удалите или остановите их.

Установка и запуск chrony

# Debian/Ubuntu
sudo apt update
sudo apt install -y chrony

# RHEL/CentOS/AlmaLinux/Rocky
sudo dnf install -y chrony

# Fedora
sudo dnf install -y chrony

# Arch
sudo pacman -S --noconfirm chrony

# Запуск и автозагрузка
sudo systemctl enable --now chronyd

# Базовая проверка
chronyc tracking
chronyc sources -v

Если видите Stratum меньше 16, Leap status: Normal и смещение в пределах миллисекунд/десятков миллисекунд — всё хорошо. На «холодном» старте chrony быстро догонит референсы.

Базовая конфигурация chrony

Файл конфигурации может называться /etc/chrony/chrony.conf (Debian‑семейство) или /etc/chrony.conf (RHEL‑семейство). Определитесь с публичными или провайдерскими источниками NTP и настройте минимальный набор опций.

# /etc/chrony/chrony.conf (или /etc/chrony.conf)

# Основные публичные источники (пример). Используйте близкие к вам пулы/серверы.
pool pool.ntp.org iburst

# Файл дрейфа — оценка частоты локальных часов
 driftfile /var/lib/chrony/drift

# Быстрое «шагание» в начале, затем только «плавная» коррекция
 makestep 1.0 3

# Разрешить ядру записывать скорректированное время в RTC (на ВМ без батареи не критично)
 rtcsync

# Логи и каталог
 logdir /var/log/chrony
 log tracking measurements statistics

# Опционально: получать сведения о високосной секунде из tzdata
 # leapsectz right/UTC

# Интерфейс управления
 cmdport 0

Пояснения:

• iburst ускоряет первичную синхронизацию.
• makestep 1.0 3 разрешает сделать «скачок» до 1 секунды до трёх раз при старте — полезно для VDS после долгого простоя. Далее chrony будет «подруливать» плавно, чтобы процессы не сходили с ума от изменения времени назад.
• cmdport 0 отключает удалённый UDP‑порт управления (323/udp), управление идёт через локальный сокет.

После правок перезапустите службу:

sudo systemctl restart chronyd
chronyc activity

Собственный NTP‑сервер на базе chrony

Частый кейс — один узел в сети (или в приватной подсети VDS) синхронизируется с внешними источниками и раздаёт время другим серверам/контейнерам. Делается это двумя настройками: разрешить клиентам и открыть порт 123/udp на фаерволе.

Разрешаем клиентам и настраиваем политики

# Разрешить NTP‑клиентам из вашей сети (пример — /24)
allow 10.0.0.0/24

# Опционально: настроить bind на конкретный интерфейс
# bindaddress 10.0.0.10

# В офлайн‑сценариях (когда внешний NTP недоступен) можно выставить локальный страйтум,
# чтобы не оставлять клиентов без времени. Используйте с осторожностью.
# local stratum 10 orphan

Проверьте, что сервис слушает 123/udp:

sudo ss -lunp | grep :123

Откройте порт в фаерволе только для нужных сетей.

# nftables (пример)
sudo nft add rule inet filter input udp dport 123 ip saddr 10.0.0.0/24 accept

# firewalld
sudo firewall-cmd --add-rich-rule='rule family=ipv4 source address=10.0.0.0/24 port protocol=udp port=123 accept' --permanent
sudo firewall-cmd --reload

# ufw
sudo ufw allow from 10.0.0.0/24 to any port 123 proto udp

Сторона клиента (на узлах вашей сети) — достаточно прописать ваш сервер в их chrony.conf или timesyncd.conf, например:

# На клиентах chrony
server 10.0.0.10 iburst

Проверка клиентов на сервере:

chronyc clients

Совет по безопасности: не превращайте узел в открытый публичный NTP без необходимости. Без фильтрации источника запросов вы рискуете стать участником DDoS через NTP‑амплификацию.

Мониторинг точности и дрейфа

Вам важно не только «включить», но и «держать в норме». Следующие команды дают картину статуса.

Диагностика в одну команду

chronyc tracking

Ключевые поля:

• Reference ID/Name — текущий опорный сервер.
• Stratum — уровень иерархии (0 — эталон, 1 — рядом с ним, 16 — «несинхронизирован»).
• System time — смещение системного времени относительно опорного (положительное/отрицательное).
• Root delay/dispersion — суммарная задержка и разброс до корня.
• Frequency — оценка дрейфа частоты локальных часов (ppm).

Качество источников

chronyc sources -v
chronyc sourcestats -v

Смотрите метки ^* (выбранный), ^+ (подходящие кандидаты), ^- (отброшенные), ^? (не достигнут). Большие Offset/RMS offset и нестабильная Skew — повод заменить источник.

Пороговые значения и тревоги

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

• Величина смещения (из chronyc tracking): если > 50–100 ms — уже заметно для TLS/лога; > 500 ms — критично.
• Stratum и Leap status: при Stratum=16 или Leap: Not synchronized — авария.
• Частота (ppm): резкий скачок — индикатор проблем с хостом/гипервизором.

Есть два удобных пути мониторинга: через системные метрики ядра и через экспорт данных chrony.

Метрики ядра (timex) через node_exporter

Linux отдаёт состояние дисциплины часов через adjtimex, и многие агенты мониторинга подхватывают эти показатели. В node_exporter это метрики вида node_timex_* — например, node_timex_estimated_error_seconds, node_timex_maxerror_seconds, node_timex_offset_seconds, node_timex_constant, node_timex_status. Если агент включён и собирает timex, вы уже видите смещения в секундах и статус синхронизации.

Экспорт статуса chrony скриптом через textfile collector

Если хотите точно то, что показывает chrony, можно собрать из вывода chronyc простым скриптом и отдать через textfile‑коллектор:

# /usr/local/bin/chrony_export_metrics.sh
#!/usr/bin/env bash
set -euo pipefail
out="/var/lib/node_exporter/textfile_collector/chrony.prom"
now=$(date +%s)
track=$(chronyc tracking)
# Извлекаем числовые значения с помощью awk/grep
offset=$(echo "$track" | awk -F ": +" '/System time/ {print $2}' | awk '{print $1}')
stratum=$(echo "$track" | awk -F ": +" '/Stratum/ {print $2}')
freq=$(echo "$track" | awk -F ": +" '/Frequency/ {print $2}')
lastoff=$(echo "$track" | awk -F ": +" '/Last offset/ {print $2}' | awk '{print $1}')
rms=$(echo "$track" | awk -F ": +" '/RMS offset/ {print $2}' | awk '{print $1}')
leap=$(echo "$track" | awk -F ": +" '/Leap status/ {print $2}')
# Нормализация leap в 0/1 (1=несинхронизирован)
leap_bad=0
if echo "$leap" | grep -qi "Not synchronized"; then leap_bad=1; fi
cat > "$out" <<EOF
# HELP chrony_system_time_offset_seconds Offset reported by chrony tracking.
# TYPE chrony_system_time_offset_seconds gauge
chrony_system_time_offset_seconds ${offset}
# HELP chrony_system_rms_offset_seconds RMS offset.
# TYPE chrony_system_rms_offset_seconds gauge
chrony_system_rms_offset_seconds ${rms}
# HELP chrony_system_last_offset_seconds Last offset.
# TYPE chrony_system_last_offset_seconds gauge
chrony_system_last_offset_seconds ${lastoff}
# HELP chrony_stratum Current NTP stratum.
# TYPE chrony_stratum gauge
chrony_stratum ${stratum}
# HELP chrony_frequency_ppm Estimated local clock frequency (ppm).
# TYPE chrony_frequency_ppm gauge
chrony_frequency_ppm ${freq}
# HELP chrony_leap_not_synchronized 1 if not synchronized.
# TYPE chrony_leap_not_synchronized gauge
chrony_leap_not_synchronized ${leap_bad}
# HELP chrony_scrape_timestamp_seconds Export timestamp.
# TYPE chrony_scrape_timestamp_seconds gauge
chrony_scrape_timestamp_seconds ${now}
EOF

Сделайте файл исполняемым и настройте периодический запуск таймером systemd. Если вам нужен быстрый ликбез по таймерам, посмотрите разбор в статье «cron, crontab и таймеры systemd».

sudo chmod 755 /usr/local/bin/chrony_export_metrics.sh

# /etc/systemd/system/chrony-exporter.service
[Unit]
Description=Export chrony metrics to textfile
After=network-online.target chronyd.service

[Service]
Type=oneshot
ExecStart=/usr/local/bin/chrony_export_metrics.sh

# /etc/systemd/system/chrony-exporter.timer
[Unit]
Description=Run chrony exporter every minute

[Timer]  
AccuracySec=1s
Unit=chrony-exporter.service

[Install]
WantedBy=timers.target

sudo systemctl daemon-reload
sudo systemctl enable --now chrony-exporter.timer

Дальше метрики окажутся в каталоге textfile‑коллектора вашего агента мониторинга. Заведите правила алертов: например, при chrony_system_time_offset_seconds > 0.1 — предупреждение, > 0.5 — крит.

Трюки и тонкости для VDS

• Старт после снапа/миграции. После перезапуска на другом гипервизоре часы могут уйти дальше обычного — позвольте makestep сделать 1–3 шага.
• Стабильные источники. Лучше 3–4 географически близких NTP‑сервера. Если есть источник от вашего провайдера — добавьте его в приоритет.
• Не дублируйте синхронизацию. Отключите в гостевой системе встроенную синхронизацию гипервизора, если она вмешивается во время. Пусть chrony будет единственным «диспетчером времени».
• Контейнеры. Контейнеры разделяют системные часы с хостом — ставьте chrony на хост и раздавайте время или направляйте контейнеры на ваш NTP‑сервер.
• Логи. Включите логирование tracking measurements statistics — удобно для ретроспективы дрейфа.

Диагностика проблем

Несколько типовых симптомов и куда смотреть:

• Stratum=16 и Leap: Not synchronized: проверьте доступность NTP‑источников, фаервол (123/udp наружу), DNS резолвинг и трассировку до серверов.
• Большой offset > 500 ms: выполните chronyc makestep. Если сразу возвращается — проверьте системную нагрузку и задержки сети.
• Скачет Frequency (ppm): это часто признак «дрожащих» виртуальных часов или вмешательства внешнего агента. Убедитесь, что только chrony управляет временем.
• Клиенты не получают время: убедитесь, что allow охватывает их сеть, порт 123/udp открыт, а клиенты действительно отправляют запросы на ваш адрес.
• Непредсказуемые прыжки назад: проверьте, не конфликтуют ли службы синхронизации. Разрешайте шаги только на старте, затем полагайтесь на «slew».

Расширенная настройка

Приоритеты источников

Можно назначить приоритеты источникам, если у вас есть «лучшие» (например, в пределах ЦОДа):

server ntp1.example.lan iburst prefer
server ntp2.example.lan iburst
pool pool.ntp.org iburst

prefer подсказывает chrony тянуться к этому источнику, если он валиден.

Ограничение количества источников

В большинстве случаев достаточно 3–5 источников. Избыточное количество увеличивает шум и задержки. Поддерживайте список актуальным.

Локальный режим при изоляции

Если ваш сервер временно изолирован от внешней сети, включение local stratum 10 orphan позволит раздавать более‑менее стабилизированное время клиентам, опираясь на собственные часы. Верните нормальные источники при первой возможности.

Логгирование и ротация

По умолчанию логи chrony небольшие. Если включили дополнительные типы логов, убедитесь в корректной ротации с помощью logrotate.

Проверка после настройки

# Общее состояние
chronyc activity
chronyc tracking
chronyc sources -v
chronyc sourcestats -v

# Клиенты (если сервер раздаёт время)
chronyc clients

# Принудительная коррекция шагом (аккуратно, лучше на старте)
sudo chronyc makestep

Оставьте систему поработать хотя бы час и снова сравните RMS offset и Frequency. Если дрейф стабилизировался и смещение держится в пределах десятков миллисекунд (или лучше) — цель достигнута.

Итоги

Chrony на VDS — это быстрый старт, точная синхронизация и надёжная работа в условиях виртуализации. С минимальной конфигурацией вы получаете аккуратную коррекцию времени, а при необходимости — собственный NTP‑сервер для сегмента инфраструктуры. Добавьте мониторинг дрейфа и простые алерты — и сюрпризы со временем перестанут влиять на ваши приложения, репликацию и безопасность.