Yazılım Performans İzleme ve Observability: Operasyonel Rehber [2026]

Monitoring ve Observability: Aynı Şey Midir?

Çok sık, "monitoring" ve "observability" birbirinin yerine kullanılır. Ancak fark vardır ve fark, işletme sonuçlarını etkileyebilir.

Monitoring: Sistemde sabit noktalar kontrol etmek. "Sunucunun CPU'su yüzde 80 mi?" "Veritabanı tepki süresi 500ms'yi aştı mı?" Bu sorulara yanıt vermek, monitoring'dir. Sorunun ne olduğunu biliyorsunuz, sadece kontrol ediyorsunuz.

Observability: Sistemin "iç durumunu" anlamak. Bir hata oluştuğunda, onun sebebini bulmak için yeterince veri toplamak. Reakif değil, proaktif.

Örnek: Müşteri, "Sistem yavaş" şikayeti yapıyor. Monitoring size, sunucunun CPU'nun normal, bellek normal olduğunu söyler. Ama neden yavaş?

Observability, loglara, metriklere, izlemelere bakarak şu soruya yanıt verir: Hangi kod satırı yavaş? Hangi veritabanı sorgusu uzun? Hangi harici API çağrısı gecikti?

Modern yazılım yönetimi, ikisini de gerektirir. Monitoring, sorunları tespit eder. Observability, sebeplerini ortaya koymaya yardımcı olur.

Observability'nin Üç Ayağı

Etkili observability, üç tür veri toplamaya dayanır: Loglar, Metrikler ve İzlemeler.

Loglar (Logs)

Sistem, belirli olayları kaydeder: "Kullanıcı giriş yaptı", "Veritabanı sorgusu başladı", "Hata oluştu: Bağlantı timeout".

Loglar, kesintisiz bir tarih kaydıdır. "Saat 14:32'de ne oldu?" sorusuna yanıt verirler. Detaylı ve tarihsel.

Avantaj: Çok detaylı, belirli olayların tam izini verir.
Dezavantaj: Hacim çok. Her işlem, duzine yada yüzlerce log oluşturur. Saklanması ve aranması yoğundur.

Araç Örnekleri: ELK Stack (Elasticsearch, Logstash, Kibana), Splunk, DataDog, CloudWatch

Metrikler (Metrics)

Sistemin sayısal değerlerinin zaman içinde kaydı. Örneğin: CPU %, Bellek MB, Yanıt Süresi ms, İstek Sayısı/Saniye, Hata Oranı %.

Metrikler, trendleri görmek için iyi. "Son 1 saat'te CPU nasıl değişti?" "Bu hafta hata oranı arttı mı?" soruları metriklerle yanıtlanır.

Avantaj: Küçük hacim, depolanması kolay, hızlı sorgulama, trendler açık.
Dezavantaj: Detay az, "neden CPU yüksek?" sorunu yanıtlamaz.

Araç Örnekleri: Prometheus, Grafana, DataDog, New Relic, CloudWatch

İzlemeler (Traces)

Bir isteğin sistemden geçişinin adım adım kaydı. Örneğin, kullanıcı satış yapıyor. İstek, web sunucusuna giriyor, ödeme modülüne çağrı yapıyor, veritabanında yazdı, e-posta gönderdi. Her adım, ne kadar sürdü? Hangisi yavaştı?

Avantaj: Dağıtık sistemlerde, isteğin tüm yolunu görmek.
Dezavantaj: Karmaşık setup, yüksek hacim, öğrenme eğrisi.

Araç Örnekleri: Jaeger, Zipkin, DataDog, New Relic, AWS X-Ray

APM Araçları: Hangi Seçmelisiniz?

APM (Application Performance Monitoring) araçları, observability'nin merkezinde yer alır. Birkaç popüler seçenek:

DataDog

Eksiksiz bir bulut izleme platformu. Logs, metrikler, izlemeler, uyarılar hepsi bir yerde.

Avantaj: Çok capabilty, kullanması kolay, şık dashboard, iyi entegrasyonlar.
Dezavantaj: Maliyetli (Veriye göre ücretlendirilir), başlangıçta öğrenme eğrisi.

Ne Zaman Kullanılır: Kurumsal ortamlar, karmaşık mimariler, bütçesi açık.

New Relic

Geleneksel APM aracı, performansa odaklı.

Avantaj: Sürü'ye iyi, alert mekanizması kuvvetli, eğitim kaynakları bol.
Dezavantaj: Log yönetimi ekstra ücretli, başlangıçta pahalı.

Ne Zaman Kullanılır: Java, .NET ortamları, performans odaklı kuruluşlar.

Grafana Stack (Prometheus + Grafana)

Açık kaynaklı, ücretsiz seçenek.

