Metriklerin Ötesinde Observability: Sistem Hikaye Anlatıcılığı Sanatı

Bütün dashboard’lar yeşil, her metrik eşiğinin içinde, ama müşteriler checkout’un çalışmadığını söylüyor. Toplulaştırılmış metrikler bileşenleri tek tek anlatır; bileşenlerin arasındaki yolda yaşayan bir hata hiçbirine görünmez.

Distributed tracing bu boşluğu kapatır. Tek bir trace, bir isteği dokunduğu her servis boyunca takip eder ve olayların hangi sırayla gerçekleştiğini kaydeder. Varsayılan yaklaşım şu: uçtan uca enstrümente edilmiş tek bir kullanıcı yolculuğu ve her span’a iliştirilmiş iş bağlamı.

Tek Bir Trace Neyi Gösterir#

Checkout akışlarında tekrar eden bir hata biçimini düşünün. Altyapı dashboard’ları sağlıklı görünür: CPU kapasitenin çok altında, bellek normal, servis başına response time’lar birkaç yüz milisaniye. Dönüşüm oranı ise dibe vurur.

Trace bunu tek bakışta açıklar. Öneri servisi cache’ini kaybeder ve checkout başına iki yerine düzinelerce API çağrısı yapmaya başlar. Her çağrı tek başına hızlı olduğu için hiçbir servisin latency grafiği kıpırdamaz. Checkout sayfası hepsini bekler, kullanıcı sayfa oturmadan çıkar. Hata yalnızca yolun toplamında vardır ve bu yolu trace kaydeder.

// Servis bazlı dashboard'ların gösterdiği
interface GelenekselMetrikler {
  cpu: "ortalama %40";
  bellek: "6GB/8GB";
  responseTime: "200ms p50";
  hataOrani: "%0.1";
}

// Aynı isteğin tek bir trace'inin gösterdiği
interface TraceGorunumu {
  kullaniciYolculugu: "checkout_denemesi";
  toplamSure: "8.3 saniye";
  spanSayisi: 247;             // sağlıklı bir checkout 15 civarındadır
  kritikYol: {
    servis: "oneri-servisi",
    operasyon: "ilgili_urunleri_getir",
    cagrilar: 47,              // görünür hale gelen cache miss
    toplamZaman: "6.8 saniye"
  };
}

Anlatı Odaklı Observability İnşa Etmek#

Karşılığını veren telemetri, sistemin tamamındaki kullanıcı etkileşimlerini servis servis parçalamadan anlatır: yolculuk kapsamlı span’lar, bu span’lara iliştirilen iş öznitelikleri ve yolculuğu okuyan alerting.

OpenTelemetry ile Yolculuk Haritalama#

Tam kullanıcı yolculuklarını yakalamak için servisler şu şekilde instrument edilir:

import { trace, context, SpanStatusCode } from '@opentelemetry/api';
import { BusinessContext } from './business-metrics';

class CheckoutService {
  private tracer = trace.getTracer('checkout-service', '1.0.0');
  
  async processCheckout(userId: string, cart: CartData): Promise<CheckoutResult> {
    // Önce iş bağlamı, sonra teknik detay
    const baslangic = Date.now();
    const span = this.tracer.startSpan('kullanici.checkout.deneme', {
      attributes: {
        'kullanici.id': userId,
        'kullanici.seviye': await this.getUserTier(userId),
        'is.sepet_degeri': cart.totalValue,
        'is.gelir_etkisi': cart.totalValue,
        'yolculuk.adim': 'checkout_basladi',
        'yolculuk.giris_noktasi': cart.referrer
      }
    });
    
    // Context'i servis sınırları boyunca yay
    return context.with(trace.setSpan(context.active(), span), async () => {
      try {
        // Her adım hikayeye eklenir
        span.addEvent('envanter.dogrulama.basladi', {
          kontrol_edilecek_urunler: cart.items.length
        });
        
        const inventory = await this.validateInventory(cart);
        
        if (!inventory.allAvailable) {
          // Checkout'un NEDEN başarısız olduğunu söyler
          span.setAttributes({
            'hata.nedeni': 'envanter_yok',
            'hata.urunler': inventory.unavailableItems.join(','),
            'is.etki': 'checkout_terkedildi'
          });
          span.setStatus({ 
            code: SpanStatusCode.ERROR, 
            message: 'Envanter kontrolü başarısız' 
          });
          return { success: false, reason: 'stokta_yok' };
        }
        
        // Hikayeyi oluşturmaya devam et...
        span.addEvent('odeme.isleme.basladi');
        const payment = await this.processPayment(cart, userId);
        
        span.setAttributes({
          'yolculuk.tamamlandi': true,
          'is.siparis_degeri': payment.amount,
          'yolculuk.toplam_sure_ms': Date.now() - baslangic
        });
        
        return { success: true, orderId: payment.orderId };
        
      } catch (error) {
        // Başarısızlık hikayesini yakala
        span.recordException(error);
        span.setAttributes({
          'hata.asama': this.getCurrentStage(),
          'hata.kurtarma_denendi': true,
          'is.etki': 'gelir_kaybi'
        });
        throw error;
      } finally {
        span.end();
      }
    });
  }
}

