Журналдар шашырамайтын желідегі уақытты синхрондау

Инфрақұрылым сағаттарының айырмасы себеп-салдарын дәлелдеу керек оқиғалар арасындағы уақыттан аз болуы тиіс. Сервер 47 секундқа қалып, коммутатор 18 секундқа озып тұрса, ал журнал жинау жүйесі қабылдаған сәттің өз белгісін қойса, бірыңғай оқиғалар тізбегі нанымды көрінгенімен, шындықты бұрмалайды.

Мен NTP-ны бір рет баптап, ұмытып кететін қосалқы параметр деп санамаймын. Уақыт журналмен, конфигурациямен және деректерді сақтау тізбегімен бірге дәлелдер жүйесіне кіреді. Сенімді сұлбаға бірнеше дереккөз, ішкі уақыт тораптары, сағатты түзетудің анық саясаты және нақты ығысуды бақылау керек. Қызмет күйінің жасыл белгісі өздігінен ештеңені дәлелдемейді.

Сағат айырмасы себеп пен салдардың ретін бұзады

Оқиғаны талдағанда күнтізбенің өзінен гөрі бір-біріне тәуелді әрекеттердің реті маңызды. Есептік жазба веб-серверге кірді, қолданба дерекқорға сұрау жіберді, желіаралық экран қосылуға рұқсат берді, коммутатор порт күйін өзгертті. Уақыт белгілері осы ретке қайшы келсе, талдаушы алғашқы сағаттарын себепті іздеуге емес, журналдармен дауласып өткізеді.

Қате жолдарды дұрыс сұрыптамаумен шектелмейді. Корреляция жүйесі бір оқиғаны бірнеше терезеге бөліп жіберуі, анықтау ережесі әрекеттер тізбегін жинай алмауы, ал сертификаттың немесе аутентификация билетінің жарамдылық мерзімі басқа сағатпен бағалануы мүмкін. Қатаң аутентификация хаттамаларында елеулі айырма кіруден бас тартуға әкеледі. Талаптары жұмсақ жүйелерде басқа қауіп бар: операция өтеді, бірақ оның ізі себептен бұрын пайда болады.

Бір жазбада көбіне бірнеше уақыт болады. Құрылғы оқиға уақытын қояды, агент оқу уақытын қосады, syslog қабылдағышы келген сәтті белгілейді, ал сақтау жүйесі индекстеу уақытын тіркейді. Бұл өрістерді бірдей санауға болмайды. Қабылдау уақыты жеткізу кідірісін бағалауға көмектеседі, бірақ дереккөздің қате сағатын түзетпейді. Байланыс қалпына келгеннен кейін коммутатор жиналып қалған хабарларды жіберсе, олар әр минутта болғанымен, қабылдағышқа бір мезетте дерлік келеді.

Сағат белдеуі де синхрондау емес. Екі торап 12:00 және 18:00 уақытын көрсетуі мүмкін, бірақ екеуі де UTC ығысуын дұрыс жазса, бір сәтті білдіреді. Керісінше, екі экрандағы сандар бірдей болғанымен, олардың айырмасы бірнеше секунд не минут болуы ықтимал. Орталық сақтауда UTC қолданған дұрыс, ал жергілікті уақытты көрсету кезінде пайдалануға болады. Сонда жазғы уақытқа ауысу, белдеу ережелерінің тарихи өзгеруі және қолмен баптау қайталанатын не түсіп қалған аралықтар жасамайды.

Уақыт белгісінің дәлдігін сағат дәлдігімен шатастырмаңыз. Үтірден кейін алты таңбасы бар жазба микросекундқа дейін дәл көрінеді, бірақ дереккөз екі секундқа қателесуі мүмкін. Таңба саны форматтың ажыратымдылығын сипаттайды, эталонға жақындығын емес. Тергеуге әдемі timestamp емес, әр құрылғы санатының өлшенген қатесі қажет.

Уақыт талабын тергеу міндеті анықтайды

Рұқсат етілетін ығысуды ажыратуға тура келетін ең жақын оқиғалардан есептеу керек. Егер жүйе желілік ереже қосылудан 200 миллисекунд бұрын іске қосылғанын дәлелдеуі тиіс болса, бір секундтық рұқсат тым үлкен. Ескі контроллер журналы уақытты бүтін секундпен ғана жазса, мінсіз NTP болса да, бір секунд ішіндегі екі операцияның ретін дәлелдеуге болмайды.

