Modern SaaS için Gerçek Zamanlı Altyapı İzleme ve Alarm

Eskiden salı öğleden sonra yaşanan bir kesinti, önce bir müşteriden gelen telaşlı bir Slack mesajı, ardından neyin bozulduğunu bulmak için bir koşuşturma, sonra da çoğunlukla "daha iyi izlemeye ihtiyacımız var" diye biten bir olay sonrası değerlendirme (post-mortem) demekti. Döngü kendini tekrarlar. Gerçek zamanlı altyapı izleme bu döngüyü kırar: sorunlar müşteriler fark etmeden görünür hâle gelir, nöbetçi mühendisler çağrıldıklarında bağlama sahip olur ve kök neden analizleri (RCA) saatler yerine dakikalar içinde yapılır.

Bu rehber neyin ölçümleneceğini, ekibin gerçekten harekete geçtiği alarmların nasıl kurulacağını ve reaktif yangın söndürmeden proaktif operasyona nasıl geçileceğini ele alıyor.

İzlememenin Bedeli

Nasıl yapılacağına geçmeden önce, bunun bariz olanın ötesinde neden önemli olduğunu açıkça söylemekte fayda var.

Kesinti maliyeti: Orta ölçekli SaaS şirketleri için plansız kesinti genellikle pahalıdır — kaybedilen gelir, destek yükü ve müşteri kaybı riski hızla birikir. Kurumsal segmentte maliyet çok daha yüksek olabilir. Daha küçük ürünlerde bile her kesinti saati, harcanan müşteri güveni demektir.

MTTR ve MTTD: Ortalama onarım süresi (MTTR), sorunun başladığı andan değil, tespit edildiği andan itibaren işlemeye başlar. 2 dakikada tespit edilip 8 dakikada çözülen bir kesinti, 40 dakika sonra tespit edilip 10 dakikada çözülen bir kesintiden çok daha iyi bir sonuçtur. İzleme öncelikle MTTD'yi (ortalama tespit süresi) kısaltır; bu da çözüm süresi değişmese bile MTTR'yi kısaltır.

Ölçümleme olmadan hata ayıklamak: Metrikler, izler ve loglar olmadan bir üretim olayını teşhis etmek, mekanik bir arızayı hiçbir gösterge ve teşhis aracı olmadan bulmaya çalışmaya benzer. Mümkündür — ama yavaş, hataya açık ve streslidir.

Gözlemlenebilirliğin Üç Temeli

Modern gözlemlenebilirlik (observability), birbirini tamamlayan üç sinyal türü üzerine kuruludur:

Metrikler

Düzenli aralıklarla toplanan sayısal ölçümler: CPU kullanımı, bellek kullanımı, istek hızı, hata oranı, yanıt gecikmesi, kuyruk derinliği, veritabanı bağlantı havuzu kullanımı. Metriklerin saklanması ucuz, sorgulanması hızlıdır; panolar ve eşik tabanlı alarmlar için idealdir.

Temel ayrım: Metrikler size bir şeylerin ters gittiğini söyler; ama her zaman neden ters gittiğini söylemez.

İzler

Dağıtık izler (distributed traces), bir isteği dokunduğu tüm servisler boyunca takip eder — kenardaki gelen HTTP isteğinden kimlik doğrulama ara katmanına, oradan iş mantığı servisine, veritabanına ve geri. Her span (izdeki tek bir adım) zamanlama ve üst veri kaydeder.

İzler, metriklerin yanıtlayamadığı soruları yanıtlar: "Bu API uç noktası yavaş — sorun veritabanı sorgusunda mı, harici API çağrısında mı, yoksa mesaj kuyruğunda mı? Hangi kullanıcının isteği? Hangi SQL sorgusu?" İzler olmadan bu soruları yanıtlamak log'larda grep ve tahmin gerektirir.

Loglar

Yapılandırılmış log kayıtları olayları yakalar: yığın iziyle (stack trace) birlikte bir istisna, tamamlanan bir arka plan işi, çalışan bir veritabanı migration'ı. Loglar en ayrıntılı sinyaldir — ölçek büyüdükçe saklaması pahalıdır, ama uç durumları teşhis etmek için yeri doldurulamaz.

İlke: Tespit etmek için metrikleri, yerini bulmak için izleri, anlamak için logları kullanın.

Neyi Ölçümlemeli

Sunucu ve Altyapı Metrikleri

Her sunucu şunları yaymalıdır:

• CPU: çekirdek başına kullanım, steal time (sanal makinelerde — hipervizör çekişmesine işaret eder)
• Bellek: kullanılan, kullanılabilir, swap kullanımı. Yüksek swap = bellek baskısı; bu da gecikme sıçramalarına yol açar.
• Disk: kullanım, I/O bekleme, okuma/yazma IOPS, boş alan. Diskin dolması, en yaygın ve en kolay önlenebilir kesinti nedenlerinden biridir.
• Ağ: giren/çıkan bayt, bağlantı sayısı, TCP yeniden iletimleri
• Süreç: açık dosya tanımlayıcıları, çalışan iş parçacıkları, süreç başına bellek RSS

Disk dolu alarmlarını öncü süre bırakacak şekilde kurun — %95'te değil, %80 dolulukta alarm verin. Log döndürme (log rotation) başarısız olduğunda ya da kontrolden çıkmış bir süreç diske yazdığında diskler beklediğinizden hızlı dolar.

Uygulama Metrikleri

Uygulama katmanında şunları ölçümleyin:

• İstek hızı: uç nokta ve durum koduna göre ayrıştırılmış saniyedeki istek sayısı. İstek hızındaki bir düşüş, çoğu zaman üst akıştaki bir sorunun ya da bir yönlendirme değişikliğinin ilk işaretidir.
• Hata oranı: uç noktaya göre ayrıştırılmış 4xx ve 5xx. 500'lerdeki bir sıçrama, çağrı bekleyen bir olaydır.
• Gecikme: uç noktaya göre P50, P95, P99. P50 tipik deneyimi gösterir; P99 en kötü %1'i — kurumsal müşteriler kuyruktaki bu gecikmeyi çoğu zaman orantısız biçimde hisseder.
• Kuyruk derinliği ve gecikmesi: Arka plan iş işleyicilerinde (BullMQ, Sidekiq, Celery) kuyruk derinliği öncü bir göstergedir. İşçilerin boşaltabileceğinden hızlı büyüyen bir kuyruk, ya bir şeyin işçileri yavaşlattığı ya da ani bir yük geldiği anlamına gelir.
• Veritabanı: bağlantı havuzu kullanımı (dolmak üzere = istekler kuyruğa giriyor), yavaş sorgu sayısı, okuma replikaları için replikasyon gecikmesi.
• Önbellek isabet oranı: Sık erişilen bir kaynakta önbellek isabet oranının düşmesi veritabanı yükünü aniden artırır — çoğu zaman bir zincirleme çöküşün ilk domino taşıdır.

İş Metrikleri

Uygulama sağlık metrikleri yeşil görünürken iş tarafı bozuk olabilir. Şunları izleyin:

• Başarısız ödeme denemeleri (bir sıçrama ödeme sağlayıcısında bir soruna işaret edebilir)
• Kayıt hunisi tamamlanma oranı (bir düşüş, bozuk bir kayıt akışına işaret edebilir)
• Yeni kullanıcı aktivasyon oranı
• Dışa aktarma işlerinin tamamlanması (kullanıcıların ancak boş bir dosya indirdiklerinde fark ettiği yaygın bir "sessiz arıza")

İş metrikleri sizin erken uyarı sisteminizdir. Ödeme tamamlamalarında %20'lik bir düşüş, CPU'daki bir sıçramadan daha alarm vericidir — CPU iyi görünse bile.

Alarm Tasarımı: İşe Yarayan Çağrının Sanatı

Çok sık çağrı atan izleme sistemleri, görmezden gelinen izleme sistemleridir. Alarm yorgunluğu baş gösterdiğinde nöbetçi mühendisler alarmları geçiştirmeyi öğrenir — ve kritik çağrı da gürültüyle birlikte geçiştirilir.

Nedenlere Değil, Belirtilere Alarm Verin

İç metriklere değil, kullanıcıya yansıyan etkiye göre çağrı atın. "/checkout üzerindeki hata oranı 5 dakika boyunca %5'i aştı" bir belirti alarmıdır — kullanıcıların yaşadığı hatalarla doğrudan ilişkilidir. "CPU %85'te" ise bir neden alarmıdır — sorun yaratıyor olabilir, ya da yoğun yük saatinde beklenen bir toplu iş olabilir.