Trace’lerden İş Etkisine#

Bir trace’i iş metriklerine bağlamak, onu incident sırasında cevap verilebilir kılan şeydir. Aşağıdaki analizci, bir trace ID’sinden iki okumayı birden çıkarır:

class IsEtkisiAnalizcisi {
  async traceEtkisiniAnalizeEt(traceId: string): Promise<EtkiRaporu> {
    const trace = await this.getTrace(traceId);
    const isKonteksti = this.extractBusinessContext(trace);
    
    return {
      // Teknik hikaye
      teknikAnlati: {
        girisNoktasi: trace.rootSpan.service,
        hataNoktasi: this.findFailureSpan(trace),
        cascadeEtkisi: this.analyzeCascade(trace),
        performansDarbogazi: this.findSlowestPath(trace)
      },
      
      // İş hikayesi
      isAnlatisi: {
        kullaniciAmaci: isKonteksti.yolculukTuru, // "satin_alma", "gezinme", vb.
        riskAltindakiDeger: isKonteksti.sepetDegeri || isKonteksti.abonelikDegeri,
        kullaniciSegmenti: isKonteksti.kullaniciSeviyesi,
        donusumAsamasi: this.getConversionStage(trace),
        alternatifYollar: this.findAlternativeJourneys(isKonteksti)
      },
      
      // Birleşik hikaye
      etki: {
        anlikGelirKaybi: this.calculateImmediateLoss(isKonteksti),
        tahminiKayipRiski: this.predictChurnImpact(trace, isKonteksti),
        markaHasarSkoru: this.assessBrandImpact(trace),
        kurtarmaAksiyonlari: this.generateRecoveryPlan(trace, isKonteksti)
      }
    };
  }
}

AI Destekli Pattern Tanıma#

Uçtan uca enstrümantasyon, kimsenin okuyamayacağı kadar çok trace verisi üretir. Bu hacim üzerinde ilk geçiş için dil modeli makul bir araçtır; iyi yakaladığı sinyal tekrardır: her hatadan önce yinelenen aynı olay sıralaması. İlk seferde doğru cevabı vermekte ise çok daha zayıftır ve yayımlanmış araştırma bu zayıflığın büyüklüğü konusunda oldukça net.

Retrieval Adımı#

Bir trace yığınını başka hiçbir şey eklemeden modele vermek, bugüne kadar ölçülmüş en zayıf kurulumdur. Chen ve arkadaşları, EuroSys ‘24’te sundukları RCACopilot çalışmasında Microsoft’un Transport servisinden bir yıl boyunca toplanan 653 olayı değerlendirdi ve tam hattın micro-F1 skorunu 0,766 olarak raporladı. Aynı tabloda, benzer geçmiş olayların hiç getirilmediği düz GPT-4 prompt’lamasının micro-F1 skoru 0,026. Eşleşen geçmiş olayların getirilmesi sonucu taşıyor.

Aynı çalışma, 0,766’lık micro-F1’e karşılık 0,533 macro-F1 veriyor; yani doğruluk, seyrek görülen kök neden kategorilerinde belirgin biçimde düşüyor. Modele sormaya değer aralıklı hatalar tam olarak o kategoride durduğu için bu fark önemli.

Dolayısıyla retrieval prompt metnine değil koda ait:

class TraceHipotezOlusturucu {
  async kokNedenOner(traces: DistributedTrace[]): Promise<Hipotez> {
    // Yükü taşıyan adım: buna benzeyen geçmiş olayları bul
    const imza = this.hataImzasiCikar(traces); // servis, operasyon, hata sınıfı, span sıralaması
    const emsaller = await this.olayDeposu.benzerleriBul(imza, { limit: 10 });

    if (emsaller.length === 0) {
      return { durum: 'emsal_yok', traceIdleri: imza.traceIdleri };
    }

    const spanOzeti = this.spanOzetiCikar(traces); // span ID'leri, adları, süreleri, parent bağlantıları; ham JSON değil
    const okunabilirSpanIdleri = new Set(spanOzeti.map(span => span.spanId));

    const cevap = await this.llm.analyze({
      yonerge:
        "Tek bir kök neden öner. Onu destekleyen span ID'lerini göster. " +
        "Trace'ler bir nedeni desteklemiyorsa yetersiz kanıt bildir.",
      emsaller: emsaller.map(e => ({
        ozet: e.ozet,
        neden: e.kokNeden,
        cozum: e.mudahale
      })),
      hataliOlanlar: spanOzeti
    });

    // Sonradan yalnızca prompt'a giren bir span yeniden açılabilir
    const gosterilenler = cevap.gosterilenSpanIdleri ?? [];
    const tumGosterilenlerOkunabilir =
      gosterilenler.length > 0 && gosterilenler.every(id => okunabilirSpanIdleri.has(id));

    // Yönergeye uyan bir model, aksiyon alınacak hiçbir şey olmadan da dönebilir;
    // span ID'si uyduran bir model ise eski uzunluk kontrolünü boşuna geçerdi
    if (!cevap.neden || !tumGosterilenlerOkunabilir) {
      return {
        durum: 'yetersiz_kanit',
        traceIdleri: imza.traceIdleri,
        emsalIdleri: emsaller.map(e => e.id)
      };
    }

    return {
      durum: 'hipotez',
      neden: cevap.neden,
      gosterilenSpanIdleri: gosterilenler, // aksiyon almaya değer tek alan
      emsalIdleri: emsaller.map(e => e.id)
    };
  }
}

Dönen değerde güven skoru yok. Kök nedenin yanına basılan bir ondalık sayı kalibrasyon izlenimi verir; burada atıf yapılan çalışmaların hiçbiri, modelin beyan ettiği güveni telemetri üzerinde kalibre edilmiş bir olasılık saymayı desteklemiyor. Saklamaya değer alan span ID listesidir, çünkü bir span ID doğrulanabilir; fonksiyon da dönmeden önce bunu doğrular. Hiçbir span göstermeyen bir cevapta doğrulanacak bir şey yoktur. Özette hiç geçmemiş bir span’ı gösteren cevap ise okuyucuyu var olmayan bir kaydın peşine yollar. İkisi de hipotez olarak dönmez.

Gerçek Olaylarda Doğruluk#

Roy ve arkadaşları Microsoft’ta LLM ajanlarını 107.000 gerçek production olayına karşı sınadı, ardından iki yazar her yöntem için 100 tahmini elle notlandırdı. Bir retrieval temel çizgisi ile bir chain-of-thought ajanı %39 oranında doğru bulundu, ReAct ajanı ise %35. Aralarındaki farkı halüsinasyon oranları açıyor: yanlış tahminler içinde retrieval temel çizgisi %49 oranında halüsinasyon üretirken ReAct’ta bu oran %6. Çalışmanın kendi özeti şöyle: ReAct üçü arasında en yüksek kesinliğe sahip, bedeli ise daha düşük genel doğruluk.

3 mikroservis sistemi üzerinde 11 hata tipi ve 735 hata vakası içeren nötr bir kıyaslama olan RCAEval, klasik taraf hakkında açık konuşuyor: “Existing methods mostly obtain moderate results” (mevcut yöntemler çoğunlukla orta düzeyde sonuç alıyor); 15 temel çizgi içindeki en iyi ortalama Avg@5 skorları 0,46 ve 0,54. İçinde hiç LLM temel çizgisi yok, dolayısıyla LLM tabanlı trace analizini klasik kök neden analiziyle karşılaştıran nötr bir sıralama da yok.

Satıcılar başka bir büyüklük yayımlıyor. Datadog’un Bits AI SRE ajanı üzerine mühendislik yazısı, çözüm süresinde %95’e varan azalma bildiriyor; kök nedeni bilinen gerçek olaylardan kurulu ve bir LLM yargıcıyla puanlanan dahili bir kıyaslama anlatıyor, doğruluk rakamı vermiyor. Çözüm süresi ile doğruluk aynı ölçüm değil ve yazı yalnızca ilkini raporluyor. Yukarıdaki araştırma rakamları da bu boşluğu doldurmuyor. Elle notlandırılmış doğruluk, F1 ve Avg@5 farklı sorulara cevap veriyor; tek bir doğruluk skorunda toplanmıyorlar.

