Correlation ID'yi HTTP isteğinden kuyruğa düşen job'lara kadar nasıl taşımalıyım?
Soru
Dağıtık bir sistemim var: bir istek Laravel API'ıma geliyor, orada bir iş SQS'e atılıyor, sonra Go ile yazdığım bir worker bu mesajı alıp işliyor. Sorun şu ki bir isteği uçtan uca izleyemiyorum — Laravel loglarındaki bir hata ile Go worker'daki bir hatayı birbirine bağlayacak ortak bir ipim yok. Bir correlation ID üretmek istiyorum ama nerede üreteceğimden, SQS'e nasıl taşıyacağımdan ve Go worker'da nasıl geri okuyup her log satırına ekleyeceğimden emin değilim. ID'yi mesajın gövdesine mi koymalıyım? Yoksa kendi header'ımı mı uydurmalıyım?
Cevap
Kısa cevap: Correlation ID’yi mesajın business gövdesine değil, taşıma metadata’sına (SQS message attribute) koyun ve geçtiği her sınırda context’e enjekte edin. Kendi header’ınızı uydurmayın — W3C traceparent kullanın ki ileride OpenTelemetry ile uçtan uca trace’e bedavaya bağlanasınız.
- Kaynağı tek yerde yakalayın. Laravel’de bir inbound middleware, gelen istekte
traceparentvar mı diye baksın; yoksa üretsin. Bu değeri hem request context’ine hem de logger’ın kalıcı context’ine koyun; artık o istekteki her log satırı ID taşır. - Payload’a değil attribute’a koyun. ID iş verisi değildir; SQS’e job’ı atarken
MessageAttributesiçine yazın. Böylece serileştirdiğiniz payload şeması bozulmaz ve worker mesaj gövdesini parse etmeden ID’yi okuyabilir. - Go worker’da yeniden hydrate edin. Mesajı alınca attribute’u bir carrier’a doldurup context’e extract edin, sonra logger’ı bu ID ile besleyin:
carrier := propagation.MapCarrier{}
for k, v := range msg.MessageAttributes {
carrier[k] = aws.ToString(v.StringValue)
}
ctx = otel.GetTextMapPropagator().Extract(ctx, carrier)
cid := trace.SpanContextFromContext(ctx).TraceID().String()
logger := slog.With("trace_id", cid)- Standart seçin: W3C Trace Context.
traceparentiki dilde de hazır kütüphanelerle parse edilir; kendi formatınızı uydurursanız her serviste yeniden yazmak zorunda kalır ve OTel ekosisteminden kopmuş olursunuz. - Log formatını hizalayın. Her iki tarafta da structured JSON log kullanın ve aynı alan adını (
trace_id) yazın. Alan adları tutmuyorsa OpenSearch/CloudWatch’ta tek sorguyla iki servisi birleştiremezsiniz. - Retry ve DLQ’da koruyun. Message attribute mesajla birlikte taşınır; job retry edilse ya da DLQ’ya düşse bile ID kaybolmaz — bu, en çok ihtiyaç duyacağınız anda (hata) ipin kopmamasını sağlar.
Sonuç: Ben olsam ID’yi baştan W3C traceparent olarak üretir, SQS message attribute’unda taşır, iki tarafta da OTel propagator ile inject/extract eder ve structured logger’a trace_id olarak enjekte ederdim. Böylece hem grep’lenebilir bir correlation ID’niz olur hem de aynı çizgide gerçek distributed tracing’e geçmeniz için ekstra iş kalmaz.
Yorumlar
Yorum yapmak için GitHub hesabınızla giriş yapmanız yeterli. Yorumlar GitHub Discussions üzerinde saklanır.