sar: time going backwards — диагностика прыжков времени, TSC и chrony в Linux

Если вы видите в отчётах sysstat или в логах строку вида sar: time going backwards, это не «глюк sar». Это симптом: время в системе получило скачок, и инструменты, которые предполагают монотонное течение времени, начинают фиксировать, что «время пошло назад». Результат — поломанные графики, временные ряды, TTL/кеши, а иногда и ошибки аутентификации или TLS из‑за некорректных меток времени.

Ниже — практичная диагностика для Linux с упором на виртуалки (KVM, VMware, Hyper-V). Задача простая: найти источник time jump, понять роль clocksource и сообщений про tsc unstable, а затем стабилизировать синхронизацию через chrony (или грамотно настроить другой NTP-клиент).

Что именно означает «time going backwards» в sar

sar читает статистику из файлов /var/log/sysstat/saXX и ожидает, что временная шкала данных строго возрастает. Когда системное время смещается назад (или данные сначала записались «в будущее» после скачка вперёд, а затем время откатили), отметки времени перестают быть согласованными — и sar сообщает «time going backwards».

Важно различать два «мира времени» в Linux:

• Wall clock — «человеческое» время (то, что показывает date). NTP-клиент может плавно подстраивать его, а иногда (в зависимости от политики) делать ступенчатые коррекции (step).

• Monotonic — монотонное время, которое должно только увеличиваться. Оно используется таймерами, измерениями длительности, планировщиками, таймаутами. Оно опирается на аппаратный/паравиртуальный источник времени. При проблемах с источником (часто это TSC/clocksource) вы получаете «рваный» ход или редкие скачки на уровне приложений.

Практическое правило: заметный скачок wall clock назад почти всегда отражается в логах NTP-сервиса. А проблемы монотонности/частоты чаще вылезают сообщениями подсистемы timekeeping, TSC и clocksource в dmesg.

Типовые причины time jump: от NTP до гипервизора

1) Агрессивная коррекция времени NTP-клиентом (step)

Если NTP-клиент (chrony, ntpd, systemd-timesyncd) решил, что часы «далеко», он может сделать step-коррекцию. Типичные триггеры: долгий простой VM, пауза/возобновление, восстановление снапшота, старт без сети, резкое изменение аппаратных часов (RTC).

Особенно часто sar time going backwards ловят, когда:

• включена синхронизация времени и внутри гостя, и со стороны гипервизора (два «главных»);

• используются снапшоты/restore, и время «откатывается» вместе с состоянием VM;

• виртуалку держали на паузе, а потом «разморозили».

2) Нестабильный TSC и неудачный clocksource

TSC (Time Stamp Counter) — аппаратный счётчик. Он часто используется как источник времени из‑за скорости и точности, но в виртуализации (и на некоторых платформах) может вести себя плохо. Тогда в dmesg появляются сигналы вроде tsc unstable, watchdog-замечания и сообщения о переключении источника времени.

Когда tsc нестабилен, ядро может пометить TSC как ненадёжный и переключиться на другой источник (kvm-clock, hpet, acpi_pm, hyperv_clocksource и т. п.). Иногда это «лечит» проблему, иногда лишь делает её более редкой, но заметной для метрик.

3) Время «правит» гипервизор или гостевые инструменты

На VMware это часто синхронизация времени VMware Tools. На Hyper-V — интеграционные сервисы. На KVM/QEMU — паравиртуальные часы плюс особенности миграций.

Самый неприятный вариант — конфликт: NTP внутри гостя тянет время в одну сторону, а гипервизор периодически «подравнивает» в другую (иногда step-ом). В результате и появляются скачки, которые видит sar.

4) Leap second и leap smear (реже, но встречается)

Leap second сам по себе редко приводит к «время назад» на современных стэках, но если в инфраструктуре смешаны разные подходы (кто-то делает leap smear, кто-то — классический leap), клиенты могут получать разные «фазы времени» и корректироваться. В метриках это иногда выглядит как «странная скорость времени» вокруг события.

Быстрая диагностика: что проверить в первую минуту

1) Состояние времени и синхронизации

timedatectl status

Смотрите на:

• System clock synchronized — синхронизированы ли системные часы;

• NTP service — кто именно управляет временем (chrony/timesyncd/иное);

• таймзону и текущее время (помогает заметить неверную TZ после шаблона/образа).

2) Сообщения ядра про timekeeping и clocksource

dmesg -T | grep -Ei 'timekeeping|clocksource|tsc|unstable|kvm-clock|hyperv'

Ищите формулировки:

• Clocksource tsc unstable, Marking TSC unstable;

• Switching to clocksource ...;

• упоминания kvm-clock / hyperv_clocksource;

• предупреждения clocksource watchdog (часто коррелируют с «подвисаниями» времени).

3) Кто менял время: журнал NTP-сервиса

Если у вас systemd и journald:

journalctl -b | grep -Ei 'chrony|timesyncd|ntpd|time jump|step|offset'