Aranmaya değer pattern’in belirli bir biçimi var: bir invalidation event’i ile onu izleyen hatalar arasında sabit bir gecikme; bu yalnızca trace’ler servisler arası sıralamayı koruduğu için görünür hale gelir. Mekanizmayı, modelin gösterdiği span’ları okuyarak harekete geçmeden önce doğrulayın. Sahadaki beklenti de bu yönde: 76 ülkeden 1.363 katılımcıyla yapılan Grafana Labs Observability Survey 2026’da katılımcıların %95’i AI’ın muhakemesini göstermesinin önemli olduğunu söyledi.

Bütçedeki ağırlığı küçük bir kalem. Honeycomb, sahaya çıkardığı Query Assistant’ın rakamlarını yayımladı: aylık yaklaşık 30 USD OpenAI faturası, her şey dahil ayda birkaç yüz dolar, ortalama yaklaşık 5 saniye gecikme ve iyileştirme öncesinde 30 saniye ya da üzerinde ölçülen bir P99. Ölçebildiği etkiyi de yayımladı; o etki cevaplarda değil öğrenmede çıktı. Altıncı haftada, asistanı kullanmış ekiplerin %26,5’i hâlâ elle sorgu yazıyordu; kullanmamış ekiplerde bu oran %4,5’ti.

Alert Gürültüsünü Bağlamla Azaltmak#

Aşırı instrumentation alert yorgunluğuyla bitiyor ve saha bunu baş engel olarak raporluyor. Grafana Labs Observability Survey 2026’da katılımcıların %30’u, olaylara daha hızlı müdahale etmenin önündeki en büyük engel olarak alert yorgunluğunu işaret etti; bu, açık farkla en sık verilen cevap.

Hikaye odaklı alerting, kimseyi uyandırmadan önce iş bağlamına bakar:

class HikayeOdakliAlerting {
  async alertDegerlendir(anomali: TraceAnomaly): Promise<AlertKarari> {
    // Sadece teknik metriklere alert verme
    if (!anomali.hasBusinessContext()) {
      return { alertVer: false, neden: "İş etkisi tespit edilmedi" };
    }
    
    // Tam hikayeyi oluştur
    const hikaye = await this.hikayeOlustur(anomali);
    
    // Sadece hikaye önemliyse alert ver
    const etkiSkoru = this.etkiSkoruHesapla({
      etkilenenKullanicilar: hikaye.kullaniciSayisi,
      riskAltindakiGelir: hikaye.potansiyelKayip,
      musteriSeviyesi: hikaye.birincilKullaniciSegmenti,
      gunSaati: hikaye.isSaatleriMi,
      benzerOlaylar: await this.benzerHikayeleriBul(hikaye)
    });
    
    if (etkiSkoru < this.alertEsigi) {
      // Logla, ama kimseyi uyandırma
      await this.sonrakiAnalizIcinLogla(hikaye);
      return { alertVer: false, neden: "Etki eşiğinin altında" };
    }
    
    // Tüm hikayeyi anlatan bir alert oluştur
    return {
      alertVer: true,
      kanal: this.etkiIcinKanalBul(etkiSkoru),
      mesaj: this.anlatisalAlertOlustur(hikaye),
      onerilenAksiyonlar: await this.playbookOlustur(hikaye),
      otoRemediasyon: this.otoRemediasyonYapilabilirMi(hikaye)
    };
  }
  