Журнал дереккөздерінің тізімін жасап, әрқайсысына төрт қасиетті жазыңыз: timestamp ажыратымдылығы, күтілетін сағат ығысуы, синхрондау тәсілі және қайта жүктелгеннен кейінгі әрекеті. Батареясы бар аппараттық сағаты жоқ құрылғыларды бөлек белгілеңіз. Олар зауыттық күнмен іске қосылып, алғашқы NTP жауабынан кейін уақытты бірден ауыстыруы мүмкін. Мұндай жағдайда жүктелудің алғашқы жазбаларын түзетусіз кейінгі жазбалармен араластыруға болмайды.

RFC 5424 стандарты syslog ішінде UTC уақытын Z жұрнағымен, нақты сандық ығысумен және секундтың бөлшек бөлігімен жіберуге рұқсат береді. Дереккөз жүйелік уақытты ала алмаса, NILVALUE қолдануға да болады. Бұл айырмашылық маңызды: сенімді уақыт белгісінің жоқтығы ойдан шығарылған жергілікті күннен дұрысырақ. Форматта жыл, ай, күн, сағат, минут, секунд, белдеу және жеткілікті бөлшек дәлдік болуын талап етіңіз. ALMT тәрізді белдеу атауы машиналық өңдеу үшін сандық ығысудан нашар, өйткені белдеу ережесі өзгереді, ал атау қай ереже қолданылғанын түсіндірмейді.

Әр топқа қате бюджетін белгілеңіз. Мысалы, қолданба серверлеріне 50 миллисекунд, қолжетімділік желісінің құрылғыларына 250 миллисекунд, ал сирек сұрау жіберетін дербес жабдыққа 1 секунд шек қоюға болады. Бұл сандарды сол күйінде көшірмеңіз: оларды желі кідірісі, жабдық мүмкіндігі және тергеу талабы анықтайды. Шектен асқан кезде журнал уақытша сенімсіз деп белгіленетін жазбаша ереже болғаны маңызды.

Түзету тәсілін де бекітіңіз. Баяу түзету қате жойылғанша жүйелік сағаттың жүру жылдамдығын өзгертеді. Күрт қадам сағатты бірден ауыстырып, уақыт аралығын қайталауы немесе алға секіруі мүмкін. Жұмыс саясаты әдетте қолданбалар әлі іске кіріспеген жүктелудің бастапқы кезеңінде қадамға рұқсат береді, ал одан кейін тек баяу түзетуді қолданады. Ерекше жағдайға жауапты адам керек: кейде үлкен қате қадамнан қауіпті, бірақ бұл шешімді мағынасы белгісіз әдепкі параметрге қалдыруға болмайды.

Монотонды сағат басқа мәселені шешеді. Қолданба операция ұзақтығын күнтізбелік уақыт түзетілгенде секірмейтін монотонды санауышпен өлшей алады. Алайда әр жүйедегі оқиғаларды салыстыру ортақ UTC уақытына сүйенеді. Монотонды уақыт NTP орнына жүрмейді, өйткені әр машинадағы санауыштың бастапқы нүктесі бөлек.

Сенімді сұлба бірнеше дереккөзден басталады

Ішкі клиенттерге кемінде екі қолжетімді уақыт торабы, ал уақыт тораптарының өзіне тәуелсіз сыртқы бағдарлар керек. RFC 8633 дәлдік маңызды операторларға кемінде төрт тәуелсіз әрі әртүрлі дереккөз ұсынады. Мұның мәні жай арифметикалық орта есепте емес. NTP алгоритмдері үміткерлерді салыстырады, анық қате сағаттарды алып тастайды және өзара келісетін топты таңдайды. Бір дереккөз болса, клиент байланыстың жоғалғанын анықтайды, бірақ қолжетімді сервердің қате уақыт беріп тұрғанын түсіне алмайды.

Корпоративтік ортаға қолайлы сұлба былай көрінеді:

1. Екі немесе одан көп ішкі уақыт торабы серверлер мен желілік жабдыққа тұрақты мекенжайлар арқылы қызмет көрсетеді.
2. Әр ішкі торап мүмкіндігінше тәуелсіз жолдармен бірнеше рұқсат етілген жоғары деңгейлі дереккөзді көреді.
3. Клиенттер кездейсоқ ашық пулды емес, конфигурацияны басқару жүйесі арқылы бірдей ішкі мекенжайлар жиынын алады.
4. Желіаралық экрандар UDP 123 трафигіне тек белгіленген клиенттер, ішкі тораптар және мақұлданған сыртқы мекенжайлар арасында рұқсат береді.
5. Мониторинг жүйесі әр торапты бөлек сұрап, оларды өзара салыстырады.

