Ölçeklenen Altyapılarda Observability Maliyetini Yönetme: FinOps ve Sampling Stratejileri

Ay başında Datadog, New Relic veya AWS CloudWatch faturası geldiğinde dashboard’lardaki p99 gecikme grafiklerinden daha hızlı yükselen tek bir metrik vardır: Finans direktörünün nabzı. Modern bir DevOps mimarisinde mikroservislerin sayısı ve trafik hacmi arttıkça, observability altyapısının maliyeti çoğu zaman production ortamının compute maliyetini geride bırakır. Sistemin kör noktalarını kapatmak isterken bütçeyi tüketmek sürdürülebilir değil. Doğru bir FinOps yaklaşımı ve akıllı log yönetimi stratejileriyle, sistem görünürlüğünden ödün vermeden veri hacmini %60 ila %80 oranında düşürmek mümkün.

Fatura Neden Şişer? Görünmez Maliyet Kalemleri

Kıdemli mühendislerin sıkça düştüğü tuzak şudur: “Her şeyi loglayalım, OpenSearch veya Loki’ye basalım; lazım olursa grep’leriz.” Trafiğiniz saniyede 100 istek seviyesindeyken bu kabul edilebilir bir tembelliktir. Ancak saniyede 50.000 request aldığınız anda bu alışkanlık bir bütçe felaketine dönüşür.

Maliyeti patlatan üç ana faktör vardır:

• Sağlık Kontrolleri (Health Checks): Kubernetes liveness/readiness probları ve ALB ping’leri log havuzunuzun %30’unu oluşturabilir. HTTP 200 GET /healthz satırının size hata anında hiçbir faydası yoktur.
• Yüksek Kardinalite (High Cardinality): Metrik etiketlerine (label) user_id, order_id gibi sınırsız varyasyonu olan değerler eklemek, time-series veritabanınızın (Prometheus/Mimir) bellek tüketimini ve ingest maliyetini katlar.
• Head-Based Sampling Hataları: Tracing verisinde rastgele %5 sampling aldığınızda, sistemdeki asıl yakalamak istediğiniz 500 hatalarının ve p99 outlier’larının da %95’ini çöpe atarsınız. Geriye sadece gürültü kalır.

Log Yönetimi: Vector ile Edge Düzeyinde Filtreleme ve Dönüştürme

Logları merkezi sisteme göndermeden önce daemonset katmanında filtrelemek en ucuz ve en etkili çözümdür. Logstash veya Fluentd gibi JVM/Ruby tabanlı hantal çözümler yerine Rust ile yazılmış düşük ayak izli Vector bu iş için biçilmiş kaftandır.

Aşağıdaki Vector konfigürasyonunda üç kritik optimizasyon yapıyoruz: Başarılı health check’leri drop ediyoruz, hassas verileri tokenize ediyoruz ve kalan debug loglarını örnekliyoruz (sampling).

cat << 'EOF' > /etc/vector/vector.yaml
sources:
  kubernetes_logs:
    type: kubernetes_logs

transforms:
  filter_health_checks:
    type: filter
    inputs:
      - kubernetes_logs
    # HTTP 200 dönen healthz loglarını doğrudan çöpe at
    condition: '!includes(["/healthz", "/readyz", "/livez"], .message)'

  drop_noisy_debugs:
    type: filter
    inputs:
      - filter_health_checks
    # Log seviyesi DEBUG olanları %90 oranında sample et
    condition: |
      if .level == "debug" {
        random() < 0.1
      } else {
        true
      }

  sanitize_and_prune:
    type: remap
    inputs:
      - drop_noisy_debugs
    source: |
      # Gereksiz Kubernetes metadata alanlarını temizle
      del(.kubernetes.pod_labels)
      del(.kubernetes.pod_annotations)
      
      # Kredi kartı gibi hassas verileri maskele
      .message = replace(.message, r'[0-9]{4}-[0-9]{4}-[0-9]{4}-[0-9]{4}', "[REDACTED_CC]")

sinks:
  elasticsearch_out:
    type: elasticsearch
    inputs:
      - sanitize_and_prune
    endpoints:
      - "https://elasticsearch.internal:9200"
    mode: "bulk"
EOF

Neden böyle yaptık? Kubernetes metadata’sındaki pod annotation’ları production’da devasa JSON payload’ları üretir. Bunları edge katmanında del() fonksiyonu ile silmek, taşınan ve indekslenen veri boyutunu anında %25 azaltır.

Tracing Verisinde Tail-Based Sampling Stratejisi

Geleneksel distributed tracing araçları trace’in başlangıcında karar verir (Head-based sampling). Bir istek geldiğinde yazı tura atılır: %1 seçilirse tüm akış kaydedilir. Fakat istek sırasında bir mikroservis patlarsa ve siz o isteği sample etmediyseniz, elinizde hiçbir şey kalmaz.

