OpenTelemetry Sampling ile Bütçeden Tasarruf: Kapsamlı Rehber

Modern yazılım dünyasında, uygulamaların performansı ve sağlığı hakkında derinlemesine bilgi sahibi olmak hayati önem taşır. Ancak tüm telemetri verilerini toplamak ve analiz etmek, özellikle büyük ölçekli sistemlerde, ciddi maliyetler yaratabilir. Bu kapsamlı rehber, OpenTelemetry sampling stratejilerini kullanarak observability maliyetlerinden nasıl tasarruf edeceğinizi detaylıca açıklayacaktır.

Mikroservis mimarileri, bulut tabanlı çözümler ve dağıtık sistemler giderek daha karmaşık hale geldikçe, bu sistemlerin gözlemlenebilirliğini (observability) sağlamak, uygulama performansını artırmak ve sorunları hızlıca gidermek için kritik bir ihtiyaç haline gelmiştir. Observability, loglar, metrikler ve izlemeler (traces) gibi üç temel bileşenle sağlanır. Ancak bu verilerin üretimi, transferi, depolanması ve analizi, yüksek hacimli ortamlarda beklenmedik bütçe aşımına yol açabilir. Özellikle izleme verileri, her bir isteğin yaşam döngüsünü baştan sona kaydederek çok detaylı bilgiler sunduğu için, en büyük maliyet kalemlerinden biri haline gelme potansiyeline sahiptir. Peki, bu değerli bilgiyi toplarken cüzdanımızı nasıl koruyabiliriz? İşte bu noktada OpenTelemetry sampling devreye giriyor.

OpenTelemetry, telemetri verisi toplama ve dışa aktarma konusunda standartlaşmış, satıcıdan bağımsız bir çerçeve sunar. Bu standartlar sayesinde, uygulamalarınızdan log, metrik ve izleme verilerini kolayca toplayabilir ve çeşitli observability platformlarına gönderebilirsiniz. Ancak OpenTelemetry’nin sağladığı en güçlü araçlardan biri de sampling yani örnekleme yeteneğidir. Sampling, tüm izleme verilerini toplamak yerine, belirli kriterlere göre yalnızca en alakalı veya en önemli izlemeleri seçme sürecidir. Bu yaklaşım, hem depolama hem de işleme maliyetlerini önemli ölçüde düşürürken, yine de sisteminizin sağlığı hakkında yeterli içgörüyü elde etmenizi sağlar. Bu makalede, OpenTelemetry sampling’in temel prensiplerinden, farklı türlerine, pratik uygulama örneklerine ve gerçek dünya senaryolarındaki kullanımına kadar her şeyi ele alacağız. Hedefimiz, hem bütçenizden tasarruf etmenize yardımcı olmak hem de observability stratejinizi daha akıllı hale getirmektir.

OpenTelemetry ve İzlemenin Temelleri Nelerdir?

OpenTelemetry, dağıtık sistemlerde telemetri verisi (metrikler, loglar ve izlemeler) toplamak için açık kaynaklı bir standartlar ve araçlar koleksiyonudur. Temel amacı, çeşitli programlama dillerinde ve altyapılarda çalışabilen, satıcıdan bağımsız bir çerçeve sunarak geliştiricilerin observability çözümlerini entegre etmesini kolaylaştırmaktır. Bir uygulama geliştirdiğinizde, performansını, hatalarını ve genel sağlığını anlamak için sürekli olarak izlemeniz gerekir. İşte bu noktada OpenTelemetry, bu izleme verilerini standart bir formatta toplamanıza ve istediğiniz analiz aracına göndermenize olanak tanır. Gerçekten de, OpenTelemetry’nin arkasındaki itici güç, farklı APM (Uygulama Performans Yönetimi) veya observability araçları arasında geçiş yaparken yeniden kodlama veya özel entegrasyonlar geliştirme ihtiyacını ortadan kaldırmaktır. Bu sayede, geliştiriciler ana iş mantığına odaklanabilirken, operasyon ekipleri de daha tutarlı ve zengin telemetri verilerine erişebilir.

İzleme (Tracing), OpenTelemetry’nin en güçlü bileşenlerinden biridir ve özellikle dağıtık sistemlerde bir isteğin birden fazla hizmet üzerinden nasıl geçtiğini görselleştirmek için kullanılır. Her bir isteğin yaşam döngüsü, bir “trace” olarak adlandırılır ve bu trace, isteğin başlangıcından bitişine kadar yaptığı her işlemi temsil eden bir dizi “span”dan oluşur. Örneğin, bir web uygulamasında kullanıcı bir düğmeye tıkladığında, bu istek önce bir ön uç servisine, ardından bir arka uç API’sine ve oradan da bir veritabanına veya başka mikroservislere gidebilir. Her bir hizmetteki her bir işlem (veritabanı sorgusu, API çağrısı vb.) bir span olarak kaydedilir. Bu span’ler, trace ID’si ile birbirine bağlanır ve hiyerarşik bir yapı oluşturarak isteğin hangi aşamalarda ne kadar zaman geçirdiğini, hangi hataların oluştuğunu ve genel olarak performans darboğazlarının nerede olduğunu anlamamızı sağlar. İzleme verisi, karmaşık sistemlerde hata ayıklama ve performans optimizasyonu için paha biçilmez bir kaynaktır.

Ancak bu kadar detaylı bilgi toplamanın bir bedeli vardır. Özellikle yüksek trafikli uygulamalarda her bir isteğin her bir span’ini kaydetmek, muazzam miktarda veri üretimine yol açar. Bu veri hacmi, depolama alanını hızla tüketir, veri transferi maliyetlerini artırır ve analiz platformlarında yüksek işlem gücü gerektirir. Sonuç olarak, observability için ayrılan bütçe kolayca kontrol dışına çıkabilir. İşte tam da bu nedenle OpenTelemetry, bu veri yükünü yönetmek ve maliyetleri optimize etmek için güçlü sampling (örnekleme) stratejileri sunar. Sampling, sisteminizin genel sağlığı hakkında yeterli içgörü sağlamakla birlikte, gereksiz veya düşük değerli verilerin kaydedilmesini önleyerek kaynak tüketimini azaltır. Bir sonraki bölümde, neden sampling yapmamız gerektiğini ve hangi durumlarda kritik bir araç haline geldiğini daha yakından inceleyeceğiz.