Stratum мәні төмен болғаны үшін бір серверді бүкіл компанияның жалғыз эталоны етпеңіз. RFC 5905 ішінде stratum иерархиядағы орынды сипаттайды: тірек сағаты бар дереккөзде stratum 1 болады, келесі деңгей 2 алады, осылай 15-ке дейін жалғасады, ал 16 синхрондау жоқ екенін білдіреді. Бұл сан сапа сертификаты емес. Тұрақсыз арнадағы stratum 2 сервері клиентке жақын әрі дұрыс басқарылатын stratum 3 серверінен нашар уақыт беруі мүмкін.

WAN арнасы сенімсіз филиалдарда жергілікті аралық тораптар пайдалы. Олар сыртқы дереккөздер уақытша жоғалғанда генератордың өлшенген ауытқуына сүйеніп, сағатты баяу жүргізе береді. Бірақ ұстап тұру режимі дәл уақытты жоқтан жасамайды: қате ұлғаяды, сондықтан мониторинг соңғы сәтті жаңартудың жасын көрсетуі тиіс. Ұзақ оқшауланғаннан кейін жергілікті сағатты үнсіз сенімді деп жариялауға болмайды.

Оқшауланған желіге PPS сигналы бар спутниктік уақыт қабылдағышы немесе корпоративтік қызметке бекітілген арна сияқты өз беделді дереккөзі қажет. Таңдау керек дәлдік пен қауіп моделіне байланысты. Маршрутизатордың жергілікті сағатын эталон деп жариялайтын қарапайым команда оның қатесін бүкіл желіге таратады. Бұл режим UTC дәлдігінен гөрі өзара бірдей уақыт маңызды қолданбаларға құжатталған ұстап тұру тәсілі ретінде жарауы мүмкін, бірақ журналдарда бұл шектеу көрсетілуі тиіс.

Қалыпты UTC шкаласындағы дереккөздерді қосымша секундты белгілі бір аралыққа созып тарататын дереккөздермен араластырмаңыз. RFC 8633 клиент мұндай қоспаны қолданбауы тиіс екенін ашық ескертеді: созу кезеңінде серверлердің айырмасы заңды түрде пайда болады, ал жауапта осы саясатты білдіретін стандартты белгі жоқ. Басқарылатын орта ішінде бір саясат таңдап, оны құжаттаңыз.

Алғашқы орнату мен баяу түзетуге бөлек ереже керек

NTP клиенті іске қосылғанда үлкен қатені тез түзетіп, одан кейін сағатты абайлап жүргізуі тиіс. Төмендегі chrony конфигурациясы екі ішкі серверге арналған бастапқы үлгі, бірақ мекенжайларды, шектерді және рұқсат етілген желілерді өз сұлбаңызға сай ауыстырыңыз:

server 10.20.0.10 iburst
server 10.20.0.11 iburst
makestep 1.0 3
rtcsync
driftfile /var/lib/chrony/drift

iburst параметрі дереккөз пайда болғаннан кейін алғашқы өлшемдерді жылдамдатады. makestep 1.0 3 ығысу бір секундтан асса, chronyd қызметіне сағатты қадаммен түзетуге рұқсат береді, бірақ тек алғашқы үш жаңарту кезінде. Одан кейін қызмет жиілікті баяу өзгертеді. Қолдайтын жүйелерде rtcsync ядроға жүйелік уақытты аппараттық сағатқа мерзімді көшіруге көмектеседі, ал driftfile іске қосылулар арасында генератор ауытқуының бағасын сақтайды.

Кез келген ескертуде үнемі chronyc makestep орындау керек деген кеңеске қарсымын. Бұл кеңес команда нәтижесін бірден әдемі ететіндіктен танымал. Жұмыс істеп тұрған дерекқорда, кезек жүйесінде немесе метрика жинағышта артқа қадам күнтізбелік уақыт аралығын қайталайды, ал алға қадам таймерлерді мерзімінен бұрын жабуы мүмкін. Алдымен қатенің көлемін, қолданбалардың күйін және синхрондаудың неге жоғалғанын анықтаңыз. Қолмен қадам жасау уақыттың оған дейінгі және кейінгі мәнін жазатын басқарылатын апаттық операция болуы тиіс.

Жүктелгеннен кейін тәуелді қызметтер бір процестің іске қосылғанын уақыт дайын екенінің дәлелі деп санамауы керек. Chrony үшін мына тексеруді қолдануға болады:

chronyc waitsync 60 0.010

Команда шамамен он секундтық аралықпен 60 ретке дейін тексеріп, chronyd синхрондалғанда және қалған түзету 10 миллисекундтан аспағанда сәтті аяқталады. Шек нақты қызметтің қате бюджетіне сай болуы тиіс. Қолданба дәлдігі төмен уақытпен іске қосыла алса, жүктелуді шексіз тоқтатпаңыз: нашарлаған күйді жазып, сенімді уақыт міндетті операцияларға тыйым салыңыз.

