Distributed Tracing'de Sampling: Detay Kaybı Riskine Değer mi?

Bir üretim ERP’sinde siparişin alınmasından sevkiyata kadar geçen tüm adımları izlemeye çalıştığımda, sistemin ne kadar çok mikroservisten geçtiğini ve her bir isteğin ne kadar çok işlem ürettiğini gördüm. Özellikle de yoğun dönemlerde, saniyede çok sayıda işlem dönerken, her bir isteğin tüm detaylarını saklamanın imkansız olduğunu anladım. İşte tam bu noktada distributed tracing’de sampling kavramı devreye giriyor. Peki, bu sampling gerçekten detay kaybı riskine değer mi? Benim tecrübelerime göre, kesinlikle değer ama doğru stratejilerle.

Yıllardır hem sistem yönetimi hem de kurumsal yazılım geliştirme tarafında operasyon yapıyorum. Bu süreçte, observability araçlarının ne kadar kritik olduğunu defalarca deneyimledim. Bir sorunu tespit etmek için loglara boğulmak yerine, tracing ile isteğin hangi serviste takıldığını görmek inanılmaz zaman kazandırıyor. Ancak bu kolaylığın bir bedeli var: veri hacmi. Bu yazıda, sampling’in neden bir zorunluluk olduğunu, farklı sampling yaklaşımlarını, detay kaybı risklerini ve bu riskleri nasıl yöneteceğimi kendi deneyimlerimle anlatacağım.

Sampling Neden Kaçınılmaz?

Distributed tracing, bir isteğin sisteminizdeki tüm servisler arasında nasıl ilerlediğini görselleştirmemizi sağlar. Her bir servis çağrısı, veritabanı işlemi veya harici API isteği bir “span” olarak kaydedilir ve bu span’ler bir “trace” oluşturur. Küçük bir sistemde bu sorun teşkil etmezken, bir üretim firmasının ERP’si veya büyük bir e-ticaret sitesi gibi kompleks ve yüksek hacimli sistemlerde durum hızla kontrolden çıkar.

Bir müşteri projesinde, yoğun bir dönemde yüksek istek hacmi gören bir mikroservis mimarisine sahiptik. Her bir işlemin onlarca span ürettiğini düşünürsek, kısa sürede milyonlarca span birikiyordu. Bu kadar veriyi depolamak ve işlemek için gerekli altyapı maliyeti (disk, CPU, network bandwidth) astronomik seviyelere ulaşıyordu. Veritabanı tarafında PostgreSQL kullanıyorduk ve bu kadar span’i indekslemek ve sorgulamak, ciddi WAL bloat ve replikasyon gecikmelerine neden oluyordu. Disk I/O’su sürekli tavan yapıyordu.

Ayrıca, her span’in toplanması ve gönderilmesi, uygulamanın kendisi üzerinde de bir performans yükü oluşturur. Ağ istekleri, serialization/deserialization işlemleri, işlemci ve bellek kullanımı her ne kadar optimize edilmiş olsa da, toplamda göz ardı edilemez bir overhead yaratır. Tracing’i %100 oranında açık bıraktığınızda, kritik bir API’nin yanıt süresinde belirgin bir artış görmek mümkündür ve bu da kullanıcı deneyimini doğrudan etkiler. Bu nedenle, tracing’i tamamen kapatmak ya da sampling yapmak dışında pek bir seçeneğimiz kalmıyor.

Temel Sampling Yaklaşımları ve Benim Tercihlerim

Sampling’in temel amacı, tüm veriyi kaydetmek yerine, anlamlı bir alt kümesini kaydetmek ve bu alt küme üzerinden genel sistem davranışı hakkında çıkarımlar yapmaktır. İki ana sampling yaklaşımı var: Head-based ve Tail-based sampling. Her birinin kendine göre avantajları ve dezavantajları bulunuyor.

Head-based Sampling

Head-based sampling, trace başlamadan hemen önce, yani “başında” bir kararın verildiği yöntemdir. En basit haliyle, gelen her isteğin rastgele bir kısmını (%X) kaydetmeye karar verirsiniz. Örneğin, her 1000 istekten 1’ini kaydetmek gibi.

# Örnek bir OpenTelemetry Python yapılandırması (pseudo-code)
from opentelemetry import trace
from opentelemetry.sdk.trace import TracerProvider
from opentelemetry.sdk.trace.export import ConsoleSpanExporter, SimpleSpanProcessor
from opentelemetry.sdk.trace.sampling import ParentBased, TraceIdRatioBased

# Her 1000 isteğin 1'ini örnekle
sampler = ParentBased(TraceIdRatioBased(0.001))