Veri Yükünü Azaltmak İçin Neden Sampling Yapmalıyız?

Observability, modern uygulama geliştirmenin temel taşlarından biri olsa da, beraberinde önemli bir maliyet yükü getirir. Özellikle izleme (tracing) verileri, sisteminizdeki her bir isteğin her adımını detaylı bir şekilde kaydettiği için, yüksek trafikli uygulamalarda hızla petabaytlarca veriye ulaşabilir. Bu durum, veri depolama, transfer ve işleme maliyetlerini katlayarak artırır. AWS CloudWatch, Datadog, New Relic gibi popüler observability platformlarının çoğu, topladıkları veri hacmine göre ücretlendirme yapar. Dolayısıyla, ne kadar çok veri gönderirseniz, o kadar çok ödersiniz. Veri yükünü azaltmak, doğrudan bütçenizden tasarruf etmek anlamına gelir ve bu noktada sampling, vazgeçilmez bir strateji haline gelir.

Sampling’in temel amacı, tüm veriyi kaydetmek yerine, sisteminiz hakkında anlamlı içgörüler sunacak temsili bir veri kümesi oluşturmaktır. Diyelim ki saniyede binlerce istek alan bir e-ticaret siteniz var. Her bir isteğin her bir veritabanı sorgusunu, her bir API çağrısını kaydetmek teorik olarak mükemmel görünse de, pratik olarak çoğu zaman aşırıya kaçmaktır. Normal çalışan isteklerin büyük bir çoğunluğu birbirine benzer ve her birini kaydetmek, veri yığınında tekrara neden olur. Ancak, yavaş çalışan istekler, hata veren istekler veya belirli iş akışlarını temsil eden istekler, sistemin sağlığı hakkında çok daha değerli bilgiler sunar. Sampling ile tam da bu değerli izlemeleri yakalamayı hedefleriz.

Ayrıca, yüksek veri hacmi sadece maliyetleri artırmakla kalmaz, aynı zamanda analiz sürecini de zorlaştırır. Çok fazla veri olduğunda, önemli anomalileri veya performans darboğazlarını tespit etmek, “gürültü” içinde “sinyal” aramak gibi bir hal alabilir. Sampling, bu gürültüyü azaltarak, analistlerin ve geliştiricilerin daha hızlı ve etkili bir şekilde sorunları bulmalarına yardımcı olur. Daha az veriyle çalışmak, sorgu sürelerini kısaltır, görselleştirme panolarının daha hızlı yüklenmesini sağlar ve genel olarak observability araçlarının kullanılabilirliğini artırır. Böylece, hem maliyetlerden tasarruf eder hem de elde ettiğiniz içgörünün kalitesini yükseltirsiniz.

Son olarak, sampling sadece finansal bir avantaj sağlamakla kalmaz, aynı zamanda güvenlik ve uyumluluk konularında da faydalı olabilir. Bazı hassas verilerin izleme kapsamında kaydedilmesini istemeyebilirsiniz. Sampling stratejileri ile belirli kriterlere uyan izlemeleri tamamen dışarıda bırakarak bu tür riskleri de azaltabilirsiniz. Özetle, sampling, veri toplama ve analizi arasında akıllı bir denge kurarak, hem bütçe dostu hem de etkili bir observability stratejisi oluşturmanın anahtarıdır. Bu sayede, uygulamanızın kritik operasyonel bilgilerini kaybetmeden, veri yükünü ve dolayısıyla maliyetleri makul seviyelere çekebilirsiniz.

OpenTelemetry’de Hangi Sampling Stratejilerini Kullanabiliriz?

OpenTelemetry, telemetri verisi toplarken hangi izlemelerin (traces) saklanacağına ve hangilerinin atılacağına karar vermek için çeşitli örnekleme (sampling) stratejileri sunar. Bu stratejiler, farklı kullanım durumlarına ve maliyet/görünürlük dengesi ihtiyaçlarına göre tasarlanmıştır. Doğru sampling stratejisini seçmek, hem bütçenizden tasarruf etmenizi hem de uygulamalarınızın performansı ve sağlığı hakkında yeterli içgörüyü korumanızı sağlar. İşte OpenTelemetry’de sıkça kullanılan sampling stratejileri ve bunların temel prensipleri:

1. AlwaysOnSampler:
   • Açıklama: Adından da anlaşılacağı gibi, bu örnekleyici tüm izlemeleri kaydeder. Hiçbir izleme atılmaz.
   • Kullanım Senaryosu: Genellikle geliştirme ortamlarında veya çok düşük trafikli, kritik uygulamalarda kullanılır. Tam detaylandırma gerektiğinde tercih edilir.
   • Maliyet Etkisi: En yüksek maliyetli stratejidir çünkü tüm veriyi toplar.
2. AlwaysOffSampler:
   • Açıklama: Bu örnekleyici hiçbir izlemeyi kaydetmez. Tüm izlemeler atılır.
   • Kullanım Senaryosu: Genellikle test ortamlarında veya izlemenin kesinlikle istenmediği durumlarda kullanılır.
   • Maliyet Etkisi: En düşük maliyetlidir ancak hiçbir observability sağlamaz.
3. TraceIdRatioBasedSampler:
   • Açıklama: Bu örnekleyici, bir izlemenin Trace ID’sine dayanarak belirli bir orana (örneğin 0.1 için %10) göre izlemeleri rastgele seçer. Karar, izlemenin başlangıcında verilir.
   • Kullanım Senaryosu: En yaygın kullanılan örnekleyicilerden biridir. Yüksek trafikli uygulamalarda maliyetleri düşürmek ve temsili bir veri kümesi elde etmek için idealdir.
   • Maliyet Etkisi: Ayarlanan orana göre maliyetleri doğrusal olarak düşürür. Örneğin, %10’luk bir oran, maliyetleri yaklaşık %90 azaltır.
