API'nizi milisaniyeler içinde yanıt verecek şekilde optimize ettiniz. Dahili ölçümleriniz mükemmel görünüyor. Ancak Mumbai'deki bir müşteri 3 saniyelik yanıt süreleri görüyor. São Paulo'daki bir geliştirici, API'nizin "kullanılamayacak kadar yavaş" olduğunu bildirdi. Sidney'deki ekibiniz entegrasyonların zaman aşımına uğradığını söylüyor.
Gecikme izleme API'si, kullanıcılarınızın gerçekte ne yaşadıklarını, gerçekte bulundukları yerden ölçer.
Her şeyi doğru yaptın. API'niz büyük bir bulut sağlayıcısında konuşlandırılmıştır. 100 ms'nin altındaki P95 gecikmelerini gösteren APM enstrümantasyonunuz var. Yük dengeleyiciniz arka uçların sağlıklı olduğunu bildiriyor. Durum sayfasında "Tüm Sistemler Çalışıyor" ifadesi görüntülenir.
Daha sonra destek bildirimlerindeki kalıpları fark etmeye başlarsınız. Belirli bölgelerdeki müşteriler yavaş API yanıtlarından şikayetçi. Entegrasyon ortakları sorun yaşayıp yaşamadığınızı soruyor. Slack topluluğunuzdaki geliştiriciler zaman aşımı hatalarından bahsediyor.
Metriklerinizi kontrol ediyorsunuz; her şey yolunda görünüyor. Müşteriden bazı testler yapmasını istersiniz; onlar da bunun yavaş olduğunu onaylarlar. İzlemeniz performansı yalnızca altyapınızın içinden ölçtüğü için onların gördüklerini görmenin hiçbir yolu yoktur.
Sorun API'niz değil. Bu, sunucularınız ve farklı bölgelerdeki kullanıcılarınız arasındaki binlerce kilometrelik ağ altyapısıdır ve sizin bunu göremezsiniz.
Gecikme izleme API'sinin hayati önem taşıdığı nokta burasıdır. Dahili metriklerinizi değiştirmek için değil, size resmin tamamını, yani dünya çapındaki gerçek ağ konumlarından uçtan uca yanıt süresini göstermek için.
Ağ gecikmesi yalnızca mesafeyle ilgili değildir. Bu, bir isteğin izlediği yolun tamamıyla ilgilidir ve bu yol, her konumdaki her kullanıcı için farklıdır.
API yanıtınızın tek bir baytı iletilmeden önce, DNS çözümlemesi gecikmeyi artırır. Jakarta'daki bir kullanıcı, yerel çözümleyicisinin yavaş olması veya DNS sağlayıcınızın en yakın herhangi noktaya yayın düğümünün uzakta olması durumunda yalnızca DNS araması için 200 ms yaşayabilir. Bu, her yeni bağlantıda ve TTL'nin sona ermesinden sonra gerçekleşir.
API etkisi: Her istemciden gelen ilk isteğe 100-500 ms eklendi. Sunucu tarafı ölçümlerinde görünmez.
BGP yönlendirmesi gecikme için optimize etmez; politika ve maliyet için optimize eder. Berlin'den ABD-Doğu sunucularınıza giden trafik Londra'dan, ardından New York'tan ve en sonunda Virginia'dan geçebilir. Daha doğrudan bir yol var ama internet bu şekilde çalışmıyor. Yönlendirme, eşleme anlaşmalarına ve ağ koşullarına göre günlük olarak değişir.
API etkisi: Optimum coğrafi yola kıyasla 50-300 ms ek gidiş-dönüş süresi.
API ağ geçidinizin veya CDN'nizin dünya çapında uç konumları vardır, ancak hepsi eşit değildir. Yoğun saatlerde bazı kenarlar aşırı yükleniyor. Bazıları daha yavaş bakıyor. Bazıları, önbelleğe alma kurallarınız API modelleriyle eşleşmiyorsa her istek için kaynağa geri döner. Farklı uçlara ulaşan kullanıcılar farklı gecikmeler yaşar.
API etkisi: Aynı uç noktaya hizmet veren uç konumlar arasında 100-1000 ms fark.
Bölgesel İSS'ler ile bulut sağlayıcıları arasındaki bağlantı büyük ölçüde farklılık gösterir. Hindistan'daki büyük bir telekomünikasyon şirketi AWS ile mükemmel bir eşlemeye sahip olabilirken, daha küçük bir İSS, trafiği birden fazla atlama noktası üzerinden yönlendirebilir. Kurumsal ağlar, mobil operatörler ve konut İSS'lerinin hepsinin altyapınıza giden farklı yolları vardır.
API etkisi: Aynı şehirdeki ancak farklı İSS'lerdeki kullanıcılar 200-500 ms'lik gecikme farklarını görebilir.
Gerçek: API'nizin sunucu tarafı işlem süresi genellikle toplam gecikmenin en küçük bileşenidir. Ağ yolu (DNS, yönlendirme, CDN kenarları, ISP eşlemesi) genellikle kod yürütme sürenizden 10-50 kat daha fazla gecikme süresi ekler. Gecikme izleme API'si yalnızca doğrudan kontrol ettiğiniz kısmı değil, bu yolun tamamını ölçer.
Çoğu API izleme kurulumu "çalıştı mı?" sorusunu yanıtlayacak şekilde tasarlanmıştır. — "Farklı bölgelerdeki kullanıcılar için ne kadar hızlı?" değil
Datadog APM, New Relic veya Elastic APM gibi Uygulama Performansı İzleme araçları, sunucularınızdaki istek işleme süresini ölçer. DNS çözümlemesi, TCP anlaşması, TLS anlaşması veya ağ geçiş süresi konusunda görünürlükleri yoktur. Kullanıcılar 2000 ms yaşarken P95'iniz 80 ms gösterebilir.
Geleneksel çalışma süresi izleme, genellikle hepsi aynı bölgede olmak üzere 1-5 konumdan kontrol edilir. İzlemeniz ABD-Doğu'dan yapılıyorsa ve yavaş kullanıcılarınız Güneydoğu Asya'daysa, sorunu asla göremezsiniz. Coğrafi kapsam genellikle sonradan akla gelen bir düşünce veya premium bir eklentidir.
İzlemeniz AWS'den AWS'ye veya GCP'den GCP'ye kontrol yapıyorsa çoğu kullanıcının geçmediği optimize edilmiş bulut omurga yollarını test ediyorsunuz demektir. Tüketici ISP'lerindeki, mobil ağlardaki ve kurumsal WAN'lardaki gerçek kullanıcılar tamamen farklı gecikme özellikleriyle karşılaşır.
Yüksek gecikme gördüğünüzde istek yaşam döngüsünün neresinde zaman harcandığını bilmeniz gerekir. DNS mi? TCP bağlantısı? TLS anlaşması mı? İlk bayt zamanı mı? İçerik aktarımı mı? Bu arıza olmadan temel nedeni teşhis edemez veya sorunu hangi ekibin düzeltmesi gerektiğini bilemezsiniz.
Sunucu işleme toplam gecikmenin %7'sini oluşturuyordu. Geri kalan %93'lük kısım ise sunucu tarafı izlemede tamamen görünmezdi.
Yavaş API'ler yalnızca kullanıcıları hayal kırıklığına uğratmaz; zamanla artan şekillerde müşterilerinize, gelirinize ve itibarınıza mal olur.
Bir geliştirici platformu veya genel API oluşturuyorsanız gecikme, benimsemeyi doğrudan etkiler. API'nizi değerlendiren geliştiriciler birkaç test isteği çalıştıracaktır. Bu istekler bulundukları yerden 2+ saniye sürerse, API'nin yanıt verdiğini hisseden bir rakibe geçecektir. Onları kaybettiğini bile bilmeyeceksin.
SLA'nız %99,9 kullanılabilirlik ve <500 ms yanıt süreleri vaat ediyor. İzleme konumunuzdan onunla buluşuyorsunuz. Ancak belirli bölgelerdeki müşteriler ihlallerle karşılaşıyor. Sonunda şikayette bulunduklarında, sorunun kapsamını veya süresini anlayacak hiçbir veriye sahip olmazsınız ve iddialarına itiraz etme veya iddialarını doğrulama olanağınız da olmaz.
API'nizi temel alan müşteriler, beklenen performansa göre zaman aşımlarını ayarlar. Bölgelerinde gecikme arttığında entegrasyonları başarısız olmaya başlıyor. Günlüklerinde hatalar görüyorlar, son kullanıcıları sorunlar yaşıyor ve API'nizi suçluyorlar; genellikle siz bir sorun olduğunu bile anlamadan sessizce bir alternatife geçiyorlar.
Geliştirici deneyimi önemlidir. API'niz APAC'ta yavaşsa, o bölgedeki geliştiriciler bunu diğer geliştiricilere bildirecektir. Yığın Taşması yanıtları, Reddit konuları ve Hacker News yorumları bundan bahsedecek. Bir kalıp olduğunu fark ettiğinizde algı zaten kurulmuş demektir.
Etkili gecikme izleme, temel çizgileri oluşturmak ve gerilemeleri tespit etmek için coğrafi çeşitlilik, zamanlama ayrıntı düzeyi ve sürekli ölçüm gerektirir.
Kullanıcılarınız her yerdedir, dolayısıyla izlemeniz de öyle olmalıdır. Gecikme izleme API'sinin Kuzey Amerika, Avrupa, Asya-Pasifik, Latin Amerika, Orta Doğu ve Afrika'daki düğümlerden ölçüm yapması gerekir. Her konum, o bölgedeki kullanıcıların gerçekte yaşadığı gecikmeyi ortaya çıkarır.
İzleme konumlarını kullanıcı tabanı coğrafyanızla eşleştirin.
Toplam gecikmeyle ilgili işlem yapılamaz. Bilmeniz gerekenler: DNS ne kadar sürdü? TCP bağlantı süresi ne kadardı? TLS anlaşması ne kadar yavaştı? İçerik aktarımına karşı ilk bayt zamanı neydi? Bu döküm size sorunun hangi katmanda olduğunu ve bunu kimin düzeltebileceğini gösterir.
Sorunun DNS mi, ağ mı, SSL mi yoksa sunucunuz mu olduğunu teşhis edin.
Mumbai'den 400ms API'niz için iyi mi yoksa kötü mü? Bu sizin temel seviyenize bağlıdır. Sürekli gecikme izleme, bölge başına temel çizgiler oluşturur; böylece normalden sapmalar konusunda uyarıda bulunabilir ve dağıtımlar, ağ değişiklikleri veya CDN yanlış yapılandırmaları sonrasındaki gerilemeleri kullanıcılar fark etmeden yakalayabilirsiniz.
Yalnızca keyfi eşikler için değil, "normalden daha yavaş" konusunda da uyarı.
Bölgesel performans sorunlarını yakalayan gecikme izlemeyi uygulamaya yönelik pratik bir kılavuz.
API tüketicilerinizin nerede bulunduğunu belirlemek için analizleri inceleyin. Yalnızca üst düzey istatistiklere göre değil, ülkeye/bölgeye göre de kontrol edin. API çağrılarınızın %20'si APAC'tan geliyorsa, Asya-Pasifik genelinde izleme kapsamına ihtiyacınız vardır. Bölgeleri API kullanım hacmine ve gelire göre önceliklendirin.
Tüm uç noktaların küresel izlemeye ihtiyacı yoktur. Şunlara odaklanın: kimlik doğrulama uç noktaları, sıklıkla API rotaları olarak adlandırılan, müşteri entegrasyonları için kritik yoldaki uç noktalar ve SLA'nızda belirtilen uç noktalar. 3-5 kritik uç noktayla başlayın ve genişletin.
Kullanıcı coğrafyanızla eşleşen konumlardan uç noktalarınızı kontrol etmek için bir gecikme izleme API'si ayarlayın. Kritik uç noktalar için 1 dakikalık kontrol aralıklarını etkinleştirin. İzlemenin tam zamanlama dökümünü (DNS, TCP, TLS, TTFB, toplam) içerdiğinden emin olun.
Her bölge için temel gecikme sürelerini belirlemek amacıyla izlemenin 1-2 hafta sürmesine izin verin. Beklenen aralıkları belgeleyin: Tokyo 180 ms, Frankfurt ise 80 ms olabilir. Bu taban çizgileri, uyarı eşiklerinizi bilgilendirir ve gerilemelerin belirlenmesine yardımcı olur.
Bölgesel temel farklılıkları hesaba katan uyarıları yapılandırın. 500 ms'lik bir eşik Tokyo için anlamlıdır ancak Frankfurt için asla tetiklenmez. Yüzdeye dayalı eşikler kullanın (ör. temel değerin %50 üzerinde olduğunda uyarı verin) veya verilerinize göre bölgeye özgü mutlak eşikler belirleyin.
Gecikme uyarılarını Slack, PagerDuty veya mevcut olay yönetimi sisteminize yönlendirin. Çağrı üzerine mühendislerin kapsamı hemen bilmesi için bölge bilgilerini uyarılara ekleyin. Uyarıları, bölgesel gecikme sorunlarının nasıl tanılanacağını açıklayan runbook'lara bağlayın.
Traceroute ve MTR'yi isteğe bağlı olarak herhangi bir izleme konumundan çalıştırabildiğinizden emin olun. Bir uyarı tetiklendiğinde, sorunun DNS mi, belirli bir ağ atlama noktası mı, CDN uç noktanız mı yoksa kaynak sunucu mu olduğunu belirlemek için hemen teşhis verilerini yakalayın. Bu veriler sağlayıcılara iletmek için gereklidir.
Her dağıtımdan sonra, önemli bölgelerden gecikme kontrollerini tetikleyin ve temel değerle karşılaştırın. Gerilemeleri tüm kullanıcıları etkilemeden önce yakalayın. Bu özellikle yönlendirmeyi etkileyen CDN yapılandırmasında, DNS'de veya altyapıda yapılan değişiklikler için önemlidir.
Latency Global tam da bu kullanım durumu için geliştirildi; 6 kıtada 70'ten fazla konumdan gerçek gecikmeyi ölçtü. Her kontrol tam zamanlama dökümünü (DNS, TCP, TLS, TTFB) içerir, böylece gecikmenin nereden geldiğini teşhis edebilirsiniz.
Sorunları araştırırken traceroute ve MTR'yi herhangi bir yerden çalıştırabilirsiniz. Geçmiş veriler bölgesel eğilimleri gösterir ve monitör başına gecikme eşiği uyarıları ayarlayabilirsiniz. Gecikme kontrollerini dağıtım hattınıza veya özel kontrol panellerinize entegre etmek için tam bir REST API de mevcuttur. Tüm konumlara erişimi olan 5 monitör için fiyatlandırma ayda 5 ABD dolarından başlıyor.
Küresel bir izleme ağı çalıştırmak altyapı açısından yoğun bir iştir. Önemli olana odaklanarak fiyatlandırmayı her büyüklükteki ekip için erişilebilir tutuyoruz: coğrafi kapsam ve teşhis derinliği.
APM (Uygulama Performansı İzleme), sunucularınızın içinde olup bitenleri ölçer (kod yürütme süresi, veritabanı sorguları, dahili hizmet çağrıları). Gecikme izleme API'si, DNS çözümlemesi, ağ aktarımı, TLS anlaşması ve kodunuz yürütülmeden önce gerçekleşen diğer her şey dahil olmak üzere harici konumlardan tam gidiş-dönüş süresini ölçer. Tamamlayıcıdırlar: APM size sunucu verimliliğini gösterirken gecikme izleme kullanıcı deneyimini gösterir.
Kullanıcı dağıtımınıza bağlıdır. Temel olarak, önemli kullanıcıların bulunduğu her büyük bölge için 3-5 konum hedefleyin. Dünya çapındaki müşterilere hizmet veren küresel bir API için, 50'den fazla konum size kıtalar arasında makul bir kapsam sunar. Önemli olan, izleme konumlarını API tüketicilerinizin gerçekte bulunduğu yerlerle eşleştirmektir; en iyi ülkeleri belirlemek ve orada kapsam olduğundan emin olmak için analizlerinizi kontrol edin.
Evet. İyi bir gecikme izleme API'si, özel başlıklar, istek gövdeleri ve kimlik doğrulama ile tüm HTTP yöntemlerini (GET, POST, PUT, PATCH, DELETE) destekler. Bu, yalnızca bir sistem durumu uç noktasına yapılan basit GET'leri değil, kimliği doğrulanmış uç noktaları izlemenize, tam API istek/yanıt döngülerini test etmenize ve gerçekçi API çağrıları için gecikmeyi ölçmenize olanak tanır.
İlk olarak, bölge bazında temeller oluşturmak için izlemeyi 1-2 hafta çalıştırın. Daha sonra bu temellere göre eşikleri ayarlayın. Örneğin: "Gecikme bu bölge için 7 günlük ortalamanın %150'sini aşarsa uyarı ver" veya bölgeye özgü mutlak eşikler belirleyin (ABD-Doğu için 200 ms, APAC için 500 ms). Bazı ekipler aynı zamanda birden fazla bölgede aynı anda bozulma meydana geldiğinde devreye giren bileşik uyarılar kullanarak bölgesel ISP sorunlarını filtreliyor.
Tam bir zamanlama dökümü şunu gösterir: DNS arama süresi (etki alanınızı çözümleme), TCP bağlantı süresi (soket kurma), TLS anlaşması süresi (SSL/TLS anlaşması), ilk bayta kadar geçen süre (sunucunuzun yanıt vermesini beklemek) ve içerik aktarım süresi (yanıt gövdesini alma). Bu döküm size gecikmenin tam olarak nereye eklendiğini gösterir: DNS sorunları, ağ sorunları, SSL yükü veya yavaş sunucu işleme.
Evet, izleme hizmeti bir REST API sağlıyorsa. Dağıtımdan sonra API aracılığıyla önemli bölgelerden gecikme kontrollerini tetikleyin, sonuçları bekleyin ve temel eşiklerle karşılaştırın. Gecikme süresi kabul edilebilir sınırları aşarsa dağıtımda başarısız olun veya geri alma işlemini tetikleyin. Bu, performans gerilemelerini tüm kullanıcıları etkilemeden önce yakalar; özellikle CDN yapılandırma değişiklikleri veya altyapı güncellemeleri için değerlidir.
Belirli bölgelerdeki kullanıcıların neden yavaş API yanıtları bildirdiğini merak etmeyi bırakın. Uç noktalarınızı ekleyin, izleme konumlarınızı seçin ve kullanıcılarınızın destek bildirimi açmadan önce gerçekte bulundukları yerden gerçek gecikmeyi görün.
Ayda 5 ABD doları • 70'den fazla konum (yakında +40 daha) • Sözleşme yok • İstediğiniz zaman iptal edin