Виртуалды машинада бір түсінікті басқару контурын қалдырыңыз. Қонақ жүйедегі NTP қызметі мен гипервизор бір сағатты бір-бірінен тәуелсіз ауыстырса, оператор түсініксіз тербеліс көреді және түзетуді кім жасағанын анықтай алмайды. Гипервизордан синхрондау ұйқыдан ояну немесе көшіру кезінде пайдалы болуы мүмкін, бірақ оның рөлі қонақ қызметімен келісіліп, нақты платформада тексерілуі керек. Бір мезетте жүретін екі жасырын түзету осы екі саналы нұсқаның кез келгенінен нашар.

Контейнер әдетте хост ядросының сағатын қолданады, сондықтан контейнер ішіндегі бөлек NTP демоны мәселенің дереккөзін түзетпейді. Контейнер жұмыс істейтін торапты тексеріп, журналға торап пен дананың идентификаторларын қосыңыз. Сонда жазба timestamp қойған нақты сағатпен байланысады.

Коммутатор кездейсоқ эталон емес, клиент болуы тиіс

Желілік жабдықты серверлер қолданатын ішкі уақыт тораптарына бағыттаңыз. Сонда талдаушы журналдарды бір уақыт шкаласымен салыстырады, ал желі ашық DNS пен интернетке шығуға тәуелді болмайды. Екі немесе одан көп мекенжай көрсетіңіз, маршруттау мен сүзгі соған тәуелді жерде NTP үшін бастапқы интерфейсті бекітіңіз және платформа рұқсат етсе, UTC жүйелік белдеуін сақтаңыз.

Өндірушілердің синтаксисі әртүрлі. Cisco IOS үлгісіндегі командалары бар жабдықта ең қысқа бөлік мынадай болуы мүмкін:

clock timezone UTC 0 0
ntp server 10.20.0.10 prefer
ntp server 10.20.0.11

Бұл блокты басқа операциялық жүйеге тексермей көшірмеңіз. Нақты микробағдарлама нұсқасының нұсқаулығын қараңыз: server, peer, source-interface, VRF және аутентификация параметрлерінің атауы мен мағынасы өзгеше болады. Команданы қатесіз қабылдап, бірақ сұрауды дұрыс емес VRF арқылы немесе ACL тыйым салған мекенжайдан жіберетін конфигурация әсіресе қауіпті.

Cisco IOS жүйесіндегі show ntp associations командасы байланыстарды көрсетеді, бірақ жолдың бар болуы синхрондауды дәлелдемейді. Жұлдызша таңдалған жүйелік серіктесті көрсетеді, reach жауаптардың сегіз биттік тарихын сегіздік санау жүйесінде сақтайды, ал 377 соңғы сегіз сұрауға жауап келгенін білдіреді. Нөлдік reach осы терезеде сәтті жауап болмағанын көрсетеді. 377 кезінде ығысу үлкен болса, мәселе пакеттердің жай бөгелуінде емес, дереккөз сапасында, желі жолында немесе жергілікті сағатта болуы ықтимал.

address         ref clock       st  when  poll  reach  delay  offset  disp
*10.20.0.10     192.0.2.10       2    34    64    377  1.82    0.41  2.10
+10.20.0.11     192.0.2.20       2    29    64    377  2.04   -0.18  2.34

Мұндай нәтижені толық оқу керек. st иерархия деңгейін, delay жол бағасын, offset серіктеске қатысты айырманы, ал disp болжамды белгісіздікті көрсетеді. Өріс атаулары мен өлшем бірліктері платформалар арасында өзгеруі мүмкін, сондықтан метрика жинау жүйесін барлық құрылғыға ортақ бір тұрақты өрнекке құруға болмайды.

Арзан коммутатордағы SNTP клиенті толық NTP-дан қарапайым болуы және күрделі дереккөз таңдауына қатыспауы мүмкін. Бұл құрылғыны саясаттан шығару себебі емес. Оған қолдайтын бірнеше сервер беріңіз, желілік белгісіздікті азайтыңыз және нақты нәтижені сырттан тексеріңіз. Құрылғы уақытты тек бүтін секундпен жазса, осы шекті тергеу моделіне қосыңыз.

Уақыт дереккөзін аутентификациялау алмастыру қаупін азайтады, бірақ сағаттың өзі дұрыс екенін дәлелдемейді. RFC 5905 осы айырмашылықты атап өтеді: сенімді тараптың қабылдағышы бұзылуы немесе конфигурациясы қате болуы мүмкін. Платформа қолдайтын қазіргі механизмді қолданыңыз, құпияларды қорғаңыз және желіні шектеңіз, бірақ тәуелсіз бақыланатын бірнеше дереккөзді сақтаңыз.

