Request Logging: Correlation ID ile Üretimde İz Sürmek
Request logging'de correlation id ve structured log neden kritik? Fastify, Express, pino ve AsyncLocalStorage örnekleriyle production hata ayıklama rehberi.
Bir isteğin birden fazla servisten geçtiği dağıtık sistemlerde, log satırlarını birbirine bağlayacak ortak bir kimlik olmadan production hatalarını izlemek pratik olarak imkansız hale gelir. Bu içerik, structured logging (her satırın sabit alanlara sahip bir JSON nesnesi olması) ile requestId veya traceId gibi bir correlation id'nin birlikte kullanılmasının neden log verisini sorgulanabilir kıldığını anlatıyor. Node.js ekosisteminde Fastify'ın pino'yu yerleşik olarak sunup otomatik req.id ürettiği, Express'te ise aynı işin pino-http middleware'i ile elle bağlanması gerektiği gösteriliyor.
Üçüncü ve genellikle en çok atlanan parça, bu id'nin asenkron işlemler ve downstream HTTP çağrıları boyunca taşınmasıdır. Node'un yerleşik AsyncLocalStorage modülü parametre geçirmeden context taşımayı sağlarken, W3C Trace Context (traceparent header) ve OpenTelemetry entegrasyonu bunu servisler arası standart bir şekilde otomatikleştiriyor. İçerik ayrıca üç yaygın production hatasını somut kod örnekleriyle ele alıyor: correlation id eksikliği yüzünden bir isteğin servisler arasında izlenememesi, unstructured (düz metin) logların aggregator araçlarında sorgulanamaması ve ham request body/header loglamanın Authorization, Cookie veya şifre gibi hassas verileri sızdırması. Son problem için pino'nun redact seçeneğiyle logger katmanında hassas alanların maskeleme yoluyla nasıl önlendiği gösteriliyor.
Mühendisler için pratik sonuç net: correlation id ve structured logging, bir hata anında 'bu istek hangi serviste, neden başarısız oldu' sorusuna dakikalar içinde cevap verebilmekle, saatlerce log arasında manuel arama yapmak arasındaki farkı yaratıyor.