4. ParentBased Sampler:
   • Açıklama: Bu örnekleyici, mevcut izlemenin üst (parent) span’inin örnekleme kararını miras alır. Eğer bir üst span varsa ve o span örneklenmişse, mevcut span de örneklenir. Eğer yoksa (yani yeni bir trace başlıyorsa), bir yedek örnekleyici (fallback sampler) kullanılır. Genellikle TraceIdRatioBasedSampler ile birlikte kullanılır.
   • Kullanım Senaryosu: Dağıtık sistemlerde izlemelerin bütünlüğünü korumak için önemlidir. Bir trace’in başlangıcında verilen örnekleme kararının tüm trace boyunca geçerli olmasını sağlar.
   • Maliyet Etkisi: Yedek örnekleyicinin maliyet etkisine benzer, ancak trace bütünlüğünü koruduğu için daha tutarlı veri sağlar.
5. RateLimitingSampler:
   • Açıklama: Bu örnekleyici, belirli bir saniyede örneklenen izleme sayısını sınırlar. Örneğin, saniyede en fazla 100 trace örneklenebilir.
   • Kullanım Senaryosu: Ani trafik artışlarında veya DoS saldırıları gibi durumlarda maliyetlerin kontrol dışına çıkmasını önlemek için bir güvenlik ağı sağlar.
   • Maliyet Etkisi: Maksimum bir maliyet sınırı belirlemenizi sağlar.

Bu stratejilerin ötesinde, OpenTelemetry’de iki ana örnekleme yaklaşımı vardır: Head Sampling ve Tail Sampling. Bu yaklaşımlar, örnekleme kararının ne zaman verildiğine göre ayrılır ve her birinin kendine özgü avantajları ve dezavantajları bulunur.

• Head Sampling (Ön-Örnekleme):
  • Açıklama: Örnekleme kararı, bir izlemenin başlangıcında (trace’in ilk span’i oluşturulduğunda) verilir. Bu, uygulamanın kendisi veya ilk hizmet tarafından yapılır.
  • Avantajları: Uygulama düzeyinde basitlik, kaynak tüketiminin erken azaltılması, toplayıcı (collector) üzerindeki yükün hafifletilmesi.
  • Dezavantajları: İzleme hakkında henüz yeterli bilgi olmadığından (hata durumu, süre gibi), akıllı kararlar vermek zordur. Önemli izlemeler atlanabilir.
  • Örnek Sampler’lar: AlwaysOnSampler, AlwaysOffSampler, TraceIdRatioBasedSampler, ParentBasedSampler.
• Tail Sampling (Son-Örnekleme):
  • Açıklama: Örnekleme kararı, bir izleme tamamlandıktan sonra, genellikle bir OpenTelemetry Collector veya ara bir servis tarafından verilir. Bu, tüm span’lerin toplanıp analiz edildikten sonra en anlamlı olanların seçilmesine olanak tanır.
  • Avantajları: Daha akıllı örnekleme kararları (örneğin, hata içeren tüm izlemeleri kaydet, belirli bir süreden uzun süren izlemeleri kaydet, belirli bir kullanıcı grubuna ait izlemeleri kaydet). Bu sayede, sorunlu izlemelerin kaçırılma olasılığı azalır.
  • Dezavantajları: Tüm izleme verisinin bir ara noktada (collector) toplanması ve geçici olarak depolanması gerektiğinden, daha fazla kaynak (CPU, bellek) gerektirir. Daha yüksek gecikme (latency) söz konusu olabilir.
  • Örnek Sampler’lar: Genellikle OpenTelemetry Collector içinde özel işlemciler (processors) kullanılarak uygulanır.

Bu farklı sampling stratejilerini ve yaklaşımlarını anlamak, uygulamanızın ihtiyaçlarına en uygun dengeyi bulmanıza yardımcı olacaktır. Genellikle, head sampling, geniş bir görünürlük sağlamak ve maliyetleri düşürmek için bir başlangıç noktası olarak kullanılırken, tail sampling, daha hedeflenmiş ve akıllı izleme için tercih edilir. Her iki yaklaşımın da kendi güçlü yönleri ve kullanım alanları vardır ve çoğu zaman, en iyi sonuçlar için bu stratejilerin bir kombinasyonu kullanılır.

Head Sampling ile Maliyetleri Nasıl Kontrol Altına Alırız?

Head sampling, OpenTelemetry’deki en basit ve doğrudan maliyet azaltma stratejilerinden biridir. Temel prensibi, bir izlemenin (trace) daha en başta, yani uygulamanın kendisinde veya ilk hizmete ulaştığı anda örneklenip örneklenmeyeceğine karar vermektir. Bu karar, Trace ID gibi önceden bilinen bilgilere veya basit bir orana dayanır. Bu yaklaşım, gereksiz verilerin sisteminize girmesini ve işlenmesini engelleyerek önemli ölçüde kaynak tasarrufu sağlar.

Head sampling’in en büyük avantajı, veri yükünü erken aşamada azaltmasıdır. Bir trace, ilk span’i oluşturulduğunda örneklenmemeye karar verilirse, bu trace’e ait sonraki hiçbir span oluşturulmaz, toplanmaz veya dışa aktarılmaz. Bu, hem uygulamanın kendisindeki işlem yükünü (span oluşturma, bağlam yayma) hem de OpenTelemetry Collector’lara ve son olarak da arka uç observability platformlarına gönderilen veri hacmini doğrudan azaltır. Özellikle yüksek trafikli uygulamalarda, bu durum bant genişliği, depolama ve işleme maliyetlerinde dramatik düşüşler sağlayabilir. Örneğin, bir web uygulamasının milyarlarca isteği işlediği bir senaryoda, %1’lik bir örnekleme oranıyla çalışmak, veri hacmini %99 oranında azaltır ve bu da doğrudan bütçenizde büyük bir fark yaratır.