Тексеру процестің барын емес, күйді өлшеуі керек

Дұрыс тексеру бес сұраққа жауап береді: дереккөз таңдалды ма, үміткер саны жеткілікті ме, қазіргі ығысу қандай, белгісіздік қаншалық үлкен және сағат соңғы рет қашан қадаммен түзетілді. systemctl is-active chronyd тек процесс туралы сұраққа жауап береді. Қызмет жұмыс істеп, бір де бір дереккөзді көрмей, машинаны ескі driftfile бойынша өз бетінше жүргізе алады.

Chrony бар Linux жүйесінде екі командадан бастаңыз:

chronyc -n tracking
chronyc -n sources -v

Қалыпты tracking нәтижесінің қысқартылған түрі мынадай:

Reference ID    : 10.20.0.10
Stratum         : 3
Ref time (UTC)  : Mon Jul 27 10:42:18 2026
System time     : 0.000004321 seconds slow of NTP time
Last offset     : -0.000006102 seconds
RMS offset      : 0.000021443 seconds
Leap status     : Normal

Chrony ішіндегі System time соңғы өлшенген offset қана емес, жүйелік сағат пен NTP бағасы арасындағы қалған түзетуді білдіреді. Leap status: Normal хаттама күйінің қалыпты екенін растайды, бірақ қабылдау сынағы сандық шекті де тексеруі керек. Reference ID жолы таңдалған дереккөзді көрсетеді, алайда мониторинг резервтегі үміткерлерді де көруі тиіс.

sources -v ішінде ^* таңдалған серверді, ^+ жарамды қосымша дереккөзді, ^- алгоритм таңдамаған дереккөзді, ал ^? өлшемі жеткіліксіз дереккөзді білдіреді. Бір ^* және үнемі қолжетімсіз үш мекенжай дәл қазір дұрыс уақыт береді, бірақ келесі ақауға төзімділік бермейді. Конфигурация өзгергеннен кейін бірнеше сұрау циклін күтіп, үміткерлердің сіздің бюджет шегінде сәйкесетінін растаңыз.

Коммутаторларда өндіруші қарастырған күй және байланыс командаларын бірге қолданыңыз. Cisco IOS үшін бұл әдетте show ntp status және show ntp associations detail. Біріншісі жүйелік сағаттың синхрондалғанын және stratum деңгейін көрсетеді, екіншісі үміткерлердің таңдалуы мен қабылданбауын түсіндіреді. Басқару жүйесіндегі жасыл белгінің суретін ғана емес, тексеруші тораптың уақыт белгісімен бірге толық нәтижені сақтаңыз.

Жолды әдейі жасалған, бірақ қауіпсіз ақаумен тексеріңіз. Сынақ клиентінде бір ішкі серверді конфигурациядан уақытша алып тастаңыз немесе оны дәл ережемен бөгеп, клиенттің рұқсат шегінен шықпай басқа дереккөзді таңдағанын тексеріңіз. Мұндай сынақты екі уақыт торабында қатар жүргізбеңіз және резервтік қатынау жолы жоқ өндірістік коммутатордан бастамаңыз. Дереккөзді қайтарғаннан кейін оның үлкен қатеге байланысты қабылданбай қалмай, қайта үміткер болғанын тексеріңіз.

Екі терминалда date нәтижесін салыстыру тек жалпы диагностикаға жарайды. Адам Enter пернесін екі жерде бір мезетте баса алмайды, нәтиже дөңгелектенеді, ал қашықтағы консоль кідірісі белгісіз. Хаттаманың өз метрикаларын және тәуелсіз сұрауды қолданыңыз. Экрандағы секундтардың сәйкесуі миллисекундтық бюджетті дәлелдемейді.

Жаңа алаңды қабылдау сынағы бір тыныш сәтті емес, уақыт қызметінің толық циклін қамтуы тиіс. Аппараттық сағатын әдейі қате қойған сынақ клиентін қайта жүктеп, алғашқы дереккөзді қашан алғанын, қадамды қашан жасағанын және рұқсат шегіне қашан кіргенін тіркеңіз. Содан кейін қолданбалар жұмыс істеп тұрғанда тек NTP қызметін қайта іске қосыңыз: жүктелу терезесінен кейін күтпеген қадам болмауы керек. Бір дереккөздің жоғалуын, WAN үзілгеннен кейін қалпына келуді және конфигурацияда атаулар қалса, DNS қолжетімсіз кездегі әрекетті бөлек тексеріңіз.

