Synthetic Monitoring ve Real User Monitoring (RUM): Uygulama Performansını Gerçekte Nasıl Ölçmeliyiz?
Synthetic Monitoring ve RUM ile web uygulamalarında performans ve gerçek kullanıcı deneyiminin izlenmesi.
Bir web uygulamasını izlerken ilk baktığımız değerler genellikle bellidir. Sunucu çalışıyor mu, HTTP isteğine cevap geliyor mu, CPU ve bellek tarafında olağan dışı bir durum var mı?
Bu kontroller altyapının sağlık durumunu anlamak için gerekli. Fakat kullanıcı deneyimini ölçmek istediğimizde tablo biraz değişiyor.
Bir web sitesi HTTP 200 cevabı verebilir. Sunucunun kaynak kullanımı normal olabilir ve veritabanı bağlantılarında herhangi bir hata görünmeyebilir. Buna rağmen kullanıcı giriş ekranında uzun süre bekliyor, ödeme işlemini tamamlayamıyor veya sayfanın kullanılabilir hale gelmesi için birkaç saniye daha beklemek zorunda kalıyor olabilir.
Monitoring tarafında burada başka bir soruya ihtiyaç duyuyoruz:
Kullanıcı, sunduğumuz servisi gerçekten beklediğimiz şekilde kullanabiliyor mu?
Synthetic Monitoring ve Real User Monitoring, kısaca RUM, bu soruya iki farklı noktadan cevap vermeye çalışıyor.
Synthetic Monitoring Nedir?
Synthetic Monitoring, önceden oluşturulmuş bir test senaryosunun belirli aralıklarla otomatik olarak çalıştırılmasıdır.
En basit haliyle bir web adresine HTTP isteği gönderip durum kodunu ve yanıt süresini kontrol edebiliriz. Biraz daha ileri gittiğimizde DNS çözümleme, TLS bağlantısı, API çağrıları ve tarayıcı üzerinden gerçekleştirilen kullanıcı işlemleri de aynı senaryoya dahil edilebilir.
Örneğin bir e-ticaret uygulamasını ele alalım.
Basit bir HTTP kontrolü ana sayfanın cevap verdiğini gösterebilir. Browser tabanlı bir synthetic test ise şu işlemleri gerçekleştirebilir:
- Ana sayfayı açar.
- Kullanıcı giriş ekranına gider.
- Test hesabıyla oturum açar.
- Ürün sayfasını görüntüler.
- Ürünü sepete ekler.
- Sepetin doğru şekilde açıldığını kontrol eder.
Burada artık tek bir URL’nin erişilebilirliğini değil, kullanıcının gerçekleştirdiği gerçek bir işlemi izliyoruz.
Grafana k6 browser check dokümantasyonundaki örnekler de bu çalışma yöntemini gösteriyor. Headless Chrome üzerinden çalışan testler sayfa açma, butona tıklama, form doldurma ve belirli bir elementin ekrana geldiğini doğrulama gibi işlemleri gerçekleştirebiliyor.
Synthetic Monitoring’in avantajlarından biri test koşullarını büyük ölçüde kontrol altında tutabilmemizdir.
Aynı lokasyondan, aynı senaryo ile ve aynı aralıklarla yapılan ölçümler zaman içerisinde karşılaştırılabilir. Örneğin yeni bir deployment sonrasında login işlemi 1,5 saniyeden 4 saniyeye çıktıysa bunu kullanıcı şikâyeti gelmeden fark etmek mümkün olabilir.
Gerçek kullanıcı trafiğinin bulunmadığı sistemlerde de synthetic testler çalışmaya devam eder. Gece saatlerinde kullanıcı olmayan bir kurumsal uygulama veya henüz canlıya alınmamış yeni bir servis bu şekilde düzenli olarak kontrol edilebilir.
Real User Monitoring Ne Gösterir?
Real User Monitoring farklı bir veri kaynağı kullanır.
Burada oluşturulmuş bir test kullanıcısını değil, uygulamayı gerçekten kullanan kişilerin tarayıcılarında oluşan performans verilerini ölçeriz.
Bu ayrım pratikte oldukça önemlidir.
Synthetic test yaptığımız sistem güçlü bir işlemciye, hızlı bir internet bağlantısına ve güncel bir tarayıcıya sahip olabilir. Gerçek kullanıcı ortamında ise şartlar sürekli değişir.
Bir kullanıcı eski bir mobil cihaz kullanabilir. Başka bir kullanıcı kurumsal proxy üzerinden çıkış yapabilir. Bir başkası mobil bağlantıyla sisteme ulaşırken farklı bir kullanıcı uygulamaya başka bir ülkeden erişebilir.
RUM bu farklılıkların kullanıcı deneyimine nasıl yansıdığını görmemizi sağlar.
MDN, iki yöntemi karşılaştırırken synthetic monitoring’i kontrollü ve mümkün olduğunca tutarlı bir test ortamı olarak tanımlıyor. RUM tarafında ise gerçek kullanıcıların oluşturduğu saha verisi bulunuyor.
Bu nedenle iki tarafta gördüğümüz rakamların birebir aynı olması beklenmemeli.
Synthetic test sonucunda:
Sayfa 1,5 saniyede açılıyor.
görebiliriz.
RUM tarafında ise:
Kullanıcıların yüzde 20’sinde yükleme süresi 4 saniyenin üzerine çıkıyor.
sonucuyla karşılaşabiliriz.
İkinci veri bizi daha farklı sorulara yönlendirir.
Sorun belirli cihazlarda mı oluşuyor?
Belirli bir tarayıcı sürümü mü etkileniyor?
Belirli bir coğrafi bölgede gecikme mi yaşanıyor?
Mobil bağlantı kullananlarda sonuçlar farklı mı?
Yeni frontend sürümü belirli cihazlarda performans problemi mi oluşturdu?
RUM’un asıl değeri ortalama bir kullanıcı oluşturmaya çalışmak yerine gerçek kullanıcı dağılımını görebilmemizdir.
Tarayıcı Aslında Oldukça Fazla Telemetry Üretiyor
Modern tarayıcılar web performansını değerlendirebilmek için düşündüğümüzden daha fazla veri üretiyor.
W3C Navigation Timing Level 2 spesifikasyonu, web uygulamalarının bir dokümanın navigation sürecindeki zamanlama bilgilerine erişmesini sağlayan PerformanceNavigationTiming arayüzünü tanımlıyor.
Bu bilgiler sayesinde sayfanın açılması sırasında geçen sürenin hangi bölümünün DNS çözümlemeye, bağlantı kurulmasına, request ve response işlemlerine veya DOM tarafına ait olduğu incelenebilir.
Bir kullanıcının söylediği “site yavaş” ifadesini operasyon tarafında anlamlandırabilmek için bu ayrım önemlidir.
Çünkü toplam 5 saniyelik yükleme süresinin tamamı uygulama sunucusundan kaynaklanmak zorunda değildir.
Web performansı tarafında sık kullanılan başka bir veri grubu da Core Web Vitals metrikleridir.
Güncel Core Web Vitals setinde üç temel metrik bulunuyor:
Largest Contentful Paint (LCP) sayfanın ana içeriğinin kullanıcı tarafından ne kadar hızlı görülebildiğine odaklanır.
Interaction to Next Paint (INP) kullanıcının gerçekleştirdiği etkileşimlere sayfanın ne kadar hızlı cevap verdiğini ölçer.
Cumulative Layout Shift (CLS) ise sayfadaki beklenmeyen görsel kaymaları değerlendirir.
Google’ın mevcut eşiklerinde iyi kullanıcı deneyimi için LCP’nin 2,5 saniye veya altında, INP’nin 200 milisaniye veya altında, CLS değerinin ise 0,1 veya altında olması öneriliyor.
Burada özellikle ortalama değere takılmamak gerekir. Core Web Vitals değerlendirmesinde 75. yüzdelik dilimin kullanılmasının sebeplerinden biri de budur.
Ortalama LCP değeri 1,8 saniye olan bir uygulamada kullanıcıların belirli bir bölümü 5 veya 6 saniyelik sürelerle karşılaşıyor olabilir. Tek başına ortalama değer bu kullanıcı grubunu görünmez hale getirebilir.
HTTP 200 Neden Yeterli Değil?
Monitoring sistemlerinde sık karşılaşılan durumlardan biri, servis kontrolleri başarılı görünmesine rağmen kullanıcı şikâyetlerinin devam etmesidir.
Bunun temel sebebi bir HTTP kontrolünün gördüğü dünya ile kullanıcının tarayıcısında gerçekleşen işlemlerin aynı olmamasıdır.
Bir web sayfası açılırken kabaca şu aşamalardan geçilebilir:
DNS çözümleme → TCP bağlantısı → TLS → HTTP isteği → sunucu cevabı → HTML → CSS ve JavaScript → API çağrıları → render → kullanıcı etkileşimi
Ana URL’nin HTTP 200 cevabı vermesi zincirin tamamının sağlıklı olduğunu göstermez.
Örneğin backend üzerindeki ana web servisi çalışıyor olabilir fakat authentication API cevap vermiyor olabilir.
JavaScript dosyalarından biri üçüncü taraf CDN üzerinden çok geç geliyor olabilir.
Sayfa açılıyor fakat kullanıcının tıkladığı buton frontend tarafındaki bir hata nedeniyle çalışmıyor olabilir.
Login sayfası yükleniyor fakat kimlik doğrulama işlemi 15 saniye sürebilir.
Bunların tamamında basit HTTP kontrolü yeşil görünmeye devam edebilir.
Bu yüzden availability ile kullanıcı deneyimini birbirinden ayırmak gerekir.
Synthetic Monitoring ve RUM Birbirinin Alternatifi Değil
İki yöntem zaman zaman birbirinin alternatifi gibi değerlendiriliyor. Uygulamada ise farklı sorulara cevap verdikleri için birlikte kullanıldıklarında daha fazla değer sağlıyorlar.
| Konu | Synthetic Monitoring | Real User Monitoring |
|---|---|---|
| Veri kaynağı | Otomatik test senaryosu | Gerçek kullanıcı |
| Kullanıcı trafiği gerekir mi? | Hayır | Evet |
| Koşullar | Kontrollü | Değişken |
| Tekrarlanabilirlik | Yüksek | Kullanıcı davranışına bağlı |
| Kesintiyi önceden görme | Güçlü | Kullanıcı oluşmadan veri yok |
| Cihaz ve tarayıcı çeşitliliği | Sınırlı | Gerçek ortamı yansıtır |
| Bölgesel performans | Seçilen probe’larla ölçülür | Gerçek kullanıcı dağılımından gelir |
| Regresyon takibi | Çok uygun | Destekleyici |
| Gerçek kullanıcı deneyimi | Simüle edilir | Doğrudan ölçülür |
Örneğin synthetic login testi her beş dakikada bir başarılı sonuç verebilir.
Aynı zaman dilimindeki RUM verisi belirli Android cihazlarda login süresinin iki katına çıktığını gösterebilir.
Tersi de mümkündür.
Gece saatlerinde gerçek kullanıcı trafiği yoksa RUM tarafında değerlendirecek veri bulunmayabilir. Synthetic Monitoring ise belirlenen senaryoları çalıştırmaya devam eder.
Bu yüzden doğru soru “Synthetic mi, RUM mu?” değildir.
Asıl soru, yaşadığımız problemi anlayabilmek için hangi veriye ihtiyacımız olduğudur.
Monitoring Verisini Altyapıyla Birlikte Okumak
Kullanıcı tarafındaki performans problemini tespit etmek tek başına yeterli değildir. Bundan sonraki adım problemin nerede başladığını bulmaktır.
Örneğin RUM tarafında saat 14.20’den sonra login sürelerinin yükseldiğini gördüğümüzü düşünelim.
Aynı zaman aralığında şu verilere bakabilmeliyiz:
CPU veya bellek kullanımında değişiklik olmuş mu?
Veritabanı sorgu süreleri yükselmiş mi?
API response time değişmiş mi?
Network latency veya packet loss artmış mı?
Uygulama loglarında yeni bir hata oluşmuş mu?
O saatte yeni bir deployment yapılmış mı?
Bir üçüncü taraf servisin yanıt süreleri yükselmiş mi?
Bu verilerin ortak zaman çizgisinde görülebilmesi kök neden analizini ciddi biçimde kolaylaştırır.
Monitoring ve observability arasındaki ayrımın operasyon tarafındaki karşılıklarından biri de burada görülüyor.
Çok sayıda veri toplamak tek başına yeterli değil. Sorun meydana geldiğinde farklı sinyaller arasındaki ilişkiyi kurabilmek gerekiyor.
Alarm Tasarımı Nasıl Olmalı?
Kullanıcı deneyimi izlenmeye başlandığında alarm tasarımının da buna göre genişletilmesi gerekir.
“HTTP servisi cevap vermiyor” hâlâ önemli bir alarmdır. Fakat sistem cevap verdiği halde kritik bir kullanıcı işlemi normalden üç kat uzun sürüyorsa bunu da bilmek isteriz.
Login işlemi için örnek olarak üç farklı durum düşünebiliriz.
İlk durumda işlem tamamen başarısız olur.
İkinci durumda işlem başarılıdır fakat kabul edilen performans sınırının üzerinde tamamlanır.
Üçüncü durumda synthetic test başarılı ve hızlıdır fakat RUM verisinde gerçek kullanıcıların belirli bir kısmında ciddi performans kaybı görülür.
Bu üç durumun araştırma yöntemi aynı değildir.
İlkinde servis kesintisi veya uygulama hatası araştırılabilir.
İkincisinde backend, database veya üçüncü taraf servislerin latency değerlerine bakılabilir.
Üçüncüsünde cihaz, tarayıcı, frontend kodu, CDN veya bölgesel bağlantı koşulları araştırılabilir.
Tek bir UP/DOWN kontrolü bu ayrımı sağlayamaz.
Nereden Başlanmalı?
Her sayfa için browser senaryosu oluşturmak veya bütün kullanıcı hareketlerini RUM tarafında ayrı ayrı izlemek iyi bir başlangıç olmayabilir.
Öncelikle uygulamanın kritik kullanıcı yolculuklarını belirlemek daha doğru olur.
Bir e-ticaret sistemi için:
Login
Ürün arama
Sepete ekleme
Ödeme
kritik işlemler olabilir.
Bir kurumsal ERP uygulamasında:
Login
Rapor görüntüleme
Kayıt oluşturma
Kayıt güncelleme
daha değerli olabilir.
Synthetic kontroller bu akışların gerçekten çalışıp çalışmadığını düzenli olarak test eder.
RUM ise gerçek kullanıcıların bu işlemler sırasında yaşadığı performansı görünür hale getirir.
Sonrasında aynı zaman aralığındaki altyapı metrikleri, loglar, network verileri ve uygulama telemetry’si devreye girer.
Bu yapı kurulduğunda monitoring sistemi bize yalnızca bir servisin ayakta olup olmadığını söylemez. Kullanıcı tarafındaki bir problemin hangi noktada başlamış olabileceğini anlamamız için de veri sağlar.
NOC ve Uygulama Ekipleri İçin Ortak Bir Görünürlük Alanı
Synthetic Monitoring ve RUM çoğunlukla web performansı veya uygulama ekiplerinin konusu olarak görülüyor. Operasyon tarafındaki karşılığı ise daha geniş.
NOC ekibi ağ ve altyapıyı izlerken uygulama ekibi API ve frontend performansını takip ediyor olabilir. Kullanıcı açısından bu katmanların ayrı bir anlamı yoktur. Kullanıcının baktığı şey işlemin tamamlanıp tamamlanmadığıdır.
Bu nedenle kullanıcı deneyimi metrikleri farklı ekiplerin konuşabileceği ortak bir referans noktası oluşturabilir.
RUM tarafında görülen performans kaybını aynı zaman aralığındaki network latency, application trace, sistem metriği ve loglarla eşleştirebiliyorsak sorun çözme süresi de kısalır.
Burada hedef daha fazla dashboard oluşturmak değil.
Hedef, kullanıcı şikâyeti geldiğinde “Bizde her şey yeşil görünüyor” demek yerine problemin hangi katmanda başladığını gösterebilecek veriye sahip olmaktır.
Sonuç
Bir web servisinin çalışıyor olması ile kullanıcı açısından iyi çalışıyor olması aynı şey değildir.
Klasik infrastructure monitoring bize sunucuların, ağ cihazlarının ve servislerin sağlık durumunu göstermek için güçlü bir temel sağlar. Fakat web uygulamalarında kullanıcı deneyimini anlamak için bu görünürlüğü tarayıcı ve kullanıcı tarafına kadar genişletmek gerekiyor.
Synthetic Monitoring, kritik işlemleri kontrollü biçimde ve sürekli olarak test eder.
RUM ise gerçek kullanıcıların farklı cihaz, tarayıcı, ağ ve coğrafi koşullarda yaşadığı deneyimi gösterir.
Bu iki veri grubu altyapı metrikleri, loglar ve uygulama telemetry’si ile birlikte değerlendirildiğinde daha anlamlı bir monitoring modeli ortaya çıkar.
O noktada artık sadece “Sistem çalışıyor mu?” sorusuna cevap vermeyiz.
Kullanıcı tarafında bir problem var mı ve varsa nerede başlıyor?
Operasyon tarafında ihtiyaç duyduğumuz cevap çoğu zaman tam olarak budur.
Eline sağlık.