Sentetik İzleme (Synthetic Monitoring) Nedir?
Kısa tanım
Sentetik izleme (synthetic monitoring), bir web sitesini ya da API'yi gerçek kullanıcıları beklemeden, önceden yazılmış senaryolarla belirli aralıklarla ve belirli konumlardan otomatik olarak test etme yöntemidir. En basit biçimi sitenin ayakta olup olmadığını kontrol eden uptime izlemedir; gelişmiş biçimleri giriş, sepet veya ödeme gibi çok adımlı akışları gerçek bir tarayıcıda çalıştırır ve performans ölçer.
Diğer adları: Synthetic Monitoring, uptime izleme, uptime monitoring, çalışma süresi izleme, aktif izleme, işlem izleme
Kullanıcı yokken de ölçmek
Gerçek kullanıcı verisi ancak biri siteyi ziyaret ettiğinde oluşur. Gece üçte ödeme sayfası çöktüyse, sabah ilk müşteri şikâyet edene kadar kimse fark etmeyebilir. Sentetik izleme bu boşluğu doldurur: dünyanın farklı noktalarındaki robotlar, sizin tanımladığınız senaryoları dakikada bir ya da beş dakikada bir çalıştırır ve sonuç beklenenden saparsa alarm üretir.
Yaygın olarak dört tür kontrol kullanılır:
- Uptime kontrolü: Bir URL'ye istek atılır, durum kodu ve yanıt süresi kontrol edilir.
- API kontrolü: Bir uç noktaya belirli bir istek gönderilir, dönen JSON'un yapısı ve değerleri doğrulanır.
- İşlem (transaction) kontrolü: Gerçek bir tarayıcı birden fazla adımı sırayla uygular: giriş yapar, ürün arar, sepete ekler.
- Zamanlanmış performans testi: Lighthouse benzeri bir laboratuvar testi aynı koşullarda düzenli çalıştırılır ve eğilim izlenir.
Uptime izlemeyi doğru kurmak
“Site açılıyor mu?” sorusu basit görünür ama yanlış kurulmuş bir kontrol ya gerçek kesintiyi kaçırır ya da sürekli boş alarm üretir. İyi bir uptime kontrolü yalnızca 200 durum koduna bakmaz. Hata sayfasını 200 ile döndüren bir sistemde bu kontrol her zaman “sağlıklı” der. Bu yüzden yanıt gövdesinde beklenen bir metnin (örneğin sayfa başlığı ya da altbilgideki şirket adı) bulunduğu da doğrulanmalıdır. Kontroller birden fazla bölgeden yapılmalı ve alarm, tek bir bölgedeki ağ sorununa değil, en az iki bölgenin aynı anda başarısız olmasına bağlanmalıdır. TLS sertifikasının bitiş tarihi ve alan adının DNS çözümlemesi de aynı izleme planına dahil edilebilir.
Erişilebilirlik hedefleri yüzdeyle ifade edilir ve küçük farklar büyük sürelere karşılık gelir. 30 günlük bir ayda %99,9 erişilebilirlik yaklaşık 43 dakika, %99,99 ise yaklaşık 4 dakika kesinti payı bırakır. Planlı bakım sırasında sunucunun 503 Service Unavailable döndürmesi ve izleme aracında bakım penceresi tanımlanması, bu sürelerin anlamlı kalmasını sağlar.
Çok adımlı senaryolar
İşlem kontrolleri çoğunlukla Playwright ya da Puppeteer gibi tarayıcı otomasyon araçlarıyla yazılır. Yapı olarak uçtan uca testlere çok benzer; fark, canlı ortamda ve sürekli çalışmalarıdır:
import { test, expect } from '@playwright/test';
test('giriş ve sepet akışı', async ({ page }) => {
await page.goto('https://alanadi.com/giris');
await page.getByLabel('E-posta').fill(process.env.IZLEME_KULLANICISI);
await page.getByLabel('Parola').fill(process.env.IZLEME_PAROLASI);
await page.getByRole('button', { name: 'Giriş yap' }).click();
await page.goto('https://alanadi.com/urun/ornek-urun');
await page.getByRole('button', { name: 'Sepete ekle' }).click();
await expect(page.getByText('Sepetinizde 1 ürün var')).toBeVisible();
});Canlı ortamda çalışan senaryoların yan etkilerini düşünmek gerekir: gerçek sipariş oluşturmamalı, stokları etkilememeli ve analitik verisini kirletmemelidir. Ayrı test hesapları, ödeme adımından önce duran akışlar ve izleme trafiğinin analitikten hariç tutulması standart önlemlerdir.
RUM ile birlikte düşünmek
| Sentetik izleme | Gerçek kullanıcı izleme | |
|---|---|---|
| Trafik gerektirir mi? | Hayır | Evet |
| Gece yaşanan kesintiyi yakalar mı? | Evet, dakikalar içinde | Ancak kullanıcı gelirse |
| Ölçüm koşulları | Sabit; dönemler arası karşılaştırma kolay | Değişken; gerçek çeşitliliği yansıtır |
| Rakip siteleri ölçebilir mi? | Evet | Hayır |
| Zayıf yanı | Gerçek cihaz ve ağ çeşitliliğini temsil etmez | Sorun ancak kullanıcılar etkilendikten sonra görünür |
Sentetik testler yayın sürecine de bağlanabilir: yeni bir sürüm staging ortamında belirlenen performans bütçesini aşarsa yayına çıkmadan durdurulur.
Kurulumda dikkat edilecekler
- Konum seçimi: Ziyaretçileriniz ağırlıklı olarak Türkiye'deyse kontrolleri yalnızca ABD'den çalıştırmak gecikmeyi olduğundan yüksek gösterir.
- Önbelleğin arkasını da test edin: CDN önbelleği origin çöktüğünde bile eski sayfayı sunabilir; kritik bir kontrolün origin'e ulaşan, önbelleğe alınmayan bir uç noktayı da yoklaması gerekir.
- Sıklık ve maliyet dengesi: Tarayıcı tabanlı senaryolar basit HTTP kontrollerinden çok daha pahalıdır; kritik akışlar sık, diğerleri seyrek çalıştırılabilir.
- Alarm yönetimi: Her alarm bir kişiye ulaşmalı ve bir aksiyon gerektirmelidir. Sürekli çalan alarm kısa sürede görmezden gelinir. Sentetik kontroller, loglar ve metriklerle birlikte gözlemlenebilirlik yapısının bir parçası olarak ele alınmalıdır.