  private anlatisalAlertOlustur(hikaye: OlayHikayesi): string {
    // Emsalsizlik de yetersiz kanıt da trace ID'leriyle gelir, gösterilen span olmadan
    const kanit = hikaye.gosterilenSpanIdleri?.length
      ? `Destekleyen span'lar: ${hikaye.gosterilenSpanIdleri.join(', ')}`
      : `Gösterilen span yok (${hikaye.durum}). Okunacak trace'ler: ${hikaye.traceIdleri?.join(', ') || 'kayıt yok'}`;

    return `
      Olay Hikayesi:
      
      Ne oluyor: ${hikaye.ozet}
      Kim etkileniyor: ${hikaye.etkilenenKullanicilar} kullanıcı (${hikaye.kullaniciSegmentleri})
      İş etkisi: Saatte $${hikaye.gelirEtkisi} potansiyel kayıp
      
      Bozulan yolculuk:
      ${hikaye.bozulanYolculuk.map(adim => `→ ${adim}`).join('\n')}
      
      Kök neden hipotezi: ${hikaye.kokNeden || 'Öneri yok'}
      ${kanit}
      
      Benzer olay: ${hikaye.oncekiOlay?.ozet || 'Benzer olay bulunamadı'}
      
      Önerilen aksiyonlar:
      ${hikaye.onerilenAksiyonlar.map((aksiyon, i) => `${i+1}. ${aksiyon}`).join('\n')}
    `;
  }
}

Maliyeti Ne Belirler#

Observability harcamasını saklama süresi, sampling oranı ve kardinalite belirler; üçü de sizin verdiğiniz kararlardır. Saklama süresi, ne kadar trace depolaması ödeyeceğinizi belirler. Sampling oranı, trafiğin ne kadarının depolamaya ulaştığını belirler. Kardinalite sorgu katmanının maliyetini belirler; trace’leri değerli kılan iş öznitelikleri de (kullanıcı seviyesi, kampanya ID’si, sepet değeri) tam olarak kardinaliteyi yükselten alanlardır.

Faturayı hangi kaldıracın hareket ettirdiği, hangi birim üzerinden faturalandığınıza bağlı ve yaygın dört satıcı dört farklı birim seçmiş. AWS trace başına faturalandırıyor: CloudWatch fiyatlandırma sayfası US East (N. Virginia) bölgesinde X-Ray’i kaydedilen trace başına 0,000005 USD olarak listeliyor, yani milyon başına 5,00 USD, üstelik ayda ilk 100.000 trace ücretsiz. Datadog host başına artı indekslenen span başına faturalandırıyor: APM yıllık fiyatlandırmada host başına aylık 31 USD ve host başına ayda 150 GB span ingestion ile 1 milyon indekslenen span içeriyor, sonrası GB başına 0,10 USD. Grafana Cloud GB başına faturalandırıyor: 13 Şubat 2026 ve sonrasında başlayan müşteriler için Application Observability belgeleri host saati başına 0,025 USD ve trace, log ve profiller için GB başına 0,50 USD listeliyor, dahil telemetri yok. Honeycomb event başına faturalandırıyor: ücretsiz planda ayda 20 milyon event, Pro ise 50 milyon event için 150 USD’den başlıyor.

Tek bir değişikliği bu birimlerden geçirdiğinizde cevaplar ayrışıyor. On Datadog APM host’u ayda 310 USD tutar ve 1.500 GB ile 10 milyon indekslenen span hakkı taşır; span hacmini 1.200 GB’tan 600 GB’a indirmek hiçbir şey kazandırmaz, çünkü iki rakam da hakkın içinde kalır. Aynı filoyu 2.000 GB’a çıkarırsanız aşım 500 GB olur ve GB başına 0,10 USD’den 50 USD eder. Aynı biçimde bir yarıya indirme Grafana Cloud’da, GB başına 0,50 USD ile 600 GB’tan 300 GB’a inildiğinde, o kalemi bir sonraki faturada 300 USD’den 150 USD’ye çeker. AWS’te hesap trace başına yürür: kaydedilen 10 milyon trace, ücretsiz kotadan sonra 9,9 milyon faturalanabilir trace bırakır ve 49,50 USD eder. Grafana’nın yeni müşteriler için dahil telemetriyi kaldıran Şubat 2026 değişikliği de birimin, hâlihazırda kullandığınız ürünün altında bile kayabileceğini hatırlatıyor.

Enstrümantasyonun servislerin içinde de bir bedeli vardır: fazladan span, fazladan allocation ve collector’a fazladan trafik demektir. Tail sampling bu bedeli daha da yükseltir; karar verilene kadar trace’leri tutan bileşenler büyük miktarda veriyi kabul edip saklayabilen durum tutan sistemler olmak zorundadır ve OpenTelemetry belgeleri bunların düzinelerce, hatta yüzlerce hesaplama düğümüne çıkabileceği uyarısını yapar. Collector filosunu kendi kapasite planı olan bir production altyapısı olarak bütçeleyin.

Pratik Uygulama Stratejileri#

