Když přístupový protokol Squidu vypadá o roky opožděný

Nativní formát přístupu Squidu začíná časovým razítkem epochy, obvykle zapisovaným jako %ts.%03tu: sekundy od epochy následované třemi číslicemi milisekund. Hodnota na tomto místě není naformátované kalendářní datum.

Nejprve zkontrolujte aktivní formát access_log. U Squidu 7 si projděte volbu výstupu a formátu access_log pro danou instanci. Vlastní formát protokolu, předpona syslogu nebo následný zpracovatel protokolů mohou na začátek zobrazeného řádku umístit jiné časové razítko.

Tři kontroly zúží okruh

1. Dekódujte číselnou hodnotu pomocí správné jednotky. Desetinné číslice jsou součástí hodnoty v sekundách, nikoli samostatné celé časové razítko v milisekundách.
2. Porovnejte dekódovaný čas UTC se zobrazením místního času. Rozdíl časového pásma může posunout zobrazenou hodinu a někdy i kalendářní den; nevysvětlí však datum vzdálené mnoho let.
3. Porovnejte nový záznam s hodinami stroje, který danou instanci Squidu provozuje. Na hostiteli se systemd timedatectl status hlásí nastavení hodin a stav synchronizace.

Pokud jsou špatné i hodiny hostitele, prozkoumejte jejich časovou synchronizaci a případně konfiguraci času virtuálního stroje. Jeden nepravděpodobný datum v protokolu nestačí k určení vadné baterie hardwarových hodin.

Pokud jsou hodiny hostitele správné, ověřte, že soubor je aktuální a patří dané instanci. Zkontrolujte rotované archivy, vzdálené sběrače a převody časových razítek v prohlížecím nástroji.

Rozlišujte také časové razítko transakce od okamžiku, kdy sběrač řádek obdrží. Běžné zaznamenávání přístupu probíhá po dokončení požadavku a protokolování démona může zapisovat asynchronně. Dlouho běžící požadavek nebo tunel se nemusí objevit v čase počátečního připojení.