Unix-tidsstempler i logfiler — Sådan læser og debugger du dem
Når noget går galt i produktion klokken 2 om natten, er det første, du gør, at hente logfilerne. Og det første problem er ofte en væg af Unix-tidsstempler — 10-cifrede heltal, som fortæller præcis, hvornår hver begivenhed fandt sted, hvis du blot kunne læse dem. 1744070400 er præcist, utvetydigt og fuldstændig uforståeligt, indtil du konverterer det.
Unix Timestamp Converter omdanner ethvert råtidsstempel til en læsbar dato øjeblikkeligt. Denne artikel dækker, hvordan tidsstempler vises i logfiler, hvordan du konverterer og korrelerer dem effektivt, og hvor tidsstempel-relaterede fejl plejer at gemme sig under debugging.
Hvorfor logfiler bruger Unix-tidsstempler
Menneskeligt læsbare datostrenge — "7. april 2026 14:32:05 UTC+2" — er bekvemme at læse, men forfærdelige for maskiner. De varierer efter landeindstillinger, kræver tidszone-parsing, kan ikke sammenlignes direkte som heltal, og tager mere plads end et enkelt tal.
Unix-tidsstempler løser alle disse problemer. Et tidsstempel som 1744070400 er:
- Utvetydigt — ingen landeindstillinger, ingen formatvariation
- Tidszone-neutralt — altid baseret på UTC
- Sorterbart — større tal = senere tid, så
ORDER BY timestampfungerer korrekt - Aritmetik-venligt — træk to tidsstempler fra hinanden for at få forløbne sekunder
De fleste loggingssystemer (syslog, applikationslogfiler, databaselogfiler, CDN-adgangslogfiler) bruger som standard UTC Unix-tidsstempler af disse årsager. Læsbarheden ofres for præcision og portabilitet.
Sådan konverterer du et logfil-tidsstempel
Den hurtigste tilgang er at indsætte tidsstemplet i Unix Timestamp Converter. Det registrerer automatisk sekunder vs. millisekunder og viser UTC-datoen og -tiden med det samme.
For hurtige konverteringer uden at forlade terminalen:
Linux/Mac (bash): `bash date -d @1744070400 # Linux date -r 1744070400 # macOS `
Python: `python import datetime datetime.datetime.fromtimestamp(1744070400, tz=datetime.timezone.utc)
datetime(2026, 4, 7, 16, 0, tzinfo=timezone.utc)
**JavaScript (browserkonsolled eller Node):**new Date(1744070400 * 1000).toISOString() // "2026-04-07T16:00:00.000Z" `
Bemærk * 1000 i JavaScript — Date arbejder i millisekunder, så et sekund-baseret tidsstempel skal ganges, før det sendes til new Date(). At glemme dette er en almindelig årsag til "tidsstempel i år 2527"-fejl.
Læsning af millisekund-tidsstempler i logfiler
Nogle systemer logger i millisekunder i stedet for sekunder. Node.js-applikationer, Java-systemer med System.currentTimeMillis() og mange JavaScript-baserede backends producerer 13-cifrede tidsstempler som 1744070400000.
Unix Timestamp Converter registrerer formatet automatisk baseret på antallet af cifre. Men i terminalen:
# Konverter millisekunder til sekunder først, derefter konverter
echo $((1744070400000 / 1000)) | xargs date -d @ # LinuxEller i Python: `python datetime.datetime.fromtimestamp(1744070400000 / 1000, tz=datetime.timezone.utc) `
En hurtig kontroltjek: hvis tidsstemplet har 13 cifre, er det næsten helt sikkert millisekunder. 10 cifre betyder sekunder. 16 cifre betyder mikrosekunder (almindelig i PostgreSQL). 19 cifre betyder nanisekunder (nogle Java- og Rust-systemer).
Korrelation af tidsstempler på tværs af flere logkilder
En af de sværeste dele af debugging af distribuerede systemer er at korrelere begivenheder på tværs af flere tjenester, der logger uafhængigt. Hvis din webserverlogfil viser en 500-fejl på tidsstemplet 1744070412, og din databaselogfil viser en forbindelses-timeout på 1744070410, er disse to begivenheder 2 sekunder fra hinanden — helt klart beslægtede.
Uden Unix-tidsstempler er denne korrelation besværlig. Hvis webserveren logger i UTC+2 og databasen logger i UTC-5, kræver manuel justering af tiderne, at du kender offset'et og udfører mental aritmetik. Med Unix-tidsstempler er begge logfiler på samme skala, og du kan trække direkte.
Praktisk workflow: 1. Identificer det omtrentlige tidsinterval for hændelsen ud fra brugerrapporter eller overvågningsalter 2. Konverter tidsintervallet til Unix-tidsstempler (Unix Timestamp Converter eller date -d "2026-04-07 16:00:00 UTC" +%s) 3. Filtrer hver logfil til det tidsstempel-område: awk '$1 >= 1744070400 && $1 <= 1744070460' access.log 4. Sorter det kombinerede output efter tidsstempel for at bygge en samlet tidslinje
Trin 4 er, hvor Unix-tidsstempler virkelig gør deres gavn — du kan sort -n på tidsstempel-kolonnen på tværs af filer fra forskellige systemer og få en kronologisk nøjagtig samlet visning.
Almindelige tidsstempel-fejl at være opmærksom på under debugging
Sekunder/millisekunder-mismatch. Et tidsstempel gemt som millisekunder, men læst som sekunder, producerer en dato i år 2527 eller lignende. Et tidsstempel gemt som sekunder, men unødvendig ganget med 1000, producerer en dato i 1970. Begge er åbenlyse, når du konverterer værdien, hvilket er grunden til, at konvertering tidligt i debugging er værdifuldt.
Lokal tid i stedet for UTC. Hvis en logfil viser 1744077600, og du forventede 1744070400 for samme begivenhed, er forskellen 7200 sekunder — præcis 2 timer. Det er en tidszone-offset. Nogle systemer logger i lokal tid i stedet for UTC, hvilket bryder korrelation på tværs af systemer. Bekræft altid, hvilken tidszone et loggingssystem bruger, før du korrelerer poster.
Urskew mellem servere. Distribuerede systemer med usynchroniserede ure producerer logfiler, hvor tidsstedemplerne ikke afspejler den faktiske rækkefølge af begivenheder. Hvis server A viser en begivenhed på 1744070400 og server B viser en kausalt senere begivenhed på 1744070398, kører server B's ur 2 sekunder bagefter. NTP-synkronisering forebygger dette, men det vedligeholdes ikke altid perfekt. Når du debugger race conditions eller årsagssammenhænge i distribuerede systemer, er urskew værd at kontrollere.
Epoke gemt som streng. Nogle systemer logger tidsstempler som strengrepræsentationer af heltal: "1744070400". Dette ser identisk ud med heltal i mange logvisninger, men kan forårsage sorterings- eller sammenligningsfejl, hvis det ikke parses korrekt. JSON-logfiler serialiserer særligt nogle gange tal som strenge.
Forkortet tidsstempel. En logpost viser 174407040 (9 cifre) i stedet for 1744070400 (10 cifre) er blevet forkortet — sandsynligvis en formater- eller bufferoverskuld-fejl. Den 9-cifrede værdi konverteres til september 2025 i stedet for april 2026.
Filtrering af logfiler efter tidsinterval med Unix-tidsstempler
At kende tidsstedemplet-området for et tidsvindue gør logfilfiltrering præcis:
# Få Unix-tidsstemplet for et specifikt UTC-tidspunkt
date -d "2026-04-07 16:00:00 UTC" +%s # → 1744070400
date -d "2026-04-07 16:05:00 UTC" +%s # → 1744070700
# Filtrer nginx-adgangslogfil (første felt er tidsstempel)
awk '$1 >= 1744070400 && $1 <= 1744070700' /var/log/nginx/access.log
# Filtrer med grep, hvis tidsstempel er på kendt position
grep -E "^174407(04|05|06|07)" /var/log/app.logFor JSON-logfiler er jq mere læsbart: `bash cat app.log | jq 'select(.timestamp >= 1744070400 and .timestamp <= 1744070700)' `
Days Between Dates-værktøjet er nyttigt, når du skal kende tidsstedemplet-området for en hel dag eller flerdagersperiode — konverter start- og slutdatoerne til tidsstempler og brug disse som filtergrænser.
Opbyg mental intuition for tidsstempel-størrelser
Efter at have debugget et par hændelser med Unix-tidsstempler begynder du at udvikle intuition for størrelsesordnerne. Fra 2026:
- Nuværende tidsstempler ligger i intervallet 1,74–1,75 milliarder
- En time = 3.600 sekunder (4 cifre)
- En dag = 86.400 sekunder (5 cifre)
- En uge = 604.800 sekunder (6 cifre)
- Et år ≈ 31.557.600 sekunder (8 cifre)
Så hvis to logposter adskilles med 86 sekunder, ligger de ca. 1,5 minut fra hinanden. Hvis de adskilles med 3.600, præcis en time. Hvis de adskilles med 604.800, præcis en uge. Disse runde tal er værd at huske — de gør mental aritmetik på tidsstempler meget hurtigere under en aktiv incident.
For enhver konvertering, som ikke er i dit hoved, er Unix Timestamp Converter den hurtigste vej fra råt heltal til en læsbar dato og tilbage.