Hangi aracı seçtiğinizden daha çok fark yaratan üç karar var:

Tek Bir Kullanıcı Yolculuğuyla Başlayın#

Her şeyi bir anda enstrümente etmek geniş ama sığ bir kapsam üretir ve hiçbir soruya cevap vermez. En çok değer taşıyan yolculuğu seçin (genelde checkout ya da kayıt akışı) ve onu baştan sona enstrümente edin:

# Her yerde değil, buradan başla
oncelik_instrumentasyon:
  faz_1:
    - kullanici_kayit_akisi
    - checkout_sureci
    - arama_satin_alma
  
  faz_2:
    - admin_operasyonlari
    - arka_plan_isleri
    - ucuncu_parti_entegrasyonlar
  
  faz_3:
    - dahili_araclar
    - raporlama_sistemleri
    - geri_kalan_her_sey

Faturalama Birimine Göre Sampling#

Ölçekte sampling opsiyonel değil ve agresif oranlar kulağa geldiği kadar çok şey kaybettirmiyor. OpenTelemetry’nin sampling belgeleri, yüksek hacimli sistemlerde %1 ya da daha düşük bir sampling oranının kalan %99’luk veriyi oldukça doğru temsil etmesinin hayli yaygın olduğunu söylüyor. Bu azaltmanın ne kazandırdığı ise yukarıdaki faturalama birimine bağlı: trace başına ya da GB başına fiyatlandırmada kazanç bir sonraki faturaya yansır, host başına fiyatlandırmada ise ancak dahil hakkı aştıysanız yansır.

class AkilliSampling {
  sampleOraniAl(span: Span): number {
    // Hataları ve yüksek değerli işlemleri her zaman örnekle
    if (span.status === 'ERROR') return 1.0;
    if (span.attributes['kullanici.seviye'] === 'premium') return 1.0;
    if (span.attributes['is.deger'] > 1000) return 1.0;
    
    // İş saatlerine göre örnekle
    const saat = new Date().getHours();
    if (saat >= 9 && saat <= 17) return 0.1;  // İş saatlerinde %10
    
    // Sessiz dönemlerde minimal örnekleme
    return 0.01; // Gece %1
  }
}

Trace Okumak Pratik İster#

Enstrümantasyon kodu, herhangi bir pull request gibi gözden geçirilir. Canlı bir incident sırasında trace okumak aynı provadan geçmez; çoğu ekip bu beceriyi ilk kez gerçek bir incident sırasında dener.

Anlatının Kırıldığı Yerler#

Kimsenin Açmadığı Dashboard’lar#

Panel enflasyonu, dashboard’ın önce geldiği bir observability yaklaşımının doğal sonucudur: her incident’tan sonra bir board eklenir, neredeyse hiçbiri silinmez. Ayakta kalanlar, kullanıcıyı landing sayfasından satın almaya kadar izleyen ve her adımı hareket ettirdiği iş metriğiyle açıklayanlardır.

İş Bağlamı Olmayan Trace’ler#

Daha fazla telemetri toplamak bir incident’ı nadiren cevaplanabilir kılar. Trace’leri iş olaylarına bağlamak kılar. Span’lara campaign_id ve promo_code özniteliklerini ekleyin; “en büyük pazarlama kampanyası sırasında dönüşüm neden düştü?” sorusu bir araştırma olmaktan çıkıp bir sorguya dönüşür.

Kirli Telemetriyle AI’a Güvenmek#

AI destekli analiz, okuduğu trace’lerin kalitesini devralır. Tutarsız span isimleri, kopuk parent bağlantıları ve servisten servise farklı anlama gelen öznitelikler kendinden emin saçmalıklar üretir. Önce enstrümantasyon kurallarını düzeltin.

Kalıcı İlkeler#

Araç seçiminden bağımsız olarak bunlar ayakta kalıyor:

1. İş sonuçlarıyla başla. Önce gelir üreten yolları enstrümente etmek, geniş altyapı kapsamından daha hızlı geri dönüş sağlar.

2. Nicelikten çok trace kalitesine yatırım yap. Her şey için vasat trace’lerden ziyade kritik yollar için mükemmel trace’lere sahip olmak daha iyi.

3. Araçlardan önce ekip kültürü oluştur. Ekip anlattığı hikayeleri nasıl okuyacağını bilmiyorsa, en iyi observability stack’i işe yaramaz.