Uygulama Örneği: Python ile TraceIdRatioBasedSampler

Head sampling genellikle uygulamanızın OpenTelemetry SDK’sında yapılandırılır. En sık kullanılan head sampling stratejilerinden biri TraceIdRatioBasedSampler‘dır. Bu örnekleyici, bir izlemenin Trace ID’sini kullanarak belirli bir orana göre örnekleme yapar. Aşağıda, Python’da bu örnekleyicinin nasıl yapılandırılacağına dair bir örnek verilmiştir:

from opentelemetry import trace
from opentelemetry.sdk.resources import Resource
from opentelemetry.sdk.trace import TracerProvider
from opentelemetry.sdk.trace.export import ConsoleSpanExporter, SimpleSpanProcessor
from opentelemetry.sdk.trace.sampling import TraceIdRatioBasedSampler

# Kaynak (Resource) bilgilerini tanımla
resource = Resource.create({
    "service.name": "my-python-app",
    "application.version": "1.0.0"
})

# TraceIdRatioBasedSampler ile örnekleme oranını belirle (örn: %10)
# Eğer 0.1 olarak ayarlanırsa, 10 trace'ten yaklaşık 1'i örneklenir.
sampler = TraceIdRatioBasedSampler(0.1)

# TracerProvider'ı başlat ve sampler'ı ata
provider = TracerProvider(
    resource=resource,
    sampler=sampler
)
trace.set_tracer_provider(provider)

# Span işlemcisini ve dışa aktarıcıyı ayarla (örneğin konsola yazdırma)
span_processor = SimpleSpanProcessor(ConsoleSpanExporter())
provider.add_span_processor(span_processor)

# Tracer'ı al
tracer = trace.get_tracer("my-app-tracer")

def my_function():
    with tracer.start_as_current_span("my_function_span"):
        print("Hello from my_function!")
        # İşlemler...

if __name__ == "__main__":
    for i in range(20):
        print(f"İstek {i+1} başlatılıyor...")
        my_function()
        print(f"İstek {i+1} tamamlandı.")

# Örnek: console.log("Modern Kod Örneği");

Bu kod bloğunda, TraceIdRatioBasedSampler(0.1) ile örnekleme oranı %10 olarak ayarlanmıştır. Bu, her 10 izlemeden yaklaşık birinin OpenTelemetry tarafından toplanacağı ve dışa aktarılacağı anlamına gelir. Geri kalan %90'lık kısım ise daha başlangıçta atılacak, bu da hem işlem gücünden hem de bant genişliğinden tasarruf sağlayacaktır.

Head sampling'in dezavantajı, örnekleme kararının izlemenin başlarında verilmesidir. Bu aşamada, izlemenin sonunda bir hata oluşup oluşmayacağını veya ne kadar süreceğini bilemeyiz. Dolayısıyla, kritik bir hata içeren veya aşırı yavaş çalışan bir izlemenin, rastgele örnekleme sonucu atılma riski bulunur. Bu durum, özellikle "canary" dağıtımlar veya yeni özelliklerin test edildiği senaryolarda sorun yaratabilir. Ancak, genel sistem sağlığını izlemek ve temel performans metriklerini toplamak için head sampling oldukça etkilidir. Kritik veya akıllı örnekleme kararlarının gerekli olduğu durumlar için ise tail sampling gibi daha sofistike yaklaşımlara ihtiyaç duyarız.

Tail Sampling ile Daha Kapsamlı ve Akıllı İzleme Nasıl Yapılır?

Head sampling, maliyetleri etkin bir şekilde azaltır, ancak izlemenin başlarında karar verildiği için, sonunda oluşabilecek kritik hataları veya performans sorunlarını gözden kaçırma riski taşır. İşte bu noktada tail sampling (son örnekleme) devreye girer. Tail sampling, örnekleme kararını izleme tamamlandıktan sonra, yani tüm span'ler toplandıktan sonra veren daha akıllı bir stratejidir. Bu sayede, izlemenin tüm içeriği değerlendirilerek daha bilinçli bir karar verilebilir ve en değerli izlemelerin kaçırılma olasılığı minimuma iner.