Қабылдау нәтижесінде сандар мен бастапқы команда нәтижелері болуы керек. «Уақыт синхрондалады» деген тұжырымды қайталап тексеру мүмкін емес. Бастапқы ығысуды, рұқсат шегіне кіру уақытын, ауысу кезіндегі ең үлкен offset мәнін, қолжетімді үміткерлер санын және конфигурация нұсқасын жазыңыз. Әр сәтсіздікте қай шек бұзылғанын көрсетіңіз. Мұндай хаттама микробағдарламадағы жаңа ақауды модельдің бұрыннан бар шектеуінен ажыратуға көмектеседі.

Журналдар түзетілген жүйелік сағатты шынымен қолданатынын да тексеріңіз. Кейбір қолданбалар сағат белдеуін қайта іске қосылғанға дейін кэште сақтайды, ал кей желілік құрылғыларда жүйелік уақыт пен syslog timestamp үшін бөлек параметрлер бар. Сынақ есептік жазбасымен кіру немесе бос порт күйін өзгерту тәрізді бақыланатын оқиға жасап, құрылғының бастапқы жазбасын, қабылдағыш жазбасын және NTP метрикасын салыстырыңыз. Оқиға мен қабылдау уақытының айырмасы белгісіз тұрақты түзетумен емес, өлшенген кідіріспен түсіндірілуі керек.

Жөндеуден кейін сәтсіз тексерулердің нәтижесін жоймаңыз. Олар қатенің сипатын көрсетіп, ескерту ережелеріне материал береді. Екінші дереккөзді бөгегенде үміткер саны азайып, күй жасыл болып қала берсе, дәл осы ауысу бөлек мониторинг шартына айналуы тиіс. Қабылдау сынағы инженер қай жерді қарау керегін әлі ұмытпаған кезде емес, қайта жасалатын ақау автоматты түрде көрінген кезде аяқталады.

Уақытты қызмет ретінде бақылау қажет

Мониторинг уақыттық қатарды сақтауы тиіс, әйтпесе қысқа үзіліс тергеу басталғанша жоғалып кетеді. Offset, жарамды дереккөздер саны, ағымдағы дереккөз, stratum, root delay немесе оның баламасы, dispersion, reachability, жиілік түзетуі, соңғы жаңартудың жасы және сағат қадамы оқиғаларын жинаңыз. Барлық өрісті бермейтін жабдықта қолжетімдісін жазып, сыртқы салыстырумен толықтырыңыз.

Бір ғана offset шегі жеткіліксіз. Мына күйлерге бөлек ескерту орнатыңыз:

• таңдалған дереккөз жоқ;
• жарамды дереккөз саны қабылданған ең төменгі мөлшерден аз;
• ығысу бірнеше сұрау қатарынан бюджеттен асады;
• offset әлі аз болғанымен, белгісіздік немесе жаңарту жасы өседі;
• қызмет жүктелу терезесі аяқталғаннан кейін сағатты қадаммен өзгертті.

Ескертудің кідірісі бір жоғалған UDP пакеті үшін кезекші инженерді оятпауға көмектеседі. Бірақ орташа есеп 30 секундтық күрт қадамды жасырып қалмауы тиіс. Әр аралықтағы абсолюттік ығысудың максимумын, дереккөз ауысуының санауышын және бөлек түзету оқиғасын сақтаңыз. -30 және +30 мәндерінің орташа саны нөл, бірақ журналды бағалауға мүлде пайдасыз.

Ішкі тораптарды әртүрлі желілік аймақтан тексеріңіз. NTP серверінің жанындағы монитор филиал ACL ережесі жауаптарды бөгегенін немесе кері маршрут оларды басқа жолға жібергенін байқамайды. Клиент метрикасы сервер қолжетімділігінен маңыздырақ: сервер жергілікті мониторға жауап беріп, желінің жартысына қолжетімсіз болып қала алады.

Синхрондау күйі журнал контексіне енуі тиіс. Ағынды үлкейтсе, әр жолға offset қосудың қажеті жоқ. Ағымдағы дереккөз, ығысу, белгісіздік және конфигурация идентификаторы бар мерзімді оқиға жеткілікті. Сонда мониторинг панелі егжей-тегжейлі метрикаларды өшіріп қойған болса да, тергеу кезінде нақты аралықта құрылғыға қай сағат қызмет еткенін анықтауға болады.

Конфигурацияны бекітілген эталонмен мерзімді салыстырыңыз. Сервер мекенжайы, VRF, ACL, белдеу, сұрау аралығы және жергілікті эталон режимі жаңарту мен апаттық жұмыстар кезінде өзгереді. Күйді тексеру салдарын ұстайды, ал конфигурацияны бақылау себебін түсіндіреді. Екеуі де қажет, өйткені желі бұзылған кездегі дұрыс файл мен кездейсоқ конфигурациясы бар жұмыс желісінің жөндеу тәсілдері бөлек.