Avantaj: Ucuz (self-hosted), kontrol sahibi, esneklik.
Dezavantaj: Kurulum ve yönetim maliyeti, log yönetimi ayrı araç (Loki), destek sınırlı.

Ne Zaman Kullanılır: Küçük/orta boylu şirketler, teknoloji öğrenme kurumları, self-hosted tercihçileri.

AWS CloudWatch

Amazon'un dahili monitoring hizmeti.

Avantaj: AWS ile entegre, basit kuruluşlar için yeterli, kullanımı kolay.
Dezavantaj: Sınırlı yetenekler, log yönetimi maliyetli, AWS dışı sistemler zayıf.

Ne Zaman Kullanılır: AWS milyve ağırlıklı şirketler.

Elastic Stack (ELK)

Açık kaynaklı, log yönetim odaklı.

Avantaj: Güçlü log analitik, esneklik, büyümeye uyum sağlıyor.
Dezavantaj: Kurulum karmaşık, yönetim maliyetli, APM sınırlı.

Ne Zaman Kullanılır: Log odaklı kuruluşlar, büyük veri hacimleri.

Seçim, mimarinize, bütçenize ve operasyonel yeteneklere bağlıdır. Küçük başlayıp, büyüdükçe araç yükseltmek yaygındır.

Alarm Yönetimi: Doğru Uyarıları Ayarlamak

Monitoring araçları, litre veri toplar. Ancak yanlış alarm ayarı, iki soruna yol açabilir:

Çok Fazla Alarm: Operasyon ekibi, her gün yüzlerce alarm alırsa, burnout olur. Uyarıları görmezden gelmeye başlarlar. Gerçek sorun, sahte uyarılar arasında kaybolur.

Yeterli Olmayan Alarm: Sorunlar, çok geç tespit edilir. Müşteri şikayeti yoluyla öğrenilir.

Etkili alarm yönetimi, balans gerektirir.

Alarm Türleri

Threshold Bazlı: CPU % 80'den yüksekse, uyarı ver. Basit ama yanıltıcı olabilir.

Anomali Bazlı: Normal trafikle karşılaştırarak, anormal davranışı tespit. Örneğin, "Hatalar her zaman yüzde 0,1 ama şimdi yüzde 5, bu anormal."

Bileşik: Birkaç metriki birleştirerek, daha akıllı karar. Örneğin, "CPU yüksekse VE hata oranı yüksekse, alarm ver (sadece CPU değil)."

Alarm Ayarlama Pratikleri

1. Müşteri Etkisine Odaklan: SLA ihlali yapabilecek sorunlara odaklan. CPU yüzde 85 değil, yanıt süresi 5 saniye'yi aştı mı.

2. Severite Seviyeleri: "Critical" alarm, derhal müdahale gerektirir. "Warning" bilgi için yeterlidir. "Info" sadece log.

3. Runbook Bağlantısı: Alarm tetiklediğinde, operatör ne yapmalı? Alarm, sorun tanımı ve ilk adımlar içermelidir.

4. Escalation Kuralları: 5 dakika cevap olmadıysa, yöneticiye let. Alarm, eğer işlemci uykudaysası ne yapılacağını tanımlamalıdır.

5. Alert Fatigue Azaltma: Çok alarm, görmezden gelinir. Alarm eşiğini yükseltmeyi düşün, daha az ama önemli alarm, daha iyidir.

SLO, SLI, SLA: Üçlü İlişki

Bu üç terim, observability'nin amaçlanı belirler.

SLI (Service Level Indicator): Ölçülebilir bir metrik. Örneğin, "İsteklerin yüzde 99,5'i 200ms'de cevap aldı." "System uptime yüzde 99,9."

SLO (Service Level Objective): Hedefimiz. "SLI'mız en az yüzde 99.5 olmalı." "Uptime hedefi yüzde 99.9 olsun."

SLA (Service Level Agreement): Müşteriye verilen söz. "Yazılım, yüzde 99.9 uptime'da çalışacak, aksi takdirde size kredi vereceğiz."

Bu üçlü, observability'nin yön gösterir. Hangi metrik ölçmeli? SLO'leriniz. Alarm nerede ayarlanmalı? SLA ihlal etmeden önce.

Daha ayrıntı için, SLA Yönetimi rehberimizi okuyun.

Incident Management: Hata Algılandıktan Sonra Ne?

Monitoring, sorun tespit eder. Sonra ne?

Etkili incident management süreci:

1. Algılama: Monitoring, sorun bulur (veya müşteri bildiriyor).
2. Sınıflandırma: Sorunun ciddiyet düzeyi nedir? P1 (kritik), P2 (yüksek), P3 (orta), P4 (düşük)?
3. Eskalasyon: Kimin devreye girmesi gerekir? İlk kontrol eden, ilişki kurabilir mi?
4. Sorun Giderme: Root cause analizi. Sorunu çöz.
5. Kommuniké: Müşteriye, iç ekibe ilerleme hakkında bilgi ver.
6. Çözüm: Sorunun çözümü.
7. Post-Mortem: Neden oldu? Nasıl tekrarlanmaz?

Bu süreci iyi uygulamak, hata süresini (mean time to recovery = MTTR) azaltır.

On-Call Programları: 24/7 Destek

Yazılım, 24 saat çalışırsa, destek de 24 saat gerekebilir. On-call programları, sorunlar oluştuğunda hemen müdahale etmeyi sağlar.

On-Call Rotasyonu: Ekip, haftalar arası sorumluluk alır. Çağrı gelirse, hemen cevap vermesi gerekir.

Uyarı Mekanizması: Telefon, SMS, push bildirim. Alarm tetiklediğinde, on-call kişi anında bildirilir.

Escalation: On-call 30 dakika cevap vermezse, bir üst seviye çağrılır.

Compensate: On-call saatleri, çalışan zamanı yoğun. Ekibiniz burnout'dan korunması için, ek yardım veya para şart.

Downtime Maliyeti: Niçin İzleme Önemli?

Yazılım çalışmıyor diye, sadece müşteri memnuniyeti değil, doğrudan para kaybı:

• E-Commerce: Saatlik milyonlar. Sitesi 1 saat çökmesi, yüzbin dolarlık kayıp.
• SaaS: Müşteriler, kullanamıyor. Operasyonları duruyor.
• Finans: Hata, para transferleri durdurabileceği gibi, kurumsal izinler kaybedebilir.

Araştırmalar gösteriyor: Orta ölçekli kurumda, saatlik downtime maliyeti 100K - 1M USD arasında.

Etkili monitoring ve gözlemcilik, bu maliyetleri azaltır. Sorunlar daha hızlı tespit edilir, daha hızlı çözülür.

Yaygın Monitoring Hataları

Kurumlar, sık sık monitoring'de hata yaparlar:

1. Çok Az Metrik Takip Etme: Sadece CPU ve bellek. Ama müşteri deneyimi, hızlı API yanıt süresi ile ilgili. İş-odaklı metrikler lazım.

2. Alarm Fatigue: Çok fazla alarm, çoğu yanlış. Operatör, burnout. Alarm eşiğini yükselt, kaliteyi artır.

3. Geriye Dönük Bakış: Sorun oluştuktan sonra, logları arama. Değil, sorun olmadan önce tespit et.

4. Log Saklama Yetersiz: Sadece son 1 gün log tutuluyor. Haftalık trendler görülemediği için, sorunun kökü bulunabilir.

5. Silolaşma: Geliştirme ekibi loglara bakmıyor, operasyon bakıyor. İkisi beraber çalışmalı.

Başlangıç: Monitoring Kurulumu

Eğer monitoring'iniz yoksa, nereden başlayacaksınız?

1. Temel Metrikler Seçin: CPU, Bellek, Disk, Ağ. Sonra, Yanıt Süresi, Hata Oranı.

2. Araç Seçin: Bütçe ve mimarinize göre. Açık kaynak ile başlayıp, ihtiyac duyarsa ticari araçlara geçebilirsiniz.

3. Dashboard Oluşturun: İşletme gözüyle, sistem sağlığını gösteren basit dashboard.

4. Temel Uyarıları Ayarla: 3-5 kritik uyarı. Sistem geri kazanabilir.

5. Ekibi Eğit: Monitoring nasıl okunur? Arızada ne yapılır?

6. Evolve Et: Zamanla, more log, trace, anomali tespiti ekleyin.

Başlangıç, karmaşık değil—önemli olan, başlamaktır.

Sonuç: Gözü Kapalı Gitmez

Modern yazılım işletme, observability olmadan yapılamaz. Müşteriden haber almadan önce, sorunu bilmelisiniz. Sorunu tespit edip, hızlı çözmelisiniz.

Etkili performans izleme ve observability, teknik yatırım değil—iş yatırımıdır. Hizmet kalitesini korur, maliyetleri azaltır.

Daha geniş bağlam için, Kurumsal Yazılım Bakım ve Modernizasyon rehberimizi okuyun. SLA Yönetimi, gözlemcilik hedeflerinizin belirlenmesi için önemli.

Yazılımınız için observability yol haritası oluşturmak istiyorsanız, Smart Maple danışmanları yardımcı olabilir. Mevcut durumunuzu değerlendirebilir, uygun araçlar ve süreçler önerebiliriz. Ziyaret edin smart-maple.com adresini daha fazla bilgi için.