Tail sampling genellikle OpenTelemetry Collector gibi ara bir bileşen üzerinde uygulanır. Uygulamanız, tüm izleme verilerini (örnekleme yapmadan veya sadece çok temel head sampling ile) OpenTelemetry Collector'a gönderir. Collector, gelen tüm span'leri geçici olarak bellekte veya diskte depolar ve bir izleme tamamlandığında (yani tüm beklenen span'ler geldiğinde veya belirli bir zaman aşımı süresi geçtiğinde), bu izlemenin tamamını analiz eder. Bu analiz sonucunda, belirli kriterlere göre izlemenin saklanıp saklanmayacağına karar verilir. Bu kriterler şunlar olabilir:

• Hata içeren tüm izlemeleri kaydet.
• Belirli bir süreden (örneğin 5 saniye) daha uzun süren tüm izlemeleri kaydet.
• Belirli bir kullanıcı ID'si veya işlem tipi içeren izlemeleri kaydet.
• Belirli bir HTTP durum koduyla (örneğin 5xx hataları) biten izlemeleri kaydet.

Bu akıllı kararlar sayesinde, "ihtiyaç duyduğunuz" veriyi daha yüksek bir güvenilirlikle toplarken, "gereksiz" veriyi atmış olursunuz. Tail sampling'in en önemli avantajı, problem çözme ve hata ayıklama süreçlerinde kritik olan izlemeleri kaçırmama yeteneğidir. Performans düşüşleri veya hata durumları gibi anormallikler ortaya çıktığında, bu izlemelerin tamamının elimizde olması, kök neden analizi için paha biçilmezdir.

Uygulama Örneği: OpenTelemetry Collector ile Tail Sampling

Tail sampling'i uygulamak için, OpenTelemetry Collector'ın yapılandırmasına bir tail_sampling işlemcisi eklemeniz gerekir. Aşağıda, örnek bir OpenTelemetry Collector yapılandırması bulunmaktadır:

receivers:
  otlp:
    protocols:
      grpc:
      http:

processors:
  batch:
    send_batch_size: 1000
    timeout: 10s
  tail_sampling:
    # Belirli bir izleme için tüm span'lerin gelmesini bekleyeceğimiz maksimum süre
    decision_wait: 10s
    # Aynı anda işlenecek maksimum trace sayısı
    num_traces: 100000
    # Örnekleme politikaları
    policies:
      - name: always-sample-errors
        type: status_code
        status_code: [ ERROR ]
      - name: sample-slow-traces
        type: latency
        latency: 5s # 5 saniyeden uzun süren tüm izlemeleri örnekle
      - name: default-sampling-ratio
        type: probabilistic
        sampling_percentage: 1 # %1 ihtimalle rastgele örnekle (hatasız ve yavaş olmayanlar için)

exporters:
  otlp:
    endpoint: "your-apm-provider-endpoint:4317"
    headers:
      "api-key": "YOUR_API_KEY"

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [batch, tail_sampling]
      exporters: [otlp]

Bu yapılandırmada:

• decision_wait: Collector'ın bir izleme için tüm span'lerin gelmesini bekleyeceği süreyi belirtir. Bu süre dolduğunda, örnekleme kararı verilir.
• num_traces: Bellekte tutulacak maksimum izleme sayısını belirler.
• policies: Örnekleme kararı vermek için kullanılan kuralları tanımlar.
  • always-sample-errors: Hata (ERROR) içeren tüm izlemelerin örneklenmesini sağlar.
  • sample-slow-traces: 5 saniyeden uzun süren tüm izlemelerin örneklenmesini sağlar.
  • default-sampling-ratio: Yukarıdaki koşulları sağlamayan izlemeler için %1'lik bir olasılıkla rastgele örnekleme yapar.

Vaka Analizi: E-ticaret Sitesi Örneği

Bir e-ticaret sitesi, Black Friday gibi yüksek trafik dönemlerinde performans sorunları yaşıyor ancak bu sorunların kök nedenlerini bulmakta zorlanıyordu. Başlangıçta tüm izlemeleri kaydediyorlardı, ancak bu durum APM maliyetlerini kontrol edilemez hale getirmişti. Head sampling uyguladıklarında ise, rastgele atılan izlemeler arasında kritik yavaşlama veya hata durumlarının bulunmasından endişeleniyorlardı.

Çözüm olarak tail sampling'e geçtiler. OpenTelemetry Collector'larını aşağıdaki politikalarla yapılandırdılar:

• Kritik ödeme adımlarında oluşan tüm hataları kaydedin.
• Sepete ekleme, ödeme ve sipariş tamamlama gibi kritik iş akışlarında 2 saniyeden uzun süren tüm izlemeleri kaydedin.
• Diğer tüm izlemeler için %0.5'lik bir olasılıkla rastgele örnekleme yapın.

Bu strateji sayesinde, e-ticaret sitesi normal işleyişteki rutin izlemelerin büyük çoğunluğunu atmayı başarırken, kritik iş akışlarındaki performans sorunları ve hataların %100'ünü yakalayabildi. Sonuç olarak, observability maliyetlerini %70 oranında azalttılar ve eş zamanlı olarak sorun giderme sürelerini %40 kısalttılar çünkü artık sadece gerçekten önemli olan verilere odaklanabiliyorlardı. Bu yaklaşım, sadece bütçe dostu olmakla kalmadı, aynı zamanda operasyonel verimliliği de önemli ölçüde artırdı.

Gerçek Dünya Senaryoları ve İleri Düzey İpuçları: Hangi Senaryoda Hangi Sampling Stratejisi Uygun?

OpenTelemetry sampling stratejilerini anlamak bir başlangıçtır; bunları gerçek dünya senaryolarına uygulamak ise asıl zorluktur. Her uygulamanın ve her işin kendine özgü gereksinimleri ve bütçe kısıtlamaları vardır. Bu bölümde, farklı senaryolara uygun sampling yaklaşımlarını inceleyecek ve deneyimli kullanıcılar için bazı ileri düzey ipuçları sunacağız.

Farklı Uygulama Türleri İçin Sampling Seçenekleri

• Yüksek Hacimli, Genel Kullanım API'leri (Örn: Mobil Uygulama Backend'i):
  • Yaklaşım: Bu tür uygulamalar, çok sayıda benzer isteği işler ve her bir isteği detaylıca izlemek pratik değildir. Head sampling, maliyetleri yönetmek için en iyi başlangıç noktasıdır.
  • Önerilen Strateji: ParentBased ile birlikte TraceIdRatioBasedSampler (örneğin %1-5 oranında) uygulamanızın SDK'sında yapılandırın. Kritik hatalar veya yavaşlamalar için daha hassas izleme gerekiyorsa, Collector'da basit bir tail_sampling (sadece ERROR durum kodlarını veya belirli bir süreyi aşanları yakalayan) ekleyebilirsiniz.
  • İpucu: Tüm sağlıklı ve hızlı izlemelerin %99'unu atmak, genellikle sistem hakkında yeterli bilgi sağlarken maliyetleri dramatik şekilde düşürür.