4. Büyümeyi span sayısı üzerinden planla. Yeni enstrümente edilen her servis, zaten var olan yollardaki span sayısını katlar; trace hacmi trafikten daha hızlı büyür. Saklama ve sampling’i bu eğriye göre ayarla, yoksa yeniden mimari bedelini sonra ödersin.

Gelecek Yönelimler#

Grafana Labs Observability Survey 2026, 76 ülkeden 1.363 uygulayıcıya yeni nesil araçlardan ne beklediklerini sordu.

Tahmine Dayalı Hikayeler#

Katılımcıların %92’si, AI’ın sorunları kesintiye yol açmadan önce yüzeye çıkarmasını değerli buluyor. Bu rakam iştahı anlatıyor. Tahminin işe yarayıp yaramadığı ayrı bir soru ve yukarıdaki kök neden araştırması buna sert bir cevap veriyor: olay çoktan elde varken bile, notlandırılan tahminler en iyi ihtimalle %39 oranında doğru çıktı.

Sahada gerçekten çalışan tahmin ise aritmetik. Hata bütçesi tüketim hızı, bütçenin ne zaman biteceğini söyler ve Google SRE Workbook tabloyu yayımlıyor. 30 gün üzerinden ölçülen %99,9 erişilebilirlik SLO’suna karşı, tüketim hızı 1 iken (%0,1 hata oranı) bütçe 30 günde, 2 iken 15 günde, 10 iken (%1 hata oranı) 3 günde, 1.000 iken (tam kesinti) 43 dakikada tükeniyor. Workbook’un başlangıç için önerdiği yapılandırma, 1 saatlik uzun pencere ve 5 dakikalık kısa pencerede tüketim hızı 14,4’e ulaştığında çağrı atıyor; bu, bütçenin %2’sinin harcanmasına denk geliyor. 6 saatlik ve 30 dakikalık pencerelerde tüketim hızı 6 olduğunda yine çağrı atıyor (%5); 3 günlük ve 6 saatlik pencerelerde tüketim hızı 1 olduğunda ise ticket açıyor (%10).

Ticari tahminleme de aynı ölçekte çalışıyor. Datadog’un forecast monitor’leri alarm öngörü süresini 12 saat ile 3 ay arasında ayarlamanıza izin veriyor; hazır seçenekler 24 saat, 1 hafta ve 1 ay. Mevsimsel algoritma en az iki sezonluk geçmiş istiyor ve tahminleme için en fazla altı sezon kullanıyor. Sahadaki hiçbir ürün belirli bir işlemin saniyeler sonra başarısız olacağını öngörmüyor. Üzerine aksiyon alınabilir bir tahmin anlatısı, diskin önümüzdeki salı dolacağını ya da hata bütçesinin perşembe öğleden sonra biteceğini söyler.

İş Öncelikli Instrumentation#

Yeni nesil observability, iş KPI’larından başlayıp onları destekleyen teknik metrikleri türetiyor.

Otonom Müdahale#

Bunun dar kapsamlı sürümleri şimdiden sahada: sorunu tespit edip bilinen bir olay imzasıyla eşleştiren ve kayıtlı müdahaleyi uygulayan sistemler (pod’u yeniden başlatmak, deploy’u geri almak, bir node’u devre dışı bırakmak). Daha genişine duyulan istek gerçek ama netleşmiş değil. Aynı Grafana anketinde katılımcıların %77’si AI’ın otonom aksiyon almasını değerli bulurken %15’i AI’ın uygulama yapmasına hiç güvenmediğini söylüyor. Yukarıdaki araştırmada elle notlandırılmış tahminlerdeki doğruluk en fazla %39’a çıkıyor; dolayısıyla savunulabilir sınır, otomasyonun yalnızca geri alınması ucuz olan yerlerde aksiyon almasına izin vermek.

Uygulama Adımları#

İşe yarayan bir sıralama:

1. Bir kritik kullanıcı yolculuğu seçin ve OpenTelemetry ile baştan sona enstrümente edin
2. Her span’a iş bağlamı ekleyin: kullanıcı seviyesi, gelir etkisi, dönüşüm aşaması
3. Tam bir kullanıcı yolculuğunu gösteren ilk hikaye odaklı dashboard’unuzu oluşturun
4. AI analizini ham prompt yerine getirilmiş geçmiş olayların üzerine kurun ve cevaplarına güvenmeden önce notlandırın
5. Trace okumayı ekip alışkanlığı yapın: düzenli bir oturumda biri yakın tarihli bir incident trace’ini baştan sona anlatsın