provider = TracerProvider(sampler=sampler)
trace.set_tracer_provider(provider)

Avantajları:

• Basitlik: Uygulaması ve yönetimi kolaydır.
• Düşük Overhead: Sadece örneklenen trace’ler için veri toplanır ve gönderilir. Bu da sistem üzerindeki yükü minimize eder.
• Gerçek Zamanlı: Karar en başta verildiği için, trace’ler anında işlenmeye başlar.

Dezavantajları:

• Kör Noktalar: Örneklenen trace’ler rastgele seçildiği için, nadir görülen hataları veya belirli bir koşul altında ortaya çıkan performans sorunlarını kaçırma ihtimali yüksektir. Bir üretim ERP’sinde, belirli bir ürün koduyla yapılan siparişlerde çıkan bir dead-lock’u, head-based sampling ile yakalamak çok zordu.
• Bağlam Kaybı: Bir trace’in önemli olup olmadığına, daha sistemin başındayken karar verildiği için, trace’in ilerleyen aşamalarında ortaya çıkan kritik bilgiler (hata, yavaşlama) bu kararı etkileyemez.

Ben genellikle head-based sampling’i, sistemin genel sağlığını ve ortalama performansını gözlemlemek için bir başlangıç noktası olarak kullanırım. Örneğin, %0.1’lik bir oranla başlayıp, sistemin genel seyrini izlerim. Ancak kritik bir sorun olduğunda, bu oran yetersiz kalabiliyor.

Tail-based Sampling

Tail-based sampling ise, bir trace’deki tüm span’ler toplandıktan sonra, yani “sonunda” örnekleme kararının verildiği yöntemdir. Bu yaklaşımda, tüm trace verisi geçici olarak bir yerde depolanır ve trace tamamlandıktan sonra, belirli kurallara göre (örneğin, hata içeren trace’ler, belirli bir sürenin üzerinde olan trace’ler) kaydedilip kaydedilmeyeceğine karar verilir.

Avantajları:

• Detaylı Bağlam: Trace’in tüm yaşam döngüsü boyunca oluşan olayları (hatalar, yavaşlamalar, belirli iş kuralları) dikkate alarak daha bilinçli bir örnekleme kararı verilebilir. Bu, özellikle kök neden analizi yaparken paha biçilmezdir.
• Hata Yakalama: Hata içeren tüm trace’leri otomatik olarak kaydetme imkanı sunar, bu da kritik sorunların gözden kaçmasını engeller.
• Performans Odaklı: Belirli bir eşiğin üzerindeki (örneğin, 500ms’den uzun süren) trace’leri kaydetme yeteneği, performans sorunlarını tespit etmek için çok etkilidir.

Dezavantajları:

• Yüksek Overhead: Tüm span’lerin geçici olarak depolanması ve işlenmesi gerektiği için, head-based sampling’e göre çok daha fazla sistem kaynağı (bellek, işlemci) tüketir. Bu, özellikle yüksek hacimli sistemlerde ciddi bir maliyet ve performans yükü oluşturabilir.
• Gecikme: Örnekleme kararı trace tamamlandıktan sonra verildiği için, trace verisinin observability platformuna ulaşmasında bir gecikme yaşanır. Gerçek zamanlı izleme gerektiren durumlarda bu bir sorun olabilir.
• Karmaşıklık: Kurulumu ve yönetimi head-based sampling’e göre daha karmaşıktır, genellikle özel bir “sampling collector” katmanı gerektirir.

Bir müşteri projesinde tail-based sampling’i denediğimizde, özellikle yoğun saatlerde collector servislerinin bellek kullanımının tavan yaptığını gördüm. Redis’teki OOM eviction policy seçimi gibi, burada da memory.high cgroup limitlerini ayarlamak zorunda kaldık. Bu yüzden, tail-based sampling’i genellikle daha kritik iş akışları veya belirli hata tipleri için kısıtlı bir şekilde kullanmayı tercih ederim.

Detay Kaybı Riskleri ve Karanlık Köşeler

Sampling’in en büyük dezavantajı, doğası gereği bilgi kaybına yol açmasıdır. Rastgele örnekleme yaptığınızda, nadir görülen olayları veya belirli bir kullanıcının yaşadığı benzersiz bir senaryoyu kaçırma riskiniz her zaman vardır. Bu durum, özellikle “selection bias” olarak bilinen bir sorunu beraberinde getirir. Örneğin, sisteminizin %99.9’u sorunsuz çalışırken, sadece %0.1’lik bir kesim çok spesifik bir hata alıyor olabilir. Head-based sampling ile bu %0.1’i yakalama ihtimaliniz, örnekleme oranınız ne kadar düşükse o kadar azalır.

