Kurumsal sistemlerde sorunlar çoğu zaman tek bir alarmla başlamaz. Sipariş akışı yavaşlar, mobil uygulamada bazı kullanıcılar hata alır, API yanıt süreleri 300 ms seviyesinden 2 saniyenin üstüne çıkar; ancak klasik izleme panelleri yalnızca CPU ya da bellek artışını gösterir. Tam da bu noktada şu soru önem kazanır: observability nedir ve monitoring yaklaşımından neden farklı ele alınmalıdır?

Monitoring, önceden tanımlanmış metrikleri ve eşikleri izler. Yani “neyi takip edeceğinizi” en baştan bilmeniz gerekir. Observability ise sistemin iç durumunu, dışarıya ürettiği sinyaller üzerinden anlamayı amaçlar. Bu sinyaller genellikle üç ana grupta toplanır: metrikler, loglar ve trace verileri. Aradaki fark yalnızca veri türünde değildir; asıl fark, bilinmeyen bir problemi araştırabilme kapasitesinde ortaya çıkar.

Özellikle mikroservis mimarisi, Kubernetes, çoklu bulut, olay tabanlı entegrasyonlar ve yoğun API trafiği barındıran yapılarda yalnızca dashboard izlemek yeterli olmaz. Mesele sadece “sistem çalışıyor mu?” sorusu değildir. Asıl ihtiyaç; “neden yavaşladı, hangi serviste başladı, hangi kullanıcı akışını etkiledi, veritabanına mı yoksa dış servise mi dayandı?” gibi sorulara dakikalar içinde yanıt verebilmektir.

Observability nedir? Temel tanım ve pratik anlamı

Observability, bir sistemin iç durumunu, ürettiği telemetri verileri üzerinden anlamlandırma ve açıklayabilme yeteneğidir. Yazılım ekipleri açısından pratik karşılığı şudur: bilinmeyen bir arıza senaryosunda, yeni bir dashboard tasarlamadan ya da yeni kod eklemeden, mevcut verilerle teşhis koyabilmek.

Örneğin 14:05’te ödeme servisinde hata oranı %0,4’ten %6 seviyesine çıktıysa monitoring size alarm verebilir. Ancak observability yaklaşımı, aynı dakikada şu ayrıntıları da görünür kılar: yalnızca Android istemciler etkilenmiş olabilir, hata belirli bir /payment/confirm endpoint’inde yoğunlaşabilir, root cause ise bir banka entegrasyonunda 30 saniyelik timeout artışı olabilir. Burada asıl değerli olan, semptomu görmek değil; ilişki ağını çözebilmektir.

Bu yaklaşım özellikle şu tip yapılarda belirgin avantaj sağlar:

  • 20’den fazla mikroservis içeren dağıtık mimariler
  • Gün içinde binlerce veya milyonlarca istek alan B2B ve SaaS platformları
  • ERP, CRM, e-ticaret, lojistik ve ödeme sistemleri arasında API bağımlılığı bulunan kurumsal altyapılar
  • CI/CD ile haftada birden fazla üretim yayını yapılan ekipler

Monitoring ve observability neden aynı şey değildir?

Monitoring ile observability çoğu zaman aynı başlık altında anılır; fakat kullanım amaçları farklıdır. Monitoring daha çok bilinen sorunlara karşı görünürlük sağlar. CPU %85’i geçerse alarm üretmek, disk doluluk oranını izlemek, HTTP 5xx hata sayısını takip etmek klasik monitoring örnekleridir.

Observability ise önceden tanımlanmamış sorulara yanıt üretmeye odaklanır. Başka bir deyişle monitoring, “beklenen sinyalleri” izler; observability ise “beklenmeyen davranışı” araştırır.

Monitoring’in güçlü olduğu alanlar

  • Uptime kontrolü: 1 dakika aralıkla servis erişilebilirliğini doğrulamak
  • Kapasite takibi: CPU, RAM, disk, ağ kullanımı
  • Eşik bazlı alarm üretimi: örneğin yanıt süresi 500 ms üstüne çıktığında uyarı vermek
  • SLA/SLO görünürlüğü: hata bütçesi ve servis seviyesi takibi

Observability’nin gerekli olduğu alanlar

  • Bir isteğin 7 servis arasında geçtiği dağıtık akışı çözümlemek
  • Aynı hatanın yalnızca belirli tenant, müşteri grubu veya uygulama sürümünde oluştuğunu bulmak
  • Yük artışı olmadan performans düşüşü yaşandığında kök nedeni ortaya çıkarmak
  • Log, metrik ve trace verisini tek bir bağlamda birleştirmek

Kurumsal ölçekte ikisinden birini seçmek gerekmez. Sağlıklı yaklaşım, monitoring’i operasyonel erken uyarı sistemi; observability’yi ise teşhis ve öğrenme katmanı olarak konumlamaktır.

Kurumsal sistemlerde neden yalnızca alarm yetmez?

Tek bir örnek üzerinden ilerleyelim. 50 bayinin kullandığı bir B2B sipariş platformunda kullanıcılar, saat 16:20 sonrası “sipariş tamamla” adımında yavaşlık bildiriyor. Monitoring panelinde web sunucuları ayakta, CPU kullanımı %55, RAM normal, veritabanı bağlantı sayısı sınırın altında. İlk bakışta kritik bir işaret görünmüyor.

Trace verisi açıldığında tablo değişiyor: isteğin toplam süresi 4,8 saniye. Bunun 3,9 saniyesi dış kargo entegrasyonuna giden çağrıda harcanıyor. Log korelasyonu ile aynı anda şu hata satırları görülüyor: timeout after 4000ms partner-carrier-api. Metriklerde ise hata oranı yalnızca %1,2. Yani alarm eşiği belki henüz aşılmadı; ama kullanıcı deneyimi ciddi biçimde bozulmuş durumda.

Bu senaryoda monitoring “bir şeyler ters gidiyor olabilir” der. Observability ise “sorun şu entegrasyonda, şu endpoint’te, şu zaman aralığında, şu müşteri segmentini etkiliyor” diyebilir. Müdahale süresi açısından fark büyüktür. Dakikalar ile saatler arasındaki çizgi çoğu zaman burada çizilir.

Özellikle MTTR yani ortalama çözüm süresi üzerinde bu yaklaşımın etkisi nettir. Her kurum kendi ölçümünü yapmalıdır; ancak pratikte bağlamı zengin telemetri üreten sistemlerde olay inceleme süresi belirgin biçimde kısalır. Burada önemli olan, rastgele daha fazla veri toplamak değil; sorgulanabilir, ilişkilendirilebilir veri toplamaktır.

Observability’nin temel bileşenleri: metrik, log, trace

Observability altyapısı çoğu ekipte üç veri sınıfı üzerine kurulur. Her birinin rolü farklıdır; gerçek değer ise birlikte kullanıldıklarında ortaya çıkar.

Metrikler

Zamana bağlı sayısal ölçümlerdir. Örnekler: istek sayısı, p95 yanıt süresi, hata oranı, queue uzunluğu, JVM heap kullanımı. Metrikler düşük maliyetlidir ve hızlı çalışır. Bu nedenle dashboard ve alarm katmanında oldukça etkilidir.

Örneğin bir serviste p95 latency’nin 220 ms’den 780 ms’ye çıktığını görmek, sorunun varlığını erken fark ettirir. Fakat nedenini tek başına açıklamaz.

Loglar

Olay bazlı kayıtlar sunar. Hata mesajı, stack trace, iş kuralı sonucu, kullanıcı veya tenant bağlamı burada yer alabilir. Yapısal log kullanımı kritik önemdedir. Serbest metin yerine JSON log tercih etmek, filtreleme ve korelasyon kalitesini artırır.

Kısa bir örnek:

{
  "timestamp": "2026-07-16T14:05:22Z",
  "service": "order-api",
  "trace_id": "8fd2a1",
  "tenant_id": "bayi-42",
  "endpoint": "/orders/complete",
  "duration_ms": 4120,
  "error": "carrier_timeout"
}

Trace verisi

Dağıtık sistemlerde bir isteğin geçtiği tüm adımları gösterir. Bir kullanıcı isteği API gateway’den başlayıp kimlik doğrulama, sipariş servisi, stok servisi, ödeme servisi ve üçüncü parti entegrasyonlardan geçebilir. Trace, bu zinciri span seviyesinde görünür hale getirir.

Örneğin toplam 2,4 saniyelik isteğin 1,7 saniyesinin veritabanı sorgusunda mı, Redis beklemesinde mi, dış API’de mi geçtiğini trace olmadan güvenle söylemek zordur. Mikroservis sayısı 8’i, 10’u geçtiğinde bu veri türü artık lüks olmaktan çıkar.

Kök neden analizi için doğru yaklaşım nasıl kurulur?

Kök neden analizi, tek başına bir araç seçimi değildir. Veri modeli, enstrümantasyon disiplini ve operasyon süreci birlikte ele alınmalıdır. Kurumsal yapılarda işe yarayan yaklaşım genellikle şu adımları içerir:

1. Kritik kullanıcı akışlarını belirleyin

Her şeyi aynı derinlikte gözlemlemek maliyetli olduğu kadar gereksiz de olabilir. Önce iş açısından kritik 5-10 akışı seçin: giriş, sipariş oluşturma, ödeme, teklif onayı, fatura üretimi, dosya yükleme gibi. Telemetriyi bu akışlara göre şekillendirin.

2. Korelasyon kimliği zorunlu olsun

Her isteğe bir trace_id veya correlation_id eklenmesi ciddi fark yaratır. Bir destek kaydında yalnızca zaman bilgisiyle arama yapmak yerine, tek bir kimlikle log, trace ve hata kaydına ulaşabilirsiniz.

3. Altın sinyalleri ölçün

Pek çok ekip dört temel sinyali izler: latency, traffic, errors, saturation. İsimler değişebilir; mantık değişmez. Her kritik servis için en azından p95 yanıt süresi, istek hacmi, hata oranı ve kaynak baskısı görünür olmalıdır.

4. SLO odaklı alarm üretin

Her metrik alarm üretmemelidir. Gece 03:00’te ekibi uyandıracak uyarıların iş etkisi net olmalıdır. Örneğin CPU %80 oldu diye değil, son 10 dakikada ödeme başarı oranı %99,5 hedefinin altına indi diye alarm üretmek daha anlamlıdır.

5. Dağıtık tracing’i kritik zincire uygulayın

Tüm sistemi ilk günden eksiksiz instrument etmek şart değildir. En çok gelir etkisi olan veya en fazla entegrasyon içeren akıştan başlamak daha gerçekçidir. 3 servisten 12 servise çıkan bir platformda bu karar ciddi zaman kazandırır.

Araçlardan önce mimari ve veri disiplini gelir

Observability konuşulurken araç isimleri hızla öne çıkar: OpenTelemetry, Prometheus, Grafana, Elasticsearch, Loki, Jaeger, Tempo, Datadog, New Relic ve benzeri platformlar. Bunların her biri belirli ihtiyaçlara yanıt verir. Yine de asıl mesele ürün seçimi değildir.

Log standardı zayıfsa, etiketleme eksikse, servis isimleri tutarsızsa ve trace verisi ilişkilendirilemiyorsa en pahalı platform bile beklenen sonucu vermez. Tersine, iyi modellenmiş telemetri ile açık kaynak tabanlı bir kurulum da oldukça etkili olabilir.

Özellikle OpenTelemetry son yıllarda önemli bir ortak katman haline geldi. Tek bir vendor’a bağımlı olmadan metrik, log ve trace üretimini standartlaştırmak isteyen ekipler için güçlü bir çerçeve sunuyor. Kurum içinde Java, .NET, Node.js ve Python servisleri birlikte çalışıyorsa bu tür standartlar entegrasyon yükünü azaltır.

Türkiye’deki kurumsal ekipler için uygulanabilir bir başlangıç planı

Bir observability programı devasa bir dönüşüm projesi olmak zorunda değil. İlk 30-60 gün içinde ölçülebilir bir başlangıç yapılabilir.

  • İlk 2 hafta: kritik servis envanteri çıkarılır, mevcut log ve metrik kaynakları listelenir
  • 3-4. hafta: correlation ID standardı belirlenir, 2 kritik iş akışına trace eklenir
  • 2. ay: p95 latency, hata oranı ve başarı oranı için SLO bazlı paneller kurulur
  • Aynı dönemde: alarmlar sadeleştirilir, gürültü üreten kurallar temizlenir

Bu planın çıktısı kısa sürede hissedilir: destek ekipleri daha az belirsizlik yaşar, yazılım ekipleri olay incelemesinde daha hızlı hareket eder, iş birimleri de “sistem yavaş” gibi genel ifadeler yerine somut servis ve zaman aralığı üzerinden konuşabilir.

Sonuç: Monitoring görünürlük sağlar, observability açıklama gücü kazandırır

Monitoring olmadan temel operasyon yönetimi zayıf kalır. Observability olmadan ise dağıtık ve hızla değişen sistemlerde kök neden analizi yavaşlar. Kurumsal yapılarda doğru yaklaşım, bu iki kavramı rakip gibi görmek değil; farklı katmanlar olarak değerlendirmektir.

Observability nedir sorusunun en net yanıtı şudur: sistemin yalnızca çalışıp çalışmadığını değil, neden beklenen gibi davranmadığını da anlamayı mümkün kılan mühendislik yaklaşımıdır. Özellikle özel yazılım, çoklu entegrasyon ve bulut tabanlı mimarilerde bu yaklaşım; daha hızlı hata tespiti, daha güvenilir performans takibi ve daha isabetli kök neden analizi için güçlü bir temel sunar.