• Kritik İş Akışlarına Sahip Uygulamalar (Örn: Finansal İşlemler, Sağlık Sistemleri):
  • Yaklaşım: Bu uygulamalarda her bir işlemin başarılı bir şekilde tamamlanması hayati önem taşır. Hata veya yavaşlama durumlarının %100'ünü yakalamak istenirken, normal çalışan işlemlerin tümünü kaydetmek aşırıya kaçabilir.
  • Önerilen Strateji: Öncelikle uygulamanızda çok düşük bir TraceIdRatioBasedSampler (%0.1 veya daha düşük) ile head sampling yaparak genel maliyeti düşürün. Asıl işi Collector'daki tail_sampling yapacaktır. Burada, iş mantığına özel politikalar tanımlayabilirsiniz:
    • Belirli bir iş akışındaki (örneğin '/api/transfer' veya '/api/payment') tüm hataları kaydet.
    • Belirli bir müşteri segmentine ait (örneğin premium_user_id içeren) izlemeleri her zaman kaydet.
    • Kritik bir işlemde belirli bir SLA'yı (Servis Seviyesi Anlaşması) aşan tüm izlemeleri kaydet.
  • İpucu: İş mantığınıza özel attributes (öznitelikler) kullanarak tail sampling politikalarınızı zenginleştirin. Örneğin, user.type: premium gibi custom attributeler ekleyebilirsiniz.
• Düşük Hacimli, Ancak Her İzlemenin Değerli Olduğu Uygulamalar (Örn: Batch İşler, Nadir Kullanılan Yönetim Araçları):
  • Yaklaşım: Bu senaryolarda veri hacmi doğal olarak düşüktür, bu nedenle her izlemenin kaydedilmesi genellikle uygun maliyetli ve faydalıdır.
  • Önerilen Strateji: AlwaysOnSampler kullanın. Tüm veriyi kaydetmek, gelecekteki olası sorun giderme süreçleri için tam bir geçmiş sağlar.
  • İpucu: Veri hacmi zaten düşük olduğu için, sampling'e odaklanmak yerine, izlemelerin zenginliğini (doğru span'ler, doğru attributeler) artırmaya odaklanın.

İleri Düzey İpuçları ve Püf Noktaları

1. Kombine Yaklaşımlar: Genellikle en iyi sonuçlar, head sampling ve tail sampling'in kombinasyonuyla elde edilir. Uygulamanızda genel bir TraceIdRatioBasedSampler ile başlar, ardından Collector'da daha akıllı tail sampling politikaları uygularsınız. Bu, Collector'a ulaşan veri miktarını azaltırken, kritik izlemelerin kaçırılmamasını sağlar.
2. Özel (Custom) Sampler'lar Yazma: OpenTelemetry SDK'ları, kendi özel örnekleyici mantığınızı (custom sampler) yazmanıza olanak tanır. Eğer standart örnekleyiciler ihtiyaçlarınızı karşılamıyorsa, uygulamanızın anlık durumuna, belirli özellik bayraklarına veya harici bir servisten alınan kararlara göre dinamik örnekleme yapabilirsiniz.

   
   # Örnek Python Custom Sampler Taslağı
   from opentelemetry.sdk.trace.sampling import Sampler, SamplingResult, Decision
   
   class DynamicFeatureFlagSampler(Sampler):
       def __init__(self, feature_flag_service):
           self._feature_flag_service = feature_flag_service
   
       def should_sample(
           self,
           parent_context: trace.Context,
           trace_id: int,
           name: str,
           kind: SpanKind,
           attributes: Attributes,
           links: Sequence[Link],
       ) -> SamplingResult:
           # Diyelim ki feature_flag_service, "critical_feature_enabled" bayrağını sorguluyor
           if self._feature_flag_service.is_enabled("critical_feature_enabled"):
               return SamplingResult(Decision.RECORD_AND_SAMPLE)
           
           # Aksi takdirde, varsayılan bir oranla örnekle
           if trace_id % 100 == 0: # Basit %1 rastgele örnekleme
               return SamplingResult(Decision.RECORD_AND_SAMPLE)
           
           return SamplingResult(Decision.DROP)
   
       def get_description(self) -> str:
           return "DynamicFeatureFlagSampler"
               

   Bu örnekte, DynamicFeatureFlagSampler, harici bir özellik bayrağı (feature flag) servisine bağlanarak kritik bir özellik etkin olduğunda her zaman örnekleme yapar, aksi takdirde %1 oranında rastgele örnekler.

3. A/B Testleri ve Yeni Özellik Dağıtımları: Yeni bir özellik dağıtıldığında veya A/B testi yapıldığında, bu özelliğe özel tüm izlemeleri %100 oranında örneklemek isteyebilirsiniz. Bu, yeni özelliğin performansı üzerindeki etkisini veya potansiyel hataları daha hızlı tespit etmenizi sağlar. Daha sonra, özellik stabil hale geldiğinde normal örnekleme oranlarına geri dönebilirsiniz.
4. Maliyet Monitöringi: Kullandığınız observability platformu üzerinde aylık veya günlük veri hacminizi ve maliyetlerinizi düzenli olarak izleyin. Örnekleme oranlarınızı bu verilere göre ayarlayarak bütçenizi kontrol altında tutun. Bazen küçük bir oran değişikliği bile büyük tasarruflar sağlayabilir.
5. Politikaların Önceliği: Tail sampling'de politikaların sıralaması önemlidir. Daha spesifik ve kritik politikaları (örneğin hata politikaları) genel politikalardan (örneğin rastgele örnekleme) önce tanımlayın, böylece kritik izlemeler her zaman doğru şekilde yakalanır.

Bu ileri düzey ipuçları ve senaryo bazlı yaklaşımlar, OpenTelemetry sampling'den maksimum faydayı sağlamanıza ve bütçenizi etkili bir şekilde yönetmenize yardımcı olacaktır. Unutmayın ki "tek beden herkese uyar" bir çözüm yoktur; en iyi strateji, uygulamanızın ve işinizin benzersiz ihtiyaçlarına göre uyarlanmış olanıdır.

Mobil Cihazlarda Observability ve HTML Best Practices

Mobil uygulamalar ve web siteleri için observability, kullanıcı deneyimini anlamak ve performans sorunlarını gidermek açısından hayati öneme sahiptir. OpenTelemetry, mobil SDK'ları aracılığıyla (örneğin, OpenTelemetry Swift/Kotlin SDK'ları veya web için JavaScript SDK'sı) mobil platformlarda da izleme verisi toplamanıza olanak tanır. Ancak mobil cihazlarda kaynak kısıtlamaları (pil ömrü, veri kullanımı) ve ağ koşulları (istikrarsız bağlantılar) göz önüne alındığında, sampling stratejileri daha da kritik hale gelir. Aşırı veri toplama, kullanıcı deneyimini olumsuz etkileyebilir ve mobil veri faturalarına yansıyabilir.

