Skip to content

Guide

Log ve JSON Yanıtlarında Zaman Damgası Okuma

On haneli sayılarla dolu bir log dosyası, henüz okuyamadığınız tarihlerle dolu bir log dosyasıdır.

By Published

Neredeyse herhangi bir sunucu logunu ya da ham bir JSON API yanıtını açtığınızda, er ya da geç sadece bir sayı olan bir alana rastlarsınız: 1732650000, ya da belki 1732650000000. Rakamların kendisinde bunun hangi tarih olduğunu, hatta hangi birime baktığınızı söyleyen hiçbir şey yok. Bu, hata ayıklamadaki en yaygın küçük sürtünmelerden biridir — tam da ihtiyacınız olan veriye bakıyorsunuz ama siz onu dönüştürene kadar okunmuyor. Bu rehber, tahmin yürütmeden bu sayıları hızlıca okumanın pratik bir anlatımıdır.

Hane sayısı hilesi

Modern bir logda veya API yanıtında göreceğiniz her Unix zaman damgası dört çözünürlükten birine girer ve kabaca 2001 ile 2286 arasındaki herhangi bir tarih için farklı hane sayılarına sahiptirler:

HaneBirimÖrnekKarşılığı
10Saniye17326500002024-11-26T21:00:00Z
13Milisaniye17326500000002024-11-26T21:00:00.000Z
16Mikrosaniye17326500000000002024-11-26T21:00:00.000000Z
19Nanosaniye17326500000000000002024-11-26T21:00:00.000000000Z

Her adım tam olarak üç hane ekler, çünkü her birim bir öncekinden 1000× daha incedir ve bu oran içinde bulunduğumuz çağın herhangi bir noktasında geçerlidir — hane saymak için gerçek tarihi bilmenize gerek yoktur, önce sayın sonra dönüştürün. Bu, zaman damgası dönüştürücümüzün otomatik olarak kullandığı aynı algılama yöntemidir, ama bir terminalde sadece bir logu gözden geçirdiğiniz anlar için gözle bilmeye değer.

Log dosyaları: aynı dosyada karışık birimlere dikkat edin

Tek bir log dosyası, birden fazla kaynaktan gelen çıktıyı topladığı için gerçekten farklı çözünürlükleri karıştırabilir. Bir ters proxy istek süresini saniye cinsinden loglarken, arkasındaki uygulama sunucusu milisaniye cinsinden loglayabilir; aynı toplu akışa yazan bir Node.js süreci (Date.now() geleneksel olarak milisaniyedir) ile bir Go servisinin (time.Now().Unix()geleneksel olarak saniyedir) tam olarak bu karışımı üretmesi kaçınılmazdır. Bunu sonradan düzeltmenin, her değeri kendi hane sayısına göre satır satır dönüştürmek dışında bir yolu yoktur — dosya genelinde tutarlılık varsaymak, logunuzun yarısını yanlış okumanın güvenilir bir yoludur.

Bir logdan analiz için bir zaman damgası sütunu çekiyorsanız — diyelim ki bir grepdeseniyle eşleşen her şeyi ya da bir log görüntüleyiciden dışa aktarılan bir sütunu — değerleri tek tek dönüştürmek yerine toplu girdi kabul eden bir dönüştürücüye tüm listeyi yapıştırın. Her satır bağımsız olarak algılanıp dönüştürülür, böylece aynı yapıştırmada karışık birimler sorun olmaz.

JSON API yanıtları: dize mi sayı mı, nasıl anlaşılır

Bir JSON gövdesi size bir değişken daha verir: zaman damgası alanının ham bir sayı mı yoksa biçimlendirilmiş bir dize mi olduğu. İkisi de yaygındır ve hiçbiri doğası gereği daha iyi değildir — sadece farklı tasarım tercihleridir, konuyu daha derinlemesine ele alan epoch ile ISO 8601 ile RFC 3339 rehberimize bakabilirsiniz. Pratikte:

