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

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

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

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

Источник

2 ответа

Решение

TL;DR:

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

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

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

Самая важная основа для хорошего мониторинга NTP - хорошая конфигурация NTP. Чтобы лучше понять это, прочтите последний проект RFC Best Current Practices (BCP). Вот сжатое резюме его рекомендаций по конфигурации:

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

Где измерить

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

Метрический выбор

Итак, к вашему вопросу, метрики, которые вас больше всего интересуют:

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

мониторинг

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

  1. Nagios:
    • check_ntp_peer: достойная базовая проверка; не проверяет достаточно широкий спектр метрик; слишком либерально в том, что позволяет
    • check_ntp_time: не рекомендуется; проверяет только смещение от заданного удаленного NTP -сервера
    • check_ntpd: разумное покрытие проверки; используйте его, если вы предпочитаете Perl Python.
    • ntpmon 's проверка nagios
  2. collectd:
    • Плагин NTP: некоторые метрики, которые он собирает, неясны
    • ntpmon в режиме сбора
  3. Prometheus / influxdb
    • экспортер узла прометея: не рекомендуется; проверяет только смещение от заданного удаленного NTP -сервера
    • плагин ввода telegraf ntpq: прямой перевод вывода ntpq в метрики telegraf; это, вероятно, слишком подробно, если вы просто хотите знать, "мой 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 расширяется до двоичного 11 111 1111, где 1 означает успешный ответ, а 0 означает отсутствие ответа - так что 377 означает достижимость 100%), а последний, вероятно, мертв для некоторая причина. Смещение означает смещение времени в миллисекундах, а джиттер - это изменчивость.

Источник
Другие вопросы по тегам