Server má nesprávny čas. Ako preveriť synchronizáciu?
Chyby platnosti certifikátov, odmietnuté tokeny a nejasná časová os. Čo skontrolovať v UTC a chrony pred zásahom do hodín servera.
Certifikát podľa dátumu ešte platí, ale jeden klient ho odmieta. Prihlásenie hlási problém s platnosťou tokenu a udalosti z rôznych serverov do seba časovo nezapadajú. Pri takýchto príznakoch sa oplatí preveriť hodiny zariadenia, ktoré kontrolu vykonáva. Nesprávny čas je jedna z možných príčin, nie hotová diagnóza. Nasledujúci postup je určený pre Linux so systemd; príklady merania používajú chrony.
Porovnávajte rovnaký čas, nie rôzne pásma
Príkaz date -u zobrazí systémový čas v UTC. Doplňte timedatectl status a zaznamenajte dátum, časové pásmo aj stav synchronizácie. Odlišné lokálne zobrazenie ešte nemusí znamenať, že hodiny meškajú. Zmena pásma nenahradí opravu synchronizácie. Zistite, ktorá služba spravuje čas na konkrétnom hostiteľovi; samotný výpis hodín neukazuje ich odchýlku od zdroja času.
Pri certifikáte sa kontroluje platnosť medzi notBefore a notAfter voči aktuálnemu času. JWT používa exp pre koniec platnosti a nbf pre jej začiatok, ak sú tieto údaje prítomné. Preverte preto aj čas klienta alebo overujúceho backendu. Pri diagnostike nevypínajte kontrolu platnosti ani automaticky nepredlžujte životnosť tokenov; najprv si uložte presnú chybu a porovnajte časy.
Preverte meranie aj dostupnosť zdroja
Pri chrony začnite chronyc tracking. Pole System time uvádza rozdiel systémových hodín od času udržiavaného chrony; nie je zameniteľné s poľom Last offset. Pozrite aj Leap status, ktorý môže hlásiť Not synchronised. Výstup si uložte a neskôr porovnajte s ďalším meraním. Jedno malé číslo bez ostatných údajov nestačí na posúdenie synchronizácie.
Príkaz chronyc sources -v ukáže používané zdroje. Hviezdička označuje vybraný zdroj; otáznik môže znamenať nedostupnosť, nesynchronizovaný zdroj alebo nedostatok meraní. Pri chýbajúcich odpovediach overte DNS a cestu NTP paketov vrátane firewallu. Bežné NTP požiadavky smerujú na UDP port 123. Otvorený HTTPS prístup sám nepotvrdzuje, že táto komunikácia funguje.
Pred opravou odlíšte postupnú korekciu od skoku
Chrony bežne upravuje čas postupne zmenou rýchlosti hodín. Mechanizmus makestep umožňuje skokovú korekciu; konfiguračná direktíva ju vie obmedziť na prvé aktualizácie po štarte chronyd. Dokumentácia upozorňuje na dopad časových skokov na niektoré aplikácie. Pri veľkej odchýlke preto najprv určte jej príčinu a posúďte, ako opravu zvládnu bežiace služby.
Nekopírujte konfiguráciu opravy zo štartu systému do živého incidentu bez posúdenia. Zaznamenajte stav pred zmenou, pripravte postup pre závislé služby a po zásahu znovu overte synchronizáciu aj pôvodne zlyhávajúcu operáciu. Ak upravíte dostupnosť zdroja, sledujte aj to, či sa hodiny skutočne opravujú. Samotný návrat sieťových odpovedí ešte nedokončuje diagnostiku.
Sledujte odchýlku a správne merajte trvanie
Pri meraní trvania operácie používajte vhodné monotónne hodiny dostupné v danom runtime. Linuxové CLOCK_MONOTONIC neovplyvní náhly skok systémového času, hoci ich ovplyvňujú frekvenčné korekcie. Pre časové značky udalostí ponechajte kalendárny čas s jasným pásmom a identifikátorom hostiteľa. Trvanie požiadavky a čas jej vzniku sú dva odlišné údaje.
Do prevádzkového prehľadu zahrňte odchýlku aj stav synchronizácie. Hranicu upozornenia zvoľte podľa požiadaviek aplikácie, nie podľa univerzálneho počtu milisekúnd. Po reštarte alebo zmene zdrojov overte, že meranie pokračuje. Pri incidente porovnajte tento stav s chybami TLS, overovania tokenov a s logmi dotknutých hostiteľov.
- Zaznamenajte UTC a odlíšte chybu pásma od chyby hodín.
- Preverte chrony, vybraný zdroj a dostupnosť NTP odpovedí.
- Posúďte dopad korekcie pred skokovou zmenou času.
- Po zásahu overte synchronizáciu aj pôvodnú používateľskú operáciu.
Čo si odniesť
Pri podozrení na nesprávny čas overte zariadenie, ktoré rozhoduje o platnosti operácie. Najprv zmerajte synchronizáciu a dostupnosť zdroja, potom naplánujte korekciu. Opravu potvrďte meraním aj funkčnosťou služby.
