Назад | Перейти на главную страницу

Проверить, что внутренний NTP-сервер отправляет правильное время?

У меня работают два сервера уровня 3 NTP, и я хотел создать простую проверку, чтобы я мог определить, смещается ли время на каком-либо из серверов, и предупредить, что он не синхронизируется должным образом с общедоступными серверами уровня 2.

Моя первая мысль заключалась в том, чтобы получить время с нескольких серверов уровня 2 и сравнить это время с тем, что отправляют мои серверы ntp. Затем предупредите, если дрейф превышает дельту X.

Есть ли более стандартный способ или лучший метод проверки того, что сервер NTP отправляет правильное время?

TL; DR:

  1. Настройте свой NTP-сервер в соответствии с лучшие текущие практики.
  2. (Предупреждение о бесстыдном саморекламе.) Используйте мой ntpmon проверьте, использует ли ваше решение для мониторинга collectd, Nagios или telegraf.

Длинная версия:

Конфигурация

Самая важная основа для хорошего мониторинга NTP - это хорошая конфигурация NTP. Для лучшего понимания прочтите Лучшие текущие практики NTP (BCP 223 / RFC 8633). Вот краткое изложение рекомендаций по настройке:

  1. Своевременно обновляйте программное обеспечение NTP
  2. Используйте от 4 до 10 источников
  3. Убедитесь, что в этих источниках представлено множество эталонных часов.
  4. Не разрешать удаленное управление без аутентификации (должно быть по умолчанию в большинстве дистрибутивов)
  5. Используйте пул ответственно (он также должен быть по умолчанию в большинстве дистрибутивов)
  6. Не смешивайте источники со смазанным скачком и без него
  7. Не используйте режим вещания без аутентификации
  8. Не используйте anycast или балансировку нагрузки, когда обслуживаете время

Где измерить

Когда у вас есть хорошая локальная конфигурация, главное помнить, что ваша проверка должна запросить локальный NTP-сервер для его показателей, а не пытаться вручную измерить смещение от удаленных серверов. Основные серверы NTP (ntpd и chronyd) уже собирают все необходимые вам метрики, поэтому проверки, которые сравнивают часы с удаленными серверами, игнорируют многие встроенные возможности NTP.

Выбор метрики

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

  • системное смещение: вычисленное наилучшее предположение смещения локальных часов от единственного истинного времени
  • корневая дисперсия: рассчитанное максимальное смещение локальных часов от источников страты 0

Мониторинг

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

  1. Нагиос:
    • check_ntp_peer: неплохая базовая проверка; не проверяет достаточно широкий спектр показателей; немного слишком либерален в том, какие компенсации это позволяет
    • check_ntp_time: не рекомендуется; проверяет только смещение от данного удаленного NTP-сервера
    • check_ntpd: разумное покрытие чеков; используйте его, если вы предпочитаете Perl питону.
    • ntpmonпроверка nagios
  2. собрано:
    • Плагин NTP: некоторые метрики, которые он собирает, неясны
    • ntpmon в режиме сбора
  3. Прометей / Influxdb
    • экспортер узлов прометея: не рекомендуется; проверяет только смещение от данного удаленного NTP-сервера
    • телеграф плагин ввода ntpq: прямой перевод вывода ntpq в метрики телеграфа; это, вероятно, слишком подробно, если вы просто хотите знать: "Мой NTP-сервер в порядке?"
    • ntpmon в режиме телеграфа

Предостережения

  1. Выше представлена ​​сводная информация о состоянии по состоянию на октябрь 2016 г., когда я проводил обзор предупреждений и телеметрии. С тех пор все могло улучшиться.
  2. ntpmon это мой проект, который, я думаю, преодолевает недостатки проверок, которые были доступны в то время. Он поддерживает как ntpd, так и chronyd, а также перечисленные выше системы оповещения и телеметрии.

Конечно, стандартный подход заключается в использовании связанного клиента NTP под названием ntpq. Эта утилита может использоваться для отображения подключенных серверов, их доступности, разницы во времени и джиттера. Вот пример:

# ntpq -p
     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
*metasntp12.admi .MRS.            1 u  274 1024  377   64.445    1.086   0.450
+cecar.ddg.lth.s 130.149.17.8     2 u  811 1024  377   48.143   -0.810   0.175
 dir.mcc.ac.uk   85.199.214.100   2 u   7d 1024    0   76.708   -1.654   0.000

Здесь вы можете видеть, что три сервера настроены, два в порядке (достижимость 377 расширяется до двоичного числа 11111 1111, где 1 означает успешный ответ, а 0 означает отсутствие ответа - поэтому 377 означает 100% достижимость), а последний, вероятно, мертв для некоторая причина. Смещение означает смещение по времени в миллисекундах, а джиттер - это изменчивость.