Mobil Uygulamalarda Sampling İpuçları:

• Düşük Sampling Oranları: Mobil cihazlarda genellikle daha düşük head sampling oranları (%0.1 - %0.5) tercih edilir. Kritik hataları veya çökmeleri yakalamak için tail sampling benzeri (ancak cihaz üzerinde kaynak kısıtlamaları nedeniyle daha basit) mekanizmalar kullanılabilir.
• Kullanıcı İzni: Özellikle kişisel veri toplarken kullanıcıdan açık rıza almak önemlidir. Sampling, toplanan veri miktarını azaltarak gizlilik endişelerini hafifletebilir.
• Network Koşullarına Duyarlı Sampling: Uygulama, kullanıcının Wi-Fi'da mı yoksa mobil veride mi olduğunu algılayabilir ve mobil veri kullanılıyorsa daha agresif bir sampling oranı uygulayabilir.
• Hata Önceliği: Mobil uygulamalarda hata izleme, performans izlemeden daha kritik olabilir. Tüm hata izlemelerini kaydetmeye öncelik verin.

HTML Best Practices ve Mobil Uyumlu Tasarım:

Bu teknik makale HTML formatında sunulduğu için, mobil uyumluluğun önemine değinmek gerekir. Günümüzde web trafiğinin büyük bir kısmı mobil cihazlardan gelmektedir. Bu nedenle, teknik makaleler dahil her türlü web içeriğinin mobil cihazlarda düzgün görüntülenmesi ve okunması gerekmektedir.

Temel Mobil Uyumlu HTML Kuralları:

1. Viewport Meta Etiketi: En temel kural, HTML etiketine viewport meta etiketini eklemektir. Bu etiket, tarayıcıya sayfanın cihazın genişliğine göre ölçeklenmesini söyler.

2. Esnek Resimler ve Medya: Resimlerin ve diğer medya öğelerinin, ekran boyutuna göre otomatik olarak yeniden boyutlandırıldığından emin olun.

   
   img {
       max-width: 100%;
       height: auto;
       display: block; /* Gereksiz boşlukları önler */
   }
               

3. Duyarlı Tipografi: Metinlerin küçük ekranlarda okunabilir olduğundan emin olun. font-size ve line-height değerlerini mobil için optimize edin.
4. Media Queries Kullanımı: Farklı ekran boyutları için farklı stiller uygulamak üzere CSS media query'lerini kullanın. Bu, içeriğin belirli cihazlara göre nasıl görüneceğini kontrol etmenizi sağlar. Örneğin, bu makaledeki kod bloklarını veya tabloları mobil cihazlarda yatay kaydırılabilir yapmak için kullanılabilir:

   
   /* Genel stil */
   .article-container {
       max-width: 960px;
       margin: 0 auto;
       padding: 15px;
       font-family: sans-serif;
       line-height: 1.6;
       color: #333;
   }
   
   /* Kod blokları için duyarlı stil */
   pre {
       background-color: #f4f4f4;
       padding: 15px;
       border-radius: 5px;
       overflow-x: auto; /* Yatay kaydırma çubuğu ekler */
       white-space: pre-wrap; /* Uzun satırları sarar */
       word-wrap: break-word;
       margin-bottom: 20px;
   }
   
   /* Küçük ekranlar için (mobil cihazlar) */
   @media (max-width: 768px) {
       .article-container {
           padding: 10px;
       }
       h2, h3 {
           font-size: 1.5em; /* Başlık boyutlarını ayarlar */
       }
       p, li {
           font-size: 0.95em;
       }
       pre {
           font-size: 0.8em;
       }
       table {
           display: block;
           overflow-x: auto;
           white-space: nowrap;
           border-collapse: collapse;
           width: 100%;
       }
       table thead, table tbody, table tr, table th, table td {
           display: block;
       }
       table tr {
           margin-bottom: 10px;
           border: 1px solid #ddd;
       }
       table td {
           border-bottom: 1px solid #ddd;
           position: relative;
           padding-left: 50%;
           text-align: right;
       }
       table td:before {
           position: absolute;
           left: 6px;
           content: attr(data-label); /* Tablo başlığını etikete dönüştürür */
           font-weight: bold;
           text-align: left;
       }
   }
   
   /* Uzman ipucu kutusu */
   .expert-tip {
       background-color: #e6f7ff;
       border-left: 5px solid #3399ff;
       padding: 15px;
       margin: 20px 0;
       border-radius: 4px;
       font-style: italic;
       color: #333;
   }
               

   Yukarıdaki CSS örneğinde, 768px genişliğin altındaki ekranlar için (yani çoğu mobil cihaz), yazı tipleri küçültülür, kod blokları yatay kaydırılabilir hale getirilir ve tablolar daha dikey bir görünüme dönüştürülerek okunabilirlik artırılır. HTML tablosunda data-label özelliğini kullanarak tablo başlıklarını mobil görünümde her hücrenin önüne eklemek iyi bir tekniktir. Örneğin:

   
   
     
   
       
   
         
   Kriter
         
   Head Sampling
         
   Tail Sampling
       
     
     
   
       
   
         
   Karar Zamanı
         
   Trace'in başında
         
   Trace tamamlandıktan sonra
       
       
   
         
   Maliyet Optimizasyonu
         
   Yüksek
         
   Orta (Collector maliyeti)
       
     
   
               

5. Performans: Mobil cihazlar için sayfa yükleme hızını optimize edin. Küçük dosya boyutları, optimize edilmiş resimler ve az JavaScript kullanımı önemlidir.

Bu HTML best practices'lerini takip ederek, OpenTelemetry ile topladığınız observability verilerini analiz eden herkesin, kullandığı cihazdan bağımsız olarak, makalenizi kolayca okuyabilmesini sağlarsınız.