Kaynaklar#

• Observability primer - opentelemetry.io (yeni sekmede açılır) - OpenTelemetry’nin observability tanımı ve üç telemetri sinyali olarak trace, metrik ve loglar arasındaki ilişki
• Sampling - opentelemetry.io (yeni sekmede açılır) - Head ve tail sampling’in nasıl çalıştığı, %1’lik bir oranın kalan trafiği neden temsil edebildiği ve tail sampling’in collector filosundan ne istediği
• Observability 2.0 - Honeycomb (yeni sekmede açılır) - Charity Majors’ın metrik dashboard’larının ötesine geçerek yüksek kardinaliteli, olay odaklı observability’ye geçiş argümanı
• Alerting on Service-Level Objectives - Google SRE Workbook (yeni sekmede açılır) - Hata bütçesi alarmlarının arkasındaki tüketim hızı tabloları: tüketim hızına göre bütçenin ne zaman biteceği ve önerilen çok pencereli alarm parametreleri
• Exploring LLM-based Agents for Root Cause Analysis - Roy ve ark. (yeni sekmede açılır) - LLM ajanlarını 107.000 production olayı üzerinde notlandıran Microsoft çalışması; yöntem başına doğruluk ve halüsinasyon oranlarıyla
• Automatic Root Cause Analysis via Large Language Models for Cloud Incidents - Chen ve ark. (yeni sekmede açılır) - RCACopilot makalesi (EuroSys ‘24); sonucun ne kadarının modelden değil, benzer geçmiş olayların getirilmesinden geldiğini gösteriyor
• RCAEval: A Benchmark for Root Cause Analysis of Microservice Systems with Telemetry Data (yeni sekmede açılır) - 735 hata vakası ve 15 temel çizgi içeren nötr kıyaslama; mevcut kök neden yöntemlerinin gerçekte nerede durduğuna dair açık sözlü bir özet
• So We Shipped an AI Product. Did it Work? - Honeycomb (yeni sekmede açılır) - Bir observability ürününün içinde çalışan LLM sorgu asistanı için birinci elden benimsenme, gecikme ve maliyet rakamları
• How we built an AI SRE agent - Datadog (yeni sekmede açılır) - Olay araştırması yapan bir ajanın satıcı anlatımı; çözüm süresi iddiası ve kıyaslamasının neyi raporlamadığı için kaynak
• Grafana Labs Observability Survey 2026 (yeni sekmede açılır) - 76 ülkeden 1.363 uygulayıcıyla yapılan anket; alert yorgunluğu, araç maliyeti ve sahanın AI’ı nerede istediği başlıklarını kapsıyor
• Forecast Monitors - Datadog dokümantasyonu (yeni sekmede açılır) - Tahmine dayalı monitor’lerin yapılandırma referansı: desteklenen alarm öngörü süreleri ve her algoritmanın istediği veri
• Amazon CloudWatch fiyatlandırması (yeni sekmede açılır) - X-Ray trace’leri ve Transaction Search span’leri için liste fiyatları; maliyet bölümünde kullanılan trace başına faturalama modeli
• Datadog fiyatlandırması (yeni sekmede açılır) - APM liste fiyatları, host başına faturalama modeli ve her host ile birlikte gelen span ingestion ve indekslenen span hakları
• Application Observability fiyatlandırması - Grafana Cloud (yeni sekmede açılır) - Trace, log ve profiller için GB başına fiyatlar ve yeni müşteriler için dahil telemetriyi kaldıran Şubat 2026 değişikliği
• Honeycomb fiyatlandırması (yeni sekmede açılır) - Maliyet karşılaştırmasında kullanılan ücretsiz ve Pro plan event hakları ile event başına faturalama modeli

Hikaye odaklı observability en çok, olayların veriye yansıyan iş sonuçları doğurduğu sistemlerde işe yarıyor (gelir düşüşleri, dönüşüm kayıpları, kullanıcı davranışıyla korelasyon gösteren SLO ihlalleri). Yalnızca dahili olan, iş metriği bağlanabilecek bir yüzü olmayan servislerde bu yaklaşım yeterince karşılık vermiyor. Temel alarmların henüz oturmadığı ekiplerde ise önce orayı düzeltmek gerekiyor.