Для chrony полезны и собственные команды:

chronyc tracking
chronyc sources -v
chronyc sourcestats -v

В chronyc tracking обычно достаточно понять три вещи: какой текущий offset, какая «частота» (frequency) и нет ли признаков регулярных крупных коррекций.

4) Текущий clocksource и доступные варианты

cat /sys/devices/system/clocksource/clocksource0/current_clocksource
cat /sys/devices/system/clocksource/clocksource0/available_clocksource

Если текущий — tsc, а в dmesg были признаки нестабильности, это красный флаг. В виртуалках чаще ожидаемо видеть kvm-clock (KVM) или специализированный источник Hyper-V.

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

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

Подробнее

Глубокая диагностика: отличаем «NTP сделал step» от проблем с TSC

Признаки, что виноват NTP-клиент

Обычно в логах есть явная запись о step/large adjustment. Для chrony это может быть «System clock was stepped», «Time jump detected» и похожие формулировки. Для systemd-timesyncd — сообщения о корректировке времени после получения ответа от сервера.

Также характерно: скачки происходят вскоре после загрузки, после восстановления сети или сразу после возобновления VM.

Признаки, что проблема ниже (clocksource / TSC / гипервизор)

• В dmesg видно, что tsc признан нестабильным, либо происходит переключение clocksource.

• Скачки коррелируют с высокой нагрузкой хоста, миграциями VM, изменением числа vCPU, «подвисаниями».

• NTP-сервис при этом не логирует step (или вообще выключен), а симптомы всё равно возникают.

Если вы ведёте мониторинг VM, удобно собрать диагностику в одну точку и привязать к событиям на гипервизоре. Как основу можно использовать подходы из статьи про NTP/chrony и мониторинг: как проверять состояние NTP/chrony и что мониторить на сервере.

Практика: что делать на виртуалках (KVM, VMware, Hyper-V)

KVM/QEMU: paravirtual clock и отсутствие «двойного управления»

В KVM чаще всего хорошо работает kvm-clock, а синхронизацию времени нужно согласовать: либо вы доверяете гостю (chrony внутри), либо используете механизмы гипервизора, но не даёте двум системам одновременно делать жёсткие коррекции.

Что проверить внутри гостя:

cat /sys/devices/system/clocksource/clocksource0/current_clocksource
dmesg -T | grep -Ei 'kvm-clock|tsc|clocksource'

Если у вас частые live migration, критично, чтобы TSC был «консистентным» между узлами. Иначе после миграции возможны скачки. Это уже зона настройки кластера: одинаковые CPU features/модель CPU, корректная политика совместимости, предсказуемые параметры времени на хостах.

VMware: проверьте синхронизацию времени в guest tools

На VMware частая причина time jump — когда гостевые инструменты периодически «подравнивают» время, а внутри гостя ещё и работает NTP. Выберите один источник истины. Для серверов обычно предпочтительнее стабильный NTP-клиент в госте (chrony), а гипервизорную подстройку отключают или переводят в более «мягкий» режим (зависит от политики и возможностей платформы).

Hyper-V: учитываем интеграционные сервисы и clocksource

На Hyper-V Linux использует специализированный источник времени, а корректировки могут идти через интеграционные компоненты. Правило то же: один главный механизм дисциплины времени и отсутствие конфликтов. Если вы видите скачки — ищите, не включены ли одновременно «помощники» Hyper-V и активный NTP-клиент с агрессивным step.

Chrony vs systemd-timesyncd vs ntpd: что выбрать

Для серверов и VM чаще всего выигрывает chrony:

• лучше переносит нестабильную сеть и особенности виртуализации;

• гибко управляет политикой step/slew;

• даёт удобные команды диагностики (chronyc tracking, chronyc sources -v).

systemd-timesyncd — простой клиент, часто «достаточный» для базовой синхронизации, но при расследовании скачков времени chrony заметно удобнее. Классический ntpd по-прежнему встречается, но в новых развёртываниях обычно выбирают chrony, если нет внутренних требований.

Если вы поднимаете новые сервера под проекты, следите, чтобы инфраструктура времени была одинаковой на всех узлах (особенно в кластерах и под оркестраторами). Для типовых веб‑проектов это одинаково актуально и на виртуальном хостинге, и на VDS — просто на VDS у вас больше контроля над системными сервисами и параметрами ядра.

Надежные SSL-сертификаты

Мы предлагаем широкий спектр SSL-сертификатов от GlobalSign по самым низким ценам. Поможем с покупкой и установкой SSL бесплатно!

Подробнее

Как настроить chrony, чтобы минимизировать «прыжки»

1) Убедитесь, что в системе один NTP-клиент

Нельзя одновременно держать chrony и systemd-timesyncd как активные клиенты дисциплины времени. Выберите один.

Проверка:

systemctl is-active chronyd
systemctl is-active systemd-timesyncd

Если переходите на chrony, обычно выключают timesyncd:

systemctl disable --now systemd-timesyncd

2) Разрешите step только при старте, дальше — только плавная коррекция

Рабочая стратегия: при загрузке один раз можно сделать step, если часы совсем неправильные (иначе ломаются TLS, пакетные менеджеры, API-клиенты). Но после того как система «встала на рельсы», любые большие коррекции назад крайне нежелательны.

Пример фрагмента конфигурации chrony:

# Разрешить step при смещении больше 1 секунды, но только в первые 3 обновления
makestep 1.0 3

Смысл: большие расхождения устраняем быстро только на старте, дальше дисциплинируем время плавно.

3) Зафиксируйте логи chrony, чтобы расследования занимали минуты

При инциденте вам важнее всего понять: был ли step, какой был offset и какие источники участвовали. Минимум — смотрите журнал сервиса:

journalctl -u chronyd -b

Если используется централизованный сбор логов/метрик, добавьте туда события chrony и ключевые поля (offset, selected source). Это резко ускоряет поиск первопричины.

Clocksource и TSC: как безопасно переключаться и что учитывать

Если вы уверены, что текущий clocksource проблемный (видите tsc unstable, регулярные переключения источника, явные «провалы» времени), иногда помогает принудительный выбор другого источника времени.

Для начала — просто посмотрите, что доступно:

cat /sys/devices/system/clocksource/clocksource0/available_clocksource

Проверить текущий источник:

cat /sys/devices/system/clocksource/clocksource0/current_clocksource

Долговременный вариант обычно задаётся параметром ядра clocksource=... в загрузчике. Это стоит делать как плановое обслуживание: неверный выбор может ухудшить точность таймеров или производительность. Если проблема проявляется только в VM, чаще правильнее лечить причину на стороне виртуализации (модель CPU, миграции, настройки времени гипервизора), а не «костылить» гостя.

Если скачки начались после включения миграций или изменений на кластере, сначала соберите корреляцию: время события, какие хосты участвовали, и что писал dmesg на госте. Часто это быстрее, чем перебор параметров ядра наугад.

Проверяем последствия: sar, метрики и «битые» sysstat-файлы

Даже после исправления первопричины у вас могут остаться «испорченные» файлы sysstat за день, когда произошёл откат времени: saXX содержит метки, которые sar будет считать неконсистентными.

Практически это означает:

• ошибка sar time going backwards может продолжать появляться при чтении истории за «проблемный» день;

• новые файлы (после фикса) будут уже нормальными.

Чтобы убедиться, что проблема не повторяется:

• проверьте новые записи journalctl по chrony/таймсинк;

• понаблюдайте сутки за chronyc tracking и стабильностью offset;

• посмотрите, исчезли ли сообщения timekeeping в dmesg после перезагрузки/миграции.

Чек-лист: короткий план действий при инциденте

1. Зафиксируйте факт: когда именно произошёл time jump (по метрикам/логам).

2. Снимите состояние: timedatectl status, chronyc tracking (если есть), текущий clocksource.

3. Проверьте dmesg на сообщения про timekeeping: tsc unstable, переключения clocksource, watchdog.

4. Убедитесь, что нет конфликта механизмов: chrony/ntpd vs systemd-timesyncd vs синхронизация гипервизора/guest tools.

5. Если это VM: уточните события на хосте (миграция, пауза, restore снапшота, перегрузка хоста).

6. Стабилизируйте схему: один NTP-клиент, предсказуемая политика step/slew, корректный clocksource и настройки гипервизора.

Частые вопросы

Нужно ли бояться leap smear?

Бояться — нет, но важно единообразие. Если часть инфраструктуры получает время от источника со smear, а часть — без, возможны корректировки на клиентах. В проде лучше, чтобы все серверы времени и клиенты придерживались одной политики.

Почему проблема «всплыла» в sar, а не в приложении?

sar просто заметил несогласованные отметки времени в собственных данных. Приложение могло пережить скачок «тихо», или симптомы пока не связали (скачущие графики, странные TTL, ошибки проверки сертификатов).

Можно ли полностью запретить любые шаги времени?

Теоретически да, но при сильно неверном времени после старта вы рискуете получить неработающие TLS-соединения, репозитории и внешние API. Обычно лучше компромисс: разрешить ограниченный step только на старте, а дальше — только плавная дисциплина.

Итог

sar time going backwards — это индикатор скачков времени, а не проблема sysstat. Быстро найти причину помогает связка: timedatectl (кто синхронизирует), журналы NTP-сервиса (был ли step/time jump) и dmesg по timekeeping (нет ли tsc unstable и переключений clocksource). В виртуализации чаще всего упирается в конфликт механизмов синхронизации или особенности TSC/clocksource при миграциях и паузах.

Если привести схему к простому виду (один клиент времени, понятная политика step/slew, корректный clocksource и согласованные настройки гипервизора), ошибки «время назад» обычно исчезают, а метрики становятся ровными.