Ескертудің нақты иесі болуы тиіс. Желі тобы UDP қолжетімділігіне, маршруттауға және коммутатор баптауларына жауап береді, платформа тобы ішкі серверлер мен клиент саясатын басқарады, ал қолданба иелері рұқсат етілетін бюджетті анықтайды. Бұл үш бөлек ескерту жүйесін талап етпейді. Үлкен offset туралы сигнал бір апта бойы «біздің мәселе емес» деген белгімен кезектер арасында көшпеуі үшін эскалация жолы керек.

Әр ірі сегменттен жасалатын синтетикалық тексеру ортақ уақыт шкаласын да бақылайды. Бақылаушы екі ішкі торапты сұрайды, олардың айырмасын есептейді және жауаптарды бөлек рұқсат етілген бағдармен салыстырады. Екі корпоративтік сервер ортақ жоғары деңгейлі дереккөз кесірінен бір бағытқа бірге ауытқыса, өзара салыстыру нөл көрсетеді, ал сыртқы бақылау ортақ ығысуды табады. Бақылау дереккөзі тексеріліп жатқан серверлер үшін жалғыз дереккөз болмауы тиіс.

Уақыт метрикаларын тергеуге түсуі мүмкін журналдар сақталатын мерзім бойы ұстаған дұрыс, бірақ егжей-тегжейін уақыт өте азайтуға болады. Бір сағаттың жалғыз орташа мәні жеткіліксіз: шеткі мәндерді, дереккөз ауысуын, синхрондау күйін және қадамдарды біріктірмей сақтаңыз. Әйтпесе бір айдан кейін күмәнді операция сәтіндегі бір минуттық қате жоғалған тегіс сызық қана қалады.

Қалыпты ақаулардың ізі бірден танылады

UDP 123 трафигі толық жоғалса, әдетте reach 0 болады, таңдалған дереккөз жоғалады және соңғы жаңартудың жасы өседі. Жалпы портты ғана емес, бағытты, бастапқы мекенжайды, VRF және кері жолды тексеріңіз. NTP сұрау мен жауапты қолданады, сондықтан қайтатын трафиксіз шығыс ережесі клиентке өлі сервер сияқты көрінеді.

Жартылай сүзгілеу одан да қауіпті. Бір ішкі мекенжай қолжетімді, екіншісі жоқ болғандықтан, күй бірнеше ай жасыл тұрады. Жалғыз қолжетімді сервер техникалық қызметке кеткенде, бүкіл сегмент уақыттан айырылады. Мұндай ақауды жарамды дереккөз санына ескерту және жоспарлы ауысу сынағы табады, ал таңдалған дереккөзді тексеру таппайды.

Аппараттық сағаты дұрыс емес құрылғы қайта жүктелгеннен кейін ескі күнмен бірнеше хабар жазады, NTP алады да, қазіргі уақытқа секіреді. Жинағыш тек дереккөз уақытымен сұрыптаса, жүктелу себебі оның жалғасынан алыс кетеді. Құрылғы берсе, қабылдау уақыты мен хабардың реттік нөмірін сақтаңыз. Талдауда синхрондау сәтін сағаттың екі режимі арасындағы шекара деп қараңыз.

Reach жақсы болған кездегі баяу ауытқу жүктемесі жоғары торапты, тұрақсыз виртуалды ортаны, екі түзету механизмінің қайшылығын немесе кідірісі қатты өзгеретін желі жолын көрсетуі мүмкін. Last offset, RMS offset, жиілік түзетуі және дереккөз ауысуын салыстырыңыз. Қызмет ұзақ уақыттық қате сағатты жаңа ғана түзеткенде, бір ағымдағы мән қалыпты көрінуі ықтимал.

Тағы бір таныс жағдай: әкімші коммутатор уақытын қолмен қояды, бірақ NTP ақауын түзетпейді. Журналда секіріс пайда болады, кейін қызмет сағатты дереккөзге баяу қайтарады немесе екінші қадам жасайды. Қолмен жасалған әрекетті өзгерістер журналына жазып, платформа рұқсат етсе, команданы рөлдер арқылы шектеңіз. Қолмен орнату экрандағы көрсеткішті жөндейді, уақыт қызметін емес.

