Eğer API izleme sisteminiz bir veri merkezindeki bir sunucuda çalışıyorsa, sadece bir kısmını görebilirsiniz. Brezilya'dan bir kullanıcı 500 hatası alırken, Moskova'daki gösterge paneliniz "her şey çalışıyor" yeşil durumu gösterebilir. Gerçek bir dış IP üzerinden başka bir ülkeden istek yapmadan ölçülemeyen 5 erişilebilirlik metriğini inceleyeceğiz ve bunu karmaşık bir altyapı olmadan nasıl yapabileceğinizi göstereceğiz.
Neden yerel izleme yanıltıcıdır
Çoğu ekip, API izlemeyi UptimeRobot, Pingdom veya her dakikada bir uç noktaya bağlanan kendi cron script'i aracılığıyla ayarlamaktadır. Sorun şu ki, bu istekler neredeyse her zaman bir veya iki bölgeden gelmektedir — genellikle ABD veya Avrupa'dan, izleme hizmetlerinin sunucularının bulunduğu yerler. Eğer hedef kitleniz Hindistan, Brezilya veya Güneydoğu Asya'daysa, yerel sağlayıcılar trafiği kesebilir, CDN düğümü aşırı yüklenebilir ve DNS eski bir IP'ye çözülüyor olabilir.
Bir diğer yaygın senaryo — CDN veya WAF (Cloudflare, Akamai) düzeyinde coğrafi engelleme. Bazı güvenlik kuralları belirli ülkelerden gelen IP aralıklarını engelleyebilir ve API'niz fiziksel olarak bazı kullanıcılar için erişilemez hale gelebilir, oysa ofis IP'nizden her şey mükemmel çalışmaktadır. Bu tür sorunlar, yalnızca tek bir noktadan test yaparak teşhis edilemez.
Üçüncü senaryo — Anycast veya bölgesel CDN kenarları aracılığıyla yük dengelemesi. Almanya'dan gelen bir istek bir düğüme ulaşırken, Singapur'dan gelen başka bir istek tamamen farklı bir düğüme ulaşabilir, farklı bir önbellek sürümü veya yapılandırması ile. Bölgeler arasındaki API davranışındaki fark, bir teori değil, kullanıcıları dünya genelinde dağıtılmış olan ekiplerin düzenli olarak karşılaştığı bir durumdur.
Sadece dış IP üzerinden görülebilen 5 erişilebilirlik metriği
Aşağıda, yalnızca hedef ülkede fiziksel olarak bulunan veya en azından ağından yönlendirilen bir IP adresinden istek yapıldığında gerçek erişilebilirlik resmini gösteren beş metrik bulunmaktadır.
1. Yanıt Süresi (Gecikme / RTT)
Round-Trip Time — isteğin gönderilmesinden ilk yanıt paketinin alınmasına kadar geçen süre. Avrupa'daki bir sunucudan API'nize olan gecikme 20 ms olabilirken, Güneydoğu Asya'dan bir kullanıcı coğrafi mesafe ve ara düğüm sayısı (hops) nedeniyle 400-600 ms beklemek zorunda kalabilir. Farklı bölgelerden gecikmeyi ölçmezseniz, hizmetin belirli bir kitle için neredeyse kullanılamaz hale geldiği anı kolayca kaçırabilirsiniz — bu, gerçek zamanlı işlemlerle bağlantılı API'ler için özellikle kritiktir: reklamda teklif verme, sohbetler, fintech işlemleri.
2. TTFB (İlk Bayta Giden Süre)
TTFB, sunucunun yanıtı göndermeye başlamadan önce isteği işlemek için geçen süreyi gösterir. Bu metrik yalnızca ağdan değil, aynı zamanda belirli bir bölgeyi hizmet veren CDN veya yük dengeleyici düğümünden de etkilenir. Sıklıkla, bir ülkedeki kenar sunucu yanıtı 50 ms içinde önbelleğe alırken, başka bir ülkede istek her seferinde orijinal sunucuya ulaşır ve yeniden işlenir, bu da 800 ms veya daha fazla zaman alır. Bölgeler arasındaki TTFB farkı, CDN yapılandırmasında veya kenar düğümlerinin yetersiz kapsama alanında sorunların kesin bir işareti olabilir.
3. DNS Çözümleme Süresi
DNS çözümleme, tamamen kullanıcının yerel çözümleyicisinden bağımsız olan gecikme ve hata kaynaklarından biridir. Eğer GeoDNS (istek bölgesine bağlı olarak farklı A kayıtları) ayarladıysanız, bir yapılandırma hatası, bir ülkeden gelen kullanıcıların başka bir kıttaki veri merkezine çözülmesine neden olabilir — bu da büyük bir gecikmeye yol açar. Bu sorun, hedef ülkenin gerçek IP'sinden DNS çözümleme isteği yapıldığında görülebilir; yerel test her zaman kendi coğrafi konumunuza göre "doğru" bir şekilde çözülür.
4. Bölgeler Arası Başarılı İstek Yüzdesi (Uptime)
İzleme gösterge panelinde %99.9 uptime, tek bir noktadan gelen isteklerle %99.9 garanti etmez. Yerel sağlayıcılar, özellikle sizin barındırma sağlayıcınıza kadar olan peering ile ilgili sorunlar yaşayabilir, bu da X ülkesinden gelen bazı isteklerin zaman aşımına uğramasına neden olurken, geri kalan dünya bu sorunu hiç fark etmeyebilir. Gerçek uptime'ı görmek için, her bölge için başarılı ve başarısız istekleri ayrı ayrı saymak gerekir, topluca değil.
5. İçerik ve Durum Kodlarındaki Farklılıklar (coğrafi engelleme ve kişiselleştirme)
Beşinci metrik hızla ilgili değil, yanıtın kendisiyle ilgilidir. API, WAF kuralları nedeniyle belirli ülkeler için 403 Yasaklı yanıtı verebilir, lisans kısıtlamaları nedeniyle kısıtlı bir veri kümesi döndürebilir veya coğrafi olarak bağlı A/B testleri nedeniyle farklı bir içerik versiyonu gösterebilir. API'yi yalnızca kendi IP'nizden test ederseniz, bu tür farklılıklar tamamen gözden kaçacaktır — ve bunlar genellikle belirli bölgelerden gelen kullanıcıların şikayetlerinin nedenidir.
Önemli Olan
Beş metrik de, hedef ülkenin ağı üzerinden gerçekten yönlendirilen bir IP'den istek yapılmasını gerektirir. Tek bir sunucuya sahip bir VPN veya aynı bölgede bir bulut sunucusu, yaklaşık bir resim verebilir, ancak hizmetin son kullanıcı tarafından nasıl görüldüğünü göstermez.
Farklı Ülkelerden İzlemeyi Nasıl Ayarlarsınız
Ayarlama mantığı basittir: aynı HTTP isteğini API'nize birkaç noktadan aynı anda gönderirsiniz, tüm beş metriği kaydedersiniz ve sonuçları karşılaştırırsınız. Adım adım şöyle görünür:
- Öncelikli ülkelerin bir listesini oluşturun — genellikle bu, trafik veya gelir açısından en yüksek 5 ülkedir.
- Her ülke için o ülkenin gerçek IP'sine sahip bir çıkış noktası hazırlayın (proxy sunucusu veya fiziksel sunucu).
- Her noktadan belirli bir aralıkla (örneğin, 5 dakikada bir) aynı isteği gönderen bir script veya hizmet ayarlayın.
- Tüm 5 metriği her ülke için ayrı ayrı bir veritabanına veya metrik sistemine (Grafana, Prometheus, ClickHouse) kaydedin.
- Metrelerin temel seviyeden sapması durumunda uyarılar ayarlayın — örneğin, belirli bir ülkeden gelen gecikme bir saat içinde 3 katına çıkarsa.
Anahtar nokta — özellikle 2. madde. İhtiyaç duyulan ülkeye gerçek bir çıkış olmadan, diğer tüm adımlar anlamsızdır, çünkü metrikler kullanıcının gördüğünü değil, izleme sunucunuzun gördüğünü ölçer.
İzleme için Hangi Proxy Türünü Seçmelisiniz
Coğrafi olarak dağıtılmış bir izleme sistemi kurmak için en sık proxy sunucuları kullanılır — bu, her gerekli ülkede fiziksel sunucular veya VPS kiralamaktan daha ucuz ve hızlıdır. Proxy türünün seçimi, neyi ölçmek istediğinize bağlıdır.
| Proxy Türü | Ne Zaman Kullanılmalı | Özellikler |
|---|---|---|
| Veri Merkezi Proxy'leri | Gerçek kullanıcı simülasyonu gerekmiyorsa temel erişilebilirlik ve gecikme kontrolü | Yüksek hız, düşük fiyat, ancak IP kolayca veri merkezi olarak tanımlanabilir — sağlayıcılara göre coğrafi engelleme testi için uygun değildir |
| İkametgah Proxy'leri | Gerçek bir kullanıcının ev sağlayıcısından ne gördüğünü kontrol etmek için | IP, belirli bir ülkedeki gerçek sağlayıcılara aittir, yönlendirmeyi ve WAF kurallarını daha doğru yansıtır |
| Mobil Proxy'ler | Mobil uygulamalar ve mobil trafik için API erişilebilirliğini test etmek | Mobil operatörlerin ağlarından IP'ler, mobil trafiğe özgü gecikmeleri ve engellemeleri gösterir |
Eğer API'niz esasen masaüstü ve sunuculardan gelen web trafiğini hizmet veriyorsa, temel izleme için veri merkezi proxy'leri yeterlidir — bunlar kararlı hız ve öngörülebilir gecikme sağlar. Ancak gerçek kullanıcının karşılaştığı durumu kontrol etmek gerekiyorsa — sağlayıcının ASN'ine göre ayarlanmış coğrafi engelleme kurallarını da dahil etmek için — ikametgah proxy'lerini kullanmak mantıklıdır, çünkü bunlar aynı ülkenin sıradan internet sağlayıcıları aracılığıyla yönlendirilir. Mobil uygulamalar ve API'ye istek yapan SDK'lar için, mobil proxy'ler aracılığıyla kontrol eklemek mantıklıdır, çünkü mobil operatörler genellikle NAT ve kendi yönlendirme kurallarını kullanır, bu da ev internetinden farklıdır.
Metriği Toplamak için Python'da Hazır Bir Script
Aşağıda, belirli bir ülkedeki proxy üzerinden istek gönderen ve beş metriğin dördünü toplayan basitleştirilmiş bir script örneği bulunmaktadır (içerik farklılıklarını ayrı olarak karşılaştırmak gerekir). Script, requests kütüphanesini ve DNS çözümleme süresini ölçmek için socket modülünü kullanır.
import time
import socket
import requests
def measure_api(url, proxy, country_label):
hostname = url.split("//")[1].split("/")[0]
# 1. DNS çözümleme süresi
dns_start = time.time()
try:
socket.gethostbyname(hostname)
except socket.gaierror:
pass
dns_time = time.time() - dns_start
proxies = {
"http": proxy,
"https": proxy,
}
try:
start = time.time()
response = requests.get(
url,
proxies=proxies,
timeout=10,
stream=True
)
ttfb = time.time() - start # yaklaşık TTFB
full_load_time = time.time() - start
status_code = response.status_code
success = status_code == 200
result = {
"country": country_label,
"dns_time_ms": round(dns_time * 1000, 2),
"ttfb_ms": round(ttfb * 1000, 2),
"total_time_ms": round(full_load_time * 1000, 2),
"status_code": status_code,
"success": success,
}
except requests.exceptions.RequestException as e:
result = {
"country": country_label,
"dns_time_ms": round(dns_time * 1000, 2),
"ttfb_ms": None,
"total_time_ms": None,
"status_code": None,
"success": False,
"error": str(e),
}
return result
# Farklı ülkelerden proxy ile kullanım örneği
endpoints = [
{"label": "Almanya", "proxy": "http://user:[email protected]:port"},
{"label": "Brezilya", "proxy": "http://user:[email protected]:port"},
{"label": "Singapur", "proxy": "http://user:[email protected]:port"},
]
API_URL = "https://api.yourservice.com/health"
for ep in endpoints:
data = measure_api(API_URL, ep["proxy"], ep["label"])
print(data)
Böyle bir script'in üretim versiyonuna, sonuçların bir veritabanına (örneğin, ClickHouse veya InfluxDB) kaydedilmesi, Grafana ile görselleştirme ve eşik değerlerin aşılması durumunda Telegram botu veya Slack webhook'u aracılığıyla uyarılar eklemek mantıklıdır. Script'i her ülke için 5-15 dakikalık aralıklarla cron veya görev zamanlayıcı üzerinden çalıştırmak en iyisidir.
Hızlı bir kontrol için kod yazmadan, benzer bir isteği cURL ile zaman ölçümü yaparak gerçekleştirebilirsiniz:
curl -x http://user:[email protected]:port \
-o /dev/null -s -w "DNS: %{time_namelookup}s | TTFB: %{time_starttransfer}s | Toplam: %{time_total}s | HTTP: %{http_code}\n" \
https://api.yourservice.com/healthSonuçları Nasıl Yorumlarsınız
Tüm ülkelerden verileri topladıktan sonra en az bir hafta boyunca her bölge için bir temel seviye (baseline) oluşur. Daha sonra, mutlak sayılara değil, bu temel seviyeden sapmalara bakmak gerekir. Eğer Brezilya'dan gelen gecikme sürekli olarak 350 ms seviyesinde kalıyorsa — bu coğrafya için normaldir ve değer aniden 1500 ms'ye yükseldiğinde alarm verilmelidir. Uptime ile de benzer bir durum söz konusudur: karmaşık bir bölge için %99.5 uptime, istikrarsız internet için kabul edilebilir bir norm olabilirken, %95'e düşmesi sağlayıcı veya CDN tarafında bir sorun olduğunu gösterir.
403 ve 451 durum kodlarına özel dikkat gösterilmelidir — bunlar neredeyse her zaman WAF veya CDN tarafından coğrafi engelleme olduğunu gösterir, API'nin kendisiyle ilgili bir sorun değil. Bu tür kodlar yalnızca belirli bir ülkeden ve belirli bir proxy türü (örneğin, veri merkezi) kullanıldığında ortaya çıkıyorsa, bu, engellemenin "IP veri merkezi gibi görünüyor" kriterine göre ayarlandığını ve gerçek coğrafi konumdan bağımsız olduğunu gösterebilir — bu durumda ikametgah proxy'leri ile yapılan test daha doğru bir resim verecektir.
Hazır Hizmetler vs. Kendi Çözümünüz
Kendi script'inizi desteklemek istemiyorsanız, piyasada farklı ülkelerdeki varlık noktaları ile sentetik izleme hizmetleri bulunmaktadır: Pingdom, Uptrends, Site24x7, Checkly. Bu hizmetler, altyapıyı ayarlama gerekliliğinden kurtarır, ancak genellikle sabit bir lokasyon seti ile sınırlıdır ve belirli bir test için IP türünün (ikametgah, mobil, veri merkezi) seçimi konusunda esneklik sağlamaz.
Proxy tabanlı kendi çözümünüz daha fazla kontrol sağlar: işiniz için önemli olan ülkeleri test edebilir, belirli sorunları teşhis etmek için IP türleri arasında geçiş yapabilir (örneğin, ASN'ye göre coğrafi engelleme) ve metrikleri doğrudan izleme sisteminize entegre edebilirsiniz. Her iki yaklaşımın kombinasyonu — makul bir denge sağlar: temel SLA izleme için hazır hizmetler, belirli bölgelerdeki sorunları teşhis etmek için proxy ile kendi script'iniz.
Sonuç
Tek bir noktadan yerel izleme, API'nin erişilebilirliği hakkında yalnızca bir kısmını gösterir. Gerçek resmi görmek için, gecikmeyi, TTFB'yi, DNS çözümleme süresini, uptime'ı ve içerik farklılıklarını her ülke için ayrı ayrı ölçmek gerekir — ve bunu, hedef bölgenin ağı üzerinden gerçekten yönlendirilen bir IP ile yapmak gerekir. Bunu yapmadan, hizmetten yararlanan bazı kullanıcıların karşılaştığı bir sorunu kolayca gözden kaçırabilirsiniz, oysa gösterge paneli "her şey yeşil" gösteriyor.
Böyle bir izleme sistemi kurmak için, ikametgah proxy'leri en iyi seçenektir, eğer gerçek bir kullanıcının belirli bir ülkedeki ev interneti ile gördüğünü görmek önemliyse. Daha ucuz ve hızlı bir temel erişilebilirlik kontrolü için veri merkezi proxy'leri yeterlidir, mobil kullanıcıların sorunlarını teşhis etmek için ise mobil proxy'ler ile kontrol eklemek mantıklıdır. Bu tür bir kombinasyon, API'nizin dünyanın herhangi bir yerinden nasıl göründüğünün tam resmini verir, yalnızca dağıtıldığı sunucudan değil.