Analizza timestamp dei log

I file di log non si mettono d'accordo su come scrivere un timestamp. La Sua applicazione emette ISO 8601, l'host scrive in syslog e il web server marca tutto nel formato common log di Apache: unire tre fonti significa riscrivere sempre lo stesso codice di parsing. Una sola chiamata sostituisce una pila di regex specifiche e calcoli sui fusi orari.

Tre formati, una sola risposta normalizzata

Ogni fonte di log ha scelto la propria convenzione decenni fa e non l'ha più cambiata. I timestamp ISO 8601 come 2026-07-25T14:30:00.123Z sono inequivocabili, ma sono solo uno dei formati che incontrerà sul campo. Le righe syslog secondo RFC 3164 si aprono con un marcatore come Jul 25 14:30:00: niente anno, niente fuso orario e un doppio spazio quando il giorno ha una sola cifra.

I log di accesso di Apache e nginx nel common log format usano una forma completamente diversa: 25/Jul/2026:14:30:00 +0200, con barre, due punti e un offset numerico. Il parser di timestamp dei log accetta il timestamp iniziale di una riga in uno qualsiasi dei tre formati e risponde con un'unica stringa ISO 8601 UTC normalizzata, i millisecondi epoch e il nome del formato riconosciuto. Non dovrà più ramificare il codice in base al tipo di fonte: qualunque cosa arrivi, un solo campo Le dice quando è successo.

Tutto ciò che non inizia con un timestamp noto viene rifiutato con un errore chiaro invece di una data indovinata, così una riga malformata fallisce rumorosamente a monte invece di corrompere silenziosamente le Sue analisi a valle.

Cosa significa davvero normalizzare

È nella normalizzazione che si annidano i bug più subdoli, quindi le regole sono dichiarate in modo esplicito. Un input ISO 8601 con offset esplicito, ad esempio 2026-07-25T16:30:00+02:00, viene convertito in UTC e restituito come 2026-07-25T14:30:00.000Z: lo stesso istante, un'unica grafia canonica. Un marcatore ISO senza alcuna zona viene considerato UTC, l'impostazione predefinita meno sorprendente per i log dei server.

L'offset numerico obbligatorio di Apache viene rispettato esattamente. I secondi frazionari sono mantenuti con precisione al millisecondo. La validazione del calendario è rigorosa: il 30 febbraio, una venticinquesima ora o un sessantunesimo secondo sono errori, non silenziosi riporti al giorno successivo, perché una pipeline di log che accetta date impossibili prima o poi La trarrà in inganno durante un incidente.

Pensato per le pipeline, deterministico per progettazione

Il parser è una funzione pura: espressioni regolari per riconoscere il formato, poi aritmetica intera sul calendario per convertire le date civili in epoch. Non legge mai l'orologio di sistema, non chiama mai la rete e non dipende mai dal fuso orario della macchina su cui gira: lo stesso input produce lo stesso output nei Suoi test di oggi e in produzione fra un anno. Questo determinismo conta quando rielabora log archiviati attraverso una nuova pipeline e si aspetta che la linea temporale ricostruita corrisponda all'originale byte per byte.

Gli usi tipici sono la normalizzazione di archivi in formati misti prima del caricamento in un motore di ricerca, l'allineamento di eventi provenienti da log applicativi, di sistema e del web server su un'unica linea temporale UTC durante l'analisi di un incidente, e la verifica che uno shipper marchi le righe nel formato atteso dal Suo collector.