Қате жергілікті эталон ақауды өте ұқыпты таратады. Барлық клиент өзара келіседі, панельдер жасыл, offset аз, бірақ бүкіл желі UTC уақытынан қалып не озып тұрады. Сондықтан ішкі тораптарды тәуелсіз сыртқы бағдарлармен салыстырыңыз және ескерту жүйесін сол иерархияның өзіне тұйықтамаңыз. Топ ішіндегі келісім мен UTC-ге қатысты дұрыстық екі бөлек тексеру.

Жергілікті уақыт пен UTC-ді араластыру бүтін сағат санындағы тұрақты ығысуға ұқсайды, ал NTP қатесі әдетте аз және баяу өзгереді. Сағат белдеуін жүйелік сағатты ауыстырумен түзетпеңіз. Алдымен бастапқы timestamp жолын, оның сандық ығысуын және жинағыштағы көрсету параметрлерін қараңыз. Әйтпесе бірінші қатенің үстіне екіншісін қосасыз.

Оқиғаны сағат қатесімен бірге қалпына келтіру керек

Оқиға болып қойған болса, бастапқы журналдарды өңдемеңіз және түзетуді архивтің өзіне қоспаңыз. Түпнұсқаларды, бақылау сомаларын, қабылдау деректерін және уақыт конфигурациясын сақтаңыз. Қалыпқа келтірілген уақыт тізбегін әр түзетудің дереккөзі мен қолданылатын аралығы көрсетілген бөлек көрініс ретінде жасаңыз.

Талдаудың жұмыс реті бес әрекеттен тұрады:

1. Әр маңызды тораптағы NTP күйін, соның ішінде таңдалған дереккөзді, offset, stratum, reach және соңғы түзету уақытын тіркеңіз.
2. Сыртқы уақыты бар оқиғаларды табыңыз: бақыланатын интерфейстегі пакет жазбасын, орталық қабылдағыш жазбасын, сенімді жүйенің транзакциясын немесе тәуелсіз уақыт белгісі бар физикалық әрекетті.
3. Аралықты қайта жүктеу, қолмен орнату, уақыт қадамдары және дереккөз ауысуы бойынша бөліңіз.
4. Бір нүкте бүкіл ауытқуды сипаттайды деп көрсетпей, әр бөлікке түзету мен белгісіздік ауқымын бағалаңыз.
5. Тәуелді оқиғаларды осы ауқымды ескеріп сұрыптап, ретін дәлелдеу мүмкін емес жұптарды белгілеңіз.

Веб-сервер өз сағаты бойынша 10:00:00 кезінде сұрау жіберді, желіаралық экран қосылуды 10:00:31 деп жазды, ал қабылдағыш екі жолды да шамамен 10:00:34 кезінде алды делік. Тексеру сервердің 35 секундқа қалып, экранның 2 секундқа озып тұрғанын көрсетеді. Қалыпқа келтіргеннен кейін бағалар 10:00:35 және 10:00:29 болады. Бұл желілік оқиғаны сұраудың себебі деп жариялауға негіз бермейді: өлшеу аралықтары мен жеткізу кідірісі қабаттасуы мүмкін. Дұрыс қорытынды мынадай: сағат дәлдігі осы екі жазбаның ретін дәлелдеуге жетпеді.

Бір торап үшін екі бақылау нүктесі болса, олардың арасындағы сызықтық ауытқуды бағалауға болады, бірақ алдымен қадам болмағанын тексеріңіз. Қадам кезінде түзету функциясы үзіледі, ал түзу сызық шын мәнінде болмаған уақыттарды жасайды. Баяу түзетуде де белгісіздік ауқымын сақтаңыз, өйткені желілік offset әр микросекундтағы нақты қабырға сағаты емес, кідірісі мен дисперсиясы бар баға.

Талдаудан кейін бұзылған NTP мекенжайымен бірге дәлелдің жетіспеуін де түзетіңіз. Метрикаларды, түзету оқиғаларын, конфигурация эталонын және ауысу сынағын қосыңыз. Жаңа сервер бөлмесі немесе желіні жаңарту кезінде GSE.kz компаниясы өзі сипаттаған серверлік инфрақұрылым мен тәулік бойғы техникалық қолдауға сүйеніп, уақыт архитектурасы мен оның күйін жинауды жүйелік интеграция жобасына енгізе алады. Нақты шектер мен дереккөздерді ұйымның өзі бекітуі тиіс, өйткені оларды қолданбалар, желі және қауіп моделі анықтайды.

Уақыты қате журналды кейін сақталған өлшемдерден дәлірек ету мүмкін емес. Бірақ жаңа түсініксіз жазбалардың пайда болуын тоқтатуға болады: уақыт қызметіне жауапты адамды белгілеңіз, резервтік дереккөздерді ақау кезінде тексеріңіз және бюджеттен асуды келесі оқиғадан бұрын көрінетін етіңіз.