Örneğin belirli bir API’ye gelen isteklerin çok küçük bir kesimi, çok nadir bir veritabanı kilitlenme durumuna neden olabilir. Head-based sampling ile bu kadar seyrek bir hatayı tespit etmek neredeyse imkansızdır. Bu tip “karanlık köşelerdeki” sorunları bulmak için ya sampling oranını çok yüksek tutmanız (ki bu maliyetli olur) ya da tail-based sampling ile hata içeren tüm trace’leri kaydetmeniz gerekir. Ancak tail-based sampling’in de kendi performans yükü var.

Kayıp detaylar, kök neden analizi yaparken bizi çıkmaza sokabilir. Bir kullanıcının şikayetini incelerken, o spesifik kullanıcının trace’ini bulamazsanız, sorunun nereden kaynaklandığını anlamak imkansız hale gelir. Bazen, bir sorunun nedenini bulmak için sadece hata veren trace’ler değil, hatadan hemen önceki sağlıklı trace’ler de önemlidir. Örneğin, bir önbellek temizleme işleminin, bir sonraki isteği nasıl etkilediğini görmek için her iki trace’e de ihtiyacınız olabilir. Sampling, bu tür bağlantılı olaylar arasındaki ilişkiyi de koparabilir. Bu yüzden, sampling stratejimi belirlerken bu riskleri her zaman göz önünde bulundururum.

Sampling Stratejilerini Optimizasyon Yöntemleri

Sampling’in detay kaybı risklerini minimize ederken, maliyet avantajlarından faydalanmak için çeşitli optimizasyon yöntemleri kullanıyorum. Bunlar genellikle Head-based ve Tail-based yaklaşımların hibrit kombinasyonları veya daha akıllıca karar verme mekanizmaları içerir.

1. Adaptive Sampling

Adaptive sampling, sistemin mevcut durumuna göre örnekleme oranını dinamik olarak ayarlayan bir yöntemdir. Örneğin, sistem normal çalışırken düşük bir oran (%0.1) kullanırken, hata oranları veya gecikme süreleri belirli bir eşiği aştığında örnekleme oranını artırır (%1 veya %10).

# Örnek bir OpenTelemetry Collector yapılandırması (pseudo-code)
# Bu kural, hata içeren trace'leri her zaman kaydeder,
# diğer trace'lerin %1'ini kaydeder.
processors:
  tail_sampling:
    policies:
      [
        {
          name: error-policy,
          type: status_code,
          status_codes: [ERROR],
          on_error: true,
          sampling_rate: 1.0 # Hata içerenleri %100 kaydet
        },
        {
          name: default-policy,
          type: probabilistic,
          sampling_percentage: 1 # Geri kalanların %1'ini kaydet
        }
      ]

Bu yaklaşım, hem normal zamanlarda maliyetleri düşürür hem de sorun anında ihtiyaç duyulan detayları yakalamayı sağlar. Kendi yan ürünümün backend’inde, bu stratejiyi Redis’teki hata oranlarını izleyerek uyguladım. Eğer Redis’ten OOM veya CONNECTION_REFUSED gibi hatalar gelmeye başlarsa, otomatik olarak tracing sampling oranını artıracak bir mekanizma kurdum.

2. Error-only ve Critical Path Sampling

Hata içeren tüm trace’leri kaydetmek, genellikle en önemli önceliktir. Hatalar, sistemde bir şeylerin yanlış gittiğinin en açık göstergesidir ve kök neden analizi için tam bağlama ihtiyaç duyulur. Bu nedenle, çoğu sampling stratejisi, hata içeren trace’leri her zaman kaydetmeyi hedefler.

Ayrıca, iş açısından kritik olan belirli API uç noktaları veya iş akışları için daha yüksek bir örnekleme oranı belirleyebilirim. Örneğin, “sipariş oluşturma” veya “ödeme işleme” gibi akışlar için %100 örnekleme yaparken, “kullanıcı profilini görüntüleme” gibi daha az kritik işlemler için %0.1 kullanabilirim. Bu, kaynakları en değerli bilgilere odaklamamı sağlar.

3. Distributed Context Propagation

Sampling kararı, trace’in başındaki ilk serviste verilse bile, bu kararın trace boyunca tüm diğer servislere doğru bir şekilde yayılması kritiktir. OpenTelemetry gibi standartlar, bu bağlam yayılımını (context propagation) sağlamak için HTTP başlıkları (örneğin traceparent) kullanır. Eğer bir trace örneklenmeye karar verildiyse, bu bilgi zincirdeki tüm servislere iletilir ve her servis o trace için span üretmeye devam eder. Aksi takdirde, trace’in bir kısmı eksik kalabilir.

