Amikor a Squid hozzáférési naplója évekkel elmaradottnak tűnik

A Squid natív hozzáférési formátuma epoch-időbélyeggel kezdődik, amelyet általában %ts.%03tu alakban írnak: az epoch óta eltelt másodpercek, majd három számjegy milliszekundum. Az ezen a helyen álló érték nem formázott naptári dátum.

Először ellenőrizze az aktív access_log-formátumot. A Squid 7 esetében tekintse át az adott példány access_log-kimenetének és -formátumának kiválasztását. Egy egyéni naplóformátum, egy syslog-előtag vagy egy későbbi naplófeldolgozó más időbélyeget tehet a megjelenített sor elejére.

Három ellenőrzés szűkíti a kört

1. Dekódolja a számértéket a megfelelő mértékegységgel. A törtszámjegyek egy másodpercérték részei, nem különálló egész időbélyeg milliszekundumban.
2. Hasonlítsa össze a dekódolt UTC-időt a helyi idő megjelenítésével. Az időzóna-különbség elmozdíthatja a megjelenített órát és néha a naptári napot; de nem magyaráz meg egy sok évvel távolabbi dátumot.
3. Hasonlítson össze egy friss bejegyzést annak a gépnek az órájával, amely az adott Squid-példányt futtatja. systemd-gazdagépen a timedatectl status jelentéseket ad az órabeállításokról és a szinkronizálás állapotáról.

Ha a gazdagép órája is hibás, vizsgálja meg az időszinkronizálást és adott esetben a virtuális gép időbeállítását. Egyetlen valószínűtlen naplódátum nem elegendő a meghibásodott hardveres óraelem azonosításához.

Ha a gazdagép órája helyes, erősítse meg, hogy a fájl naprakész és ehhez a példányhoz tartozik. Ellenőrizze a forgatott archívumokat, a távoli gyűjtőket és az időbélyeg-átalakításokat a megjelenítő eszközben.

Különböztesse meg a tranzakció időbélyegét attól az időponttól, amikor egy gyűjtő megkapja a sort. A szokásos hozzáférési naplózás a kérés befejezésekor történik, a démon naplózása pedig aszinkron módon írhat. Egy hosszú ideig futó kérésnek vagy alagútnak nem kell a kezdeti kapcsolat idején megjelennie.