"created_at": 1732650000ham bir epoch tamsayısıdır — yukarıdaki hane sayısı kontrolünü uygulayın. "created_at": "2024-11-26T21:00:00Z" zaten bir RFC 3339 dizesidir ve dönüşüm gerektirmeden olduğu gibi okunabilir. Bazı API'ler kafa karıştırıcı biçimde sayıyı dize olarak gönderir ("created_at": "1732650000") — bu, hane sayısı kuralına göre yine bir epoch değeridir, sadece tırnak içindedir; genellikle API yazarının 64 bitlik bir tamsayının yalnızca 53 bit güvenli sayılara sahip bir istemci dili tarafından (en yaygını JavaScript'in Numbertürü) sessizce kırpılmasını istememesinden kaynaklanır. İş akışınız yanıtı yeniden biçimlendirmeyi içeriyorsa — diyelim ki o alanı bir elektronik tabloya ya da farklı bir yapılandırılmış biçime çekmeyi — CSV ↔ JSON dönüştürücü yapısal dönüşümü halleder; zaman damgası değerlerini yine de sonrasında özel bir dönüştürücüden geçirmeniz gerekir.

Hızlı bir zihinsel kontrol listesi

Bir logda veya yanıt gövdesinde okunamayan bir zaman damgasına rastladığınızda: önce hane sayısını sayın (on, on üç, on altı veya on dokuz size birimi söyler); dize olarak mı yoksa çıplak bir sayı olarak mı tırnaklandığını kontrol edin, çünkü bu sadece onu nasıl çıkaracağınızı etkiler, anlamını değil; ve aynı dosya birimleri karıştırıyorsa, tüm dosya için tek bir çözünürlük varsaymak yerine satır satır dönüştürün. Bunların hiçbiri dönüşüm faktörlerini ezberlemeyi gerektirmez — birkaç düzine kez yaptıktan sonra edindiğiniz bir örüntü tanımadır ve aritmetiği her durumda bir dönüştürücü yapar.

Frequently asked questions

Bir log zaman damgasının saniye mi milisaniye mi olduğunu nasıl anlarım?
Tamsayı kısmının hane sayısını sayın. Kabaca on hane (2001'den 2286'ya kadar tarihleri kapsar) saniye demektir; on üç hane milisaniye; on altı hane mikrosaniye; on dokuz hane nanosaniye demektir. Bu işe yarar çünkü her birim bir öncekinden 1000 kat daha ince ve bu, modern çağın herhangi bir tarihinde tam olarak üç hane ekler.
Aynı dosyadaki farklı log satırları neden bazen farklı birimler kullanır?
Genellikle günlük, tek bir epoch çözünürlüğünde standartlaştırılmamış birden fazla servis veya kütüphaneden gelen çıktıyı topladığı için olur — milisaniye ile log tutan bir Java servisinin yanında saniye ile log tutan bir kabuk betiği klasik bir örnektir. Sonradan tutarlılığı zorlamanın güvenilir bir yolu yoktur; her satırı kendi hane sayısına göre dönüştürürsünüz.
Tüm bir log dosyasını bir zaman damgası dönüştürücüsüne yapıştırabilir miyim?
Her satırda bir ham epoch değeri olacak şekilde bir liste yapıştırabilir ve her birini bağımsız olarak dönüştürebilirsiniz — bir logdan veya veritabanı dökümünden çekilen bir zaman damgası sütununu gözle taramanın en hızlı yolu budur. Önce ham log metninden yalnızca sayısal zaman damgası sütununu çıkarmanız gerekir, örneğin hızlı bir grep veya elektronik tablo bölmesiyle.
Bir JSON API neden zaman damgasını bazen dize bazen sayı olarak gönderir?
Çünkü tek bir standart yoktur — bazı API'ler ham bir epoch tamsayısı yayınlar (kompakttır ama birimini bilmeniz gerekir), diğerleri bir RFC 3339 dizesi yayınlar (kendi kendini açıklar, bir yanıt gövdesinde gözle taraması kolaydır). İkisi de aynı anı temsil eder; hangisini alacağınız tamamen API tasarımcısının tercihidir ve (umarız) alanın şemasında belgelenmiştir.

Sources & references

Authoritative references cited by this piece. Verified by Buğra Sözeri on the dates shown and re-checked at every deploy.

Related

Published September 25, 2026