Sonuç: Sampling ile Bütçenizi Kurtarırken Kaliteyi Korumak Mümkün

Günümüzün karmaşık ve dağıtık sistemlerinde, uygulamaların gözlemlenebilirliği (observability) sadece bir lüks değil, aynı zamanda operasyonel verimlilik ve kullanıcı memnuniyeti için temel bir gerekliliktir. Ancak bu değerli içgörüyü elde etmenin maliyeti, özellikle yüksek trafikli ortamlarda hızla tavan yapabilir. OpenTelemetry sampling, bu maliyet yükünü hafifletmek için güçlü ve esnek bir çözüm sunar. Bu makale boyunca gördüğümüz gibi, sampling, tüm telemetri verisini körü körüne kaydetmek yerine, hangi izlemelerin gerçekten önemli olduğuna dair akıllı kararlar alarak bütçenizden tasarruf etmenizi sağlar.

Head sampling ile erken aşamada veri hacmini azaltabilir, Tail sampling ile ise kritik hataları ve performans sorunlarını yüksek güvenilirlikle yakalayabilirsiniz. Her iki yaklaşımın da kendine özgü avantajları ve kullanım senaryoları vardır ve genellikle en iyi sonuçlar için bu stratejilerin akıllıca bir kombinasyonu kullanılır. OpenTelemetry'nin sağladığı esneklik sayesinde, TraceIdRatioBasedSampler gibi basit oran tabanlı örnekleyicilerden, iş mantığına özel kurallar uygulayan sofistike tail_sampling politikalarına ve hatta tamamen özel örnekleyicilere kadar geniş bir yelpazede çözümler geliştirebilirsiniz.

Önemli olan, uygulamanızın doğasını, iş hedeflerinizi ve bütçe kısıtlamalarınızı dikkatlice değerlendirerek size en uygun sampling stratejisini belirlemektir. Veri toplama oranlarınızı sürekli olarak izlemek, observability platformunuzdaki maliyetleri takip etmek ve stratejinizi buna göre ayarlamak, sürekli bir optimizasyon sürecidir. Unutmayın, hedef, "her şeyi" izlemek değil, "önemli olanı" en etkili şekilde izlemektir. OpenTelemetry sampling ile, hem bütçenizi koruyabilir hem de uygulama performansınız ve sağlığınız hakkında kritik içgörüleri kaybetmeden, daha akıllı ve sürdürülebilir bir observability stratejisi oluşturabilirsiniz. Bu, sadece finansal bir avantaj sağlamakla kalmaz, aynı zamanda operasyonel ekiplerinizin daha az "gürültü" ile daha hızlı ve doğru kararlar almasına da olanak tanır.

Sıkça Sorulan Sorular (SSS)

Sampling tüm veriyi kaybetmeme neden olmaz mı?

Hayır, doğru uygulandığında sampling, tüm veriyi kaybetmek anlamına gelmez. Aksine, size en değerli ve eyleme geçirilebilir içgörüleri sağlayacak temsili bir veri kümesi elde etmenizi amaçlar. Head sampling rastgele seçerken, tail sampling hatalar, yavaşlıklar veya belirli iş akışları gibi önemli kriterlere göre seçim yaparak kritik izlemelerin kaçırılmamasını sağlar. Bu sayede, "gürültüyü" azaltırken "sinyali" korursunuz.

Head ve Tail sampling arasında ne zaman seçim yapmalıyım?

Genellikle her ikisini bir arada kullanmak en iyisidir. Yüksek hacimli ve genel kullanım senaryoları için uygulamanızda düşük oranlı (örneğin %1-5) head sampling uygulayarak ilk maliyet optimizasyonunu sağlayabilirsiniz. Ardından, daha kritik ve akıllı kararlar için OpenTelemetry Collector'da tail sampling'i (hata içerenleri veya belirli bir süreyi aşanları her zaman örnekleyen) yapılandırın. Head sampling, erken aşamada yükü azaltırken, tail sampling önemli sorunların kaçırılmamasını garanti eder.

İdeal sampling oranı ne olmalı?

İdeal sampling oranı, uygulamanızın trafik hacmine, kritiklik seviyesine, hata oranına ve bütçe kısıtlamalarınıza bağlı olarak değişir. Genellikle %1 ile %10 arasında bir head sampling oranıyla başlanır. Tail sampling'de ise, kritik izlemeler için %100, geri kalanı için ise çok düşük bir olasılık (%0.1-%1) belirlenir. En iyi oranı bulmak için, observability platformunuzdaki verileri (toplam izleme sayısı, hata oranları, ortalama gecikme) izleyerek ve maliyet-fayda analizi yaparak deneme yanılma yoluyla ince ayar yapmanız gerekir.

Custom sampler yazmak ne zaman gerekli olur?

Custom sampler yazmak, standart OpenTelemetry örnekleyicileri mevcut iş mantığınıza veya karmaşık dinamik gereksinimlerinize uymadığında gerekli olur. Örneğin, belirli bir özellik bayrağına (feature flag) göre dinamik olarak örnekleme yapmak, belirli bir coğrafi bölgeden gelen istekleri daha yüksek oranlarda izlemek veya harici bir sisteme danışarak örnekleme kararı vermek istediğinizde özel bir örnekleyici geliştirebilirsiniz.

Sampling maliyetleri ne kadar azaltabilir?

Sampling, observability maliyetlerini önemli ölçüde azaltabilir. Uygulamanızın trafik hacmine ve uyguladığınız sampling oranına bağlı olarak %50'den %95'e kadar hatta daha fazla tasarruf sağlamak mümkündür. Örneğin, %1'lik bir sampling oranıyla, gönderilen veri hacmini teorik olarak %99 oranında azaltırsınız. Bu da doğrudan depolama, transfer ve işleme maliyetlerine yansır ve bulut faturanızda ciddi bir düşüş anlamına gelir.