Tail-based sampling, isteğin tamamlanmasını bekler. İstek hata aldıysa veya belirlenen latency eşiğini aştıysa trace’i %100 saklar; sorunsuz HTTP 200 yanıtlarını ise agresif bir şekilde eler.

Bunu OpenTelemetry (OTel) Collector katmanında şu şekilde konfigüre ediyoruz:

cat << 'EOF' > /etc/otelcol/config.yaml
receivers:
  otlp:
    protocols:
      grpc:
      http:

processors:
  tail_sampling:
    decision_wait: 10s
    num_traces: 10000
    expected_new_traces_per_sec: 2000
    policies:
      # 1. Kural: Status code ERROR olan tüm trace'leri eksiksiz tut
      - name: drop_errors_policy
        type: status_code
        status_code: { status_codes: [ ERROR ] }

      # 2. Kural: Süresi 1.5 saniyeyi aşan tüm yavaş istekleri yakala
      - name: latency_policy
        type: latency
        latency: { threshold_ms: 1500 }

      # 3. Kural: Kalan normal akıştan sadece %1 örnek al
      - name: probabilistic_policy
        type: probabilistic
        probabilistic: { sampling_percentage: 1.0 }

exporters:
  otlp/backend:
    endpoint: "tempo.monitoring.svc.cluster.local:4317"
    tls:
      insecure: true

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [tail_sampling]
      exporters: [otlp/backend]
EOF

Bu konfigürasyonda OTel Collector, trace parçalarını decision_wait: 10s süresince bellekte tutar. Span ağacı tamamlandığında kuralları yukarıdan aşağıya değerlendirir. İstisna veya lag varsa diskte saklanır; yoksa veri hacmi anında %99 bastırılır.

Metriklerin Sessiz Katili: Kardinaliteyi Düşürme (Metric Relabeling)

Datadog veya Prometheus faturalarında metrik maliyetlerinin patlamasının temel nedeni “Custom Metrics” ve time-series patlamalarıdır. Bir metriğin kaç time-series ürettiğini şu formülle hesaplarız:

Total Time Series = (Değer_Sayısı_Label_A) * (Değer_Sayısı_Label_B) * (Değer_Sayısı_Label_C)

Eğer bir yazılımcı HTTP istek metriğine user_id veya rastgele UUID’ler içeren path eklediyse, o metrik saniyeler içinde 500.000 time-series üreterek bellek limitlerini vurur. Prometheus scrape konfigürasyonunda metric_relabel_configs kullanarak bu etiketleri ingest anında silmelisiniz:

scrape_configs:
  - job_name: 'api-gateway'
    kubernetes_sd_configs:
      - role: pod
    metric_relabel_configs:
      # Belirli yüksek kardinaliteli dinamik labelları drop et
      - action: labeldrop
        regex: '(user_id|client_ip|session_token)'
      
      # REST URL path'lerindeki UUID'leri regex ile normalize et
      - source_labels: [__name__, path]
        regex: 'http_requests_total;/api/v1/orders/[a-f0-9\-]+'
        target_label: path
        replacement: '/api/v1/orders/:id'

Yukarıdaki işlem yapılmadığında /api/v1/orders/a1b2-c3d4 ve /api/v1/orders/e5f6-g7h8 iki ayrı metrik olarak depolanır. Regex normalizasyonu sayesinde her iki istek de /api/v1/orders/:id altında birleşir; metrik tekilleşir ve time-series sayısı tek hanelere iner.

Veri Yaşam Döngüsü: Tiering ve Soğuk Depolama

SRE ekiplerinin yaptığı analizler, log sorgularının %92’sinin son 48 saat içinde yazılan verilere yapıldığını gösteriyor. 30 gün önceki bir INFO logunu pahalı NVMe disklerde tutmak safi kaynak israfıdır.

Loki veya Elasticsearch kullanırken iki katmanlı (hot/cold) saklama stratejisi kurgulayın:

• Hot Tier (0-7 Gün): Hızlı sorgulama için NVMe diskler veya SSD blok depolama. Tam indeksleme açık.
• Warm/Cold Tier (7-30 Gün): İndeksleri küçültülmüş, read-only modda çalışan uygun maliyetli HDD veya S3/GCS object storage katmanı.
• Deep Archive (30+ Gün): Yalnızca regülasyon (KVKK/GDPR/PCI-DSS) gereği tutulması gereken veriler için S3 Glacier / GCS Archive lifecycle kuralları. İndeks yok, yalnızca ham gzip blokları.

Özet: FinOps Mühendisliği Bir Süreçtir

Observability sistemlerini optimize etmek, kör uçuş yapmak anlamına gelmez. Tam aksine, doğru sinyali yakalayıp gürültüyü (noise) elimine etmektir. Edge katmanında Vector ile gürültüyü kesin, APM tarafında tail-based sampling ile hatalara odaklanın ve scraping aşamasında kardinaliteyi regex ile dizginleyin. Bu üç adımı attığınızda, faturanız düşerken platformunuzun asıl sorunları tespit etme kabiliyeti katlanarak artacaktır.