Gdy dziennik dostępu Squida wygląda na opóźniony o lata

Natywny format dostępu Squida zaczyna się od znacznika czasu epoch, zwykle zapisywanego jako %ts.%03tu: sekundy od epochy, po których następują trzy cyfry milisekund. Wartość w tym miejscu nie jest sformatowaną datą kalendarzową.

Najpierw sprawdź aktywny format access_log. W Squidzie 7 przejrzyj wybór wyjścia i formatu access_log dla tej instancji. Niestandardowy format dziennika, prefiks syslog lub późniejszy procesor dzienników może umieścić inny znacznik czasu na początku wyświetlanego wiersza.

Trzy kontrole zawężają krąg

1. Zdekoduj wartość liczbową za pomocą właściwej jednostki. Cyfry ułamkowe są częścią wartości w sekundach, a nie osobnym całym znacznikiem czasu w milisekundach.
2. Porównaj zdekodowany czas UTC z wyświetlaniem czasu lokalnego. Różnica strefy czasowej może przesunąć wyświetlaną godzinę, a czasem dzień kalendarzowy; nie wyjaśnia jednak daty odległej o wiele lat.
3. Porównaj świeży wpis z zegarem maszyny uruchamiającej tę instancję Squida. Na hoście systemd timedatectl status raportuje ustawienia zegara i stan synchronizacji.

Jeśli zegar hosta również jest błędny, zbadaj jego synchronizację czasu i, jeśli ma to zastosowanie, konfigurację czasu maszyny wirtualnej. Jedna nieprawdopodobna data w dzienniku nie wystarcza, aby zidentyfikować uszkodzoną baterię zegara sprzętowego.

Jeśli zegar hosta jest poprawny, potwierdź, że plik jest aktualny i należy do tej instancji. Sprawdź rotowane archiwa, zdalnych kolektorów i konwersje znaczników czasu w narzędziu do przeglądania.

Odróżnij także znacznik czasu transakcji od momentu, w którym kolektor otrzymuje wiersz. Zwykłe rejestrowanie dostępu odbywa się po zakończeniu żądania, a rejestrowanie demona może zapisywać asynchronicznie. Długo trwające żądanie lub tunel nie musi pojawiać się w czasie początkowego połączenia.