Bu stratejileri bir araya getirerek, hem maliyetleri kontrol altında tutuyor hem de kritik anlarda gerekli observability’yi sağlıyorum. Beklenmedik bir OOM-killed durumu yaşandığında, adaptive sampling sayesinde hatanın ne zaman ve nerede oluştuğunu anında görebiliyorum. Bu tür hataları yakalamak, baştan bu mekanizmayı kurmanın asıl amacıdır.

Gerçek Dünya Uygulamaları ve Elde Ettiklerim

Distributed tracing ve akıllı sampling stratejilerini farklı projelerde uyguladım ve sonuçlarını bizzat gözlemledim. Kendi yan ürünümün backend’inde, bir üretim ERP’sinde ve çeşitli müşteri projelerinde bu yaklaşımlar, hem operasyonel verimliliği artırdı hem de maliyetleri önemli ölçüde düşürdü.

Bir üretim ERP’sinde, yeni bir üretim planlama modülü devreye alındığında, AI ile optimize edilmiş planlama algoritmalarının performansını izlemek kritikti. Başlangıçta %100 tracing ile başladık ama sistemdeki yük arttıkça, observability platformuna gönderilen veri hacmi ve buna bağlı maliyet sürdürülemez seviyelere ulaştı. Adaptive sampling stratejisine geçerek, sadece hata içeren veya belirli bir eşiğin üzerinde süren planlama isteklerini %100 kaydederken, diğer başarılı ve hızlı istekleri çok düşük bir oranda örnekledik. Bu geçişle birlikte, veri hacmi ve maliyet kabaca bir mertebe küçüldü. En önemlisi, önemli bir detay kaybı yaşamadan, kritik performans sorunlarını veya algoritmik hataları tespit etmeye devam ettik.

Bu tablo, sampling’in sadece bir teorik kavram olmadığını, somut finansal ve operasyonel faydalar sağladığını gösteriyor. Elbette, az da olsa bir hata tespit oranı kaybı göz ardı edilemez, ancak bu kayıp genellikle tekrarlanabilir ve daha az kritik hatalardan kaynaklanıyordu. Önemli olan, işi etkileyen veya sistemsel kararlılığı bozan büyük sorunları hala yakalayabiliyor olmamızdı.

Benim felsefem, “olur o kadar” yaklaşımıyla, mükemmeliyetçilik yerine pragmatik çözümlere odaklanmaktır. %100 izleme sağlamak her zaman ideal gibi görünse de, gerçek dünya maliyetleri ve karmaşıklığı göz önüne alındığında, bu genellikle sürdürülebilir değildir. Önemli olan, sisteminiz hakkında yeterli bilgiye sahip olmak için doğru dengeyi bulmaktır. Bu dengeyi, sürekli olarak metrikleri izleyerek (örneğin, toplanan span sayısı, hata içeren trace yüzdesi, ortalama trace süresi) ve sampling oranlarını ayarlayarak sağlıyorum.

Sonuç: Risk mi, Gereklilik mi?

Distributed tracing’de sampling, bir risk barındırır: Detay kaybı. Ancak tecrübem gösteriyor ki, bu risk doğru stratejilerle yönetilebilir ve günümüzün kompleks, yüksek hacimli sistemlerinde bir zorunluluktur. Sampling olmadan, çoğu kuruluş observability’nin maliyet yükü altında ezilir ve ya tracing’i tamamen kapatmak zorunda kalır ya da anlamsız bir veri yığını içinde boğulur.

Benim net pozisyonum: Sampling bir gerekliliktir, ancak akıllıca uygulanmalıdır. Head-based ve tail-based yaklaşımları birleştirerek, adaptive sampling kullanarak ve kritik iş akışlarına öncelik vererek, hem maliyetleri kontrol altında tutabilir hem de operasyonel görünürlüğünüzü koruyabilirsiniz. Önemli olan, “ne kaybediyorum?” sorusunu sormak ve bu kaybın işinize etkisini ölçmektir. Eğer kaybettiğiniz detaylar, sisteminizin genel sağlığı ve kritik iş akışları için hayati değilse, sampling kesinlikle değecektir.

Unutmayın, observability bir lüks değil, modern sistemlerin vazgeçilmez bir parçasıdır. Ve sampling, bu vazgeçilmez aracı, sürdürülebilir ve ekonomik hale getiren anahtardır. Bir sonraki yazımda, bu tür observability verilerini nasıl daha verimli bir şekilde depolayıp sorgulayabileceğimizden bahsedeceğim.