Neden tabanlı alarmları çağrı olayı olarak değil, bilgilendirme amaçlı (Slack'te düşük öncelikli bildirimler) kullanın.

Önem Seviyeleri

Farklı bildirim yollarına sahip, birbirinden ayrı önem seviyeleri tanımlayın:

Tekilleştirme ve Gruplama

Tek bir altta yatan sorun çoğu zaman onlarca ilişkili alarmı tetikler. Tekilleştirme olmadan nöbetçi tek bir olay için 30 kez çağrılır — ve ilk 10 dakikayı 30 çağrının da aynı sorun olduğunu anlamakla geçirir.

Alarm sisteminizi, ilişkili alarmları servis, zaman penceresi ve alarm kuralına göre gruplayacak şekilde yapılandırın. Her bir tetiklenmeyi değil, grubu sahiplenin.

Runbook'lar

Her P1 ve P2 alarmı bir runbook'a (müdahale kılavuzu) bağlanmalıdır: bu alarmın ne anlama geldiğini, en yaygın nedenlerini ve nöbetçi mühendisin atması gereken ilk 3–5 adımı anlatan bir belge. Runbook sorunu çözmez; nereden başlanacağını bulmak için harcanan zamanı ortadan kaldırarak MTTR'yi kısaltır.

Reaktiften Proaktife: Eğilim Analizi

En yüksek getirili izleme yatırımı, sorunları olaya dönüşmeden önce ortaya çıkaran anomali tespitidir.

Disk büyüme projeksiyonu: Disk kullanımı günde 2 GB artıyorsa ve şu anki boş alan 20 GB ise 10 gününüz var demektir. Şimdi alarm verin. %95'te değil, %80'de alarm verin.

Hata oranı eğilimleri: %0,1 olan ve günde %20 büyüyen bir 5xx hata oranı, sabit %0,5'lik bir orandan daha endişe vericidir. Eğilim tabanlı alarmlar, eşik tabanlı alarmların kaçırdığı kademeli bozulmaları yakalar.

Bellek sızıntısı tespiti: Günler boyunca hiç azalmadan tekdüze biçimde artan bellek RSS'i bir bellek sızıntısıdır. Bu örüntü bir OOM çökmesine yol açmadan önce alarm verin.

Mevsimsel anomali tespiti: Beklenen trafik örüntüleri günün saatine ve haftanın gününe göre değişir. Salı günü saat 14:00'te trafiğin %30 düşmesi, kullanıcılarınız öğle arasındaysa normaldir — değillerse alarm vericidir. Mevsimselliği hesaba katan anomali tespiti, yanlış pozitifleri çarpıcı biçimde azaltır.

Araçlar: Kendi Sunucunda mı, Yönetilen Servis mi?

Kendi sunucunuzda barındırılan yığın: Prometheus (metrik toplama), Grafana (panolar), Loki (log toplama), Tempo (izler), Alertmanager (yönlendirme). Tam kontrol, kullanıcı ya da metrik başına maliyet yok, kendi altyapınızda çalışır. Operasyonel yük gerçektir — izleme sisteminin de izlenmesi gerekir.

Yönetilen servisler: Datadog, New Relic, Grafana Cloud. Daha düşük operasyonel yük, ilk panoya daha hızlı ulaşma. Maliyet veri hacmi ve kullanıcı sayısıyla ölçeklenir — ölçek büyüdükçe ciddi bir kaleme dönüşebilir.

Hibrit: Altyapı metrikleri için (öngörülebilir, yüksek hacimli, maliyete duyarlı) Prometheus + Grafana'yı kendiniz barındırın; dağıtık izleme için (daha düşük hacim, akıllı arayüzden yüksek değer) yönetilen bir servis kullanın.

Ayrılmış bir platform mühendisliği kapasitesi olmayan ekipler için, yönetilen bir servisle başlayıp operasyonel olgunluk arttıkça kendi barındırdıkları yapıya geçmek pragmatik bir yoldur.

Sonuç

Gözlemlenebilirlik bir özellik değildir — diğer her özelliği geliştirmeyi ve yayına almayı daha güvenli kılan temeldir. Olaylardan saatler yerine dakikalar içinde toparlanan ekipler, daha az hatası olan ekipler değildir; sistemlerini görebilen, neyin değiştiğini anlayabilen ve güvenle harekete geçebilen ekiplerdir.

Gereken yatırım gerçektir: ölçümleme zaman alır, alarm ince ayarı süregiden bir disiplindir ve runbook'ların yazılması ve güncel tutulması gerekir. Getirisi de bir o kadar gerçektir: daha düşük MTTR, yayına almada daha yüksek güven ve sisteme bir şey gerçekten ilgi gerektirdiğinde bunu kendilerine söyleyeceği konusunda güvendikleri için geceyi deliksiz uyuyabilen nöbetçi mühendisler.

• İzleme
• Gözlemlenebilirlik
• DevOps
• Alarm