Cloudflare kesintileri, bölgesel CDN hataları ve uç düzeyindeki bozulmalar her zaman durum sayfalarında görünmez. CDN'nizin Tokyo POP'u kapandığında ancak küresel durumu yeşil göründüğünde, Virginia'daki izleme sisteminiz bunu yakalayamayacaktır.
Bölgesel kesinti tespiti, yalnızca altyapınızın olduğu yerden değil, kullanıcılarınızın gerçekte bulunduğu yerden izlemeyi gerektirir.
Saat gecenin 3'ü. Çağrı mühendisiniz müşteri başarısı karşısında uyarı alıyor: "Singapur'daki üç kurumsal müşteri uygulamaya erişemediklerini bildirdi. Yaklaşık iki saat önce başladı."
İzleme kontrol panelinizi kontrol ediyorsunuz; her şey yeşil. Cloudflare'in durum sayfası — çalışır durumda. AWS — olay yok. APM'niz — mutlu küçük grafikler. Yani müşterilerden tekrar denemelerini, önbelleklerini temizlemelerini, ağlarını kontrol etmelerini istiyorsunuz.
Ama olmaya devam ediyor. Aynı bölgeden daha fazla bilet. Sonunda birisi Singapur VPS'sinden traceroute çalıştırıyor ve şunu keşfediyor: trafik, 502'leri döndüren Cloudflare kenarına çarpıyor. CDN'de bir PoP'u etkileyen bölgesel bir kesinti var ve izleme yığınınızdaki hiçbir şey o bölgeden kontrol edilmiyor.
İki saatlik kesinti. Belirli bir coğrafya için. Sıfır uyarı. Bu sayfanın konusu olan kör nokta budur.
İster Cloudflare kesintisi, Fastly uç hatası veya Akamai bölgesel bozulması olsun, bu sorunların tespit edilmesi etkilenen bölgelerden izleme yapılmasını gerektirir. Sorunları müşteri sorunlarına dönüşmeden bu şekilde yakalarsınız.
İnternet tek bir ağ değildir. Sidney'den gelen bir talep, Frankfurt'tan gelen bir talepten tamamen farklı bir altyapı üzerinden geçiyor. Bu bölgesel yolun herhangi bir parçası başarısız olduğunda yalnızca o bölgedeki kullanıcılar etkilenir.
Cloudflare, Fastly ve Akamai gibi CDN'ler dünya çapında yüzlerce Varlık Noktasını (PoP) işletiyor. Belirli bir uç sunucuda veya PoP'de donanım arızası, yanlış yapılandırma veya kapasite sorunları gibi sorunlar yaşandığında yalnızca o uca yönlendirilen kullanıcılar etkilenir. Kenarların %95'i iyi durumda olduğundan CDN'nin genel durumu "işler durumda" kalır.
Örnek: Haziran 2022'de Cloudflare, ağ yapılandırması değişikliği nedeniyle 19 veri merkezini etkileyen 30 dakikalık bir kesinti yaşadı. Bu bölgelerdeki kullanıcılar hatalar gördü; başka yerlerdeki kullanıcılar olağandışı hiçbir şey yaşamadı.
DNS herhangi bir isteğin ilk adımıdır. Cloudflare 1.1.1.1 veya CDN'nizin DNS sunucuları belirli bir bölgede sorunlarla karşılaştığında (yanlış yapılandırılmış herhangi bir yayın rotası, aşırı yüklenmiş bir ad sunucusu) o bölgedeki kullanıcılar alanınızı çözemez. Tarayıcıları sadece "DNS_PROBE_FINISHED_NXDOMAIN" gösteriyor.
Örnek: Bölgesel DNS sorunları, İSS düzeyindeki filtrelemeden, yerel çözümleyici sorunlarından veya yalnızca belirli coğrafi bölgeleri etkileyen herhangi bir yayın yönlendirme sorunlarından kaynaklanabilir.
BGP rota sızıntıları, ele geçirmeler ve yanlış yapılandırmalar, trafiği yetersiz yollara yönlendirebilir veya tamamen kara delik oluşturabilir. Bir bölgedeki büyük bir taşıyıcının yönlendirme sorunları olduğunda, her iki uç nokta da mükemmel şekilde çalışıyor olsa bile, o bölgeden CDN'nize veya kaynağınıza giden trafik başarısız olabilir.
Örnek: BGP olayları düzenli olarak binlerce ağı etkiliyor. Yanlış yapılandırılmış tek bir AS yolu, sitenizin izleme konumunuzdan iyi görünmesine rağmen tüm ülkelerden saatlerce erişilemez olmasına neden olabilir.
Belirli ülkelerdeki büyük İSS'lerin, eşleme anlaşmazlıkları, tıkanıklık veya altyapı sorunları nedeniyle CDN'nize olan bağlantısı azalmış olabilir. Avustralya'daki Telstra kullanıcıları hatalarla karşılaşabilirken aynı şehirdeki Optus kullanıcıları herhangi bir sorun yaşamayabilir; çünkü trafik farklı yollardan akar.
Örnek: İSS'ler ile bulut sağlayıcıları arasındaki eşleştirme anlaşmazlıkları, geçmişte belirli pazarlardaki milyonlarca kullanıcıyı etkileyen birkaç hafta süren bozulmalara neden olmuştur.
Ortak konu: Bu hataların tümü coğrafi kapsamdadır. Kökeniniz yukarıda. CDN yapılandırmanız doğru. Ancak uç noktanız ile belirli bir bölgedeki kullanıcılar arasında bir yerde bir şey bozuldu ve Virginia'daki tek bir konumdan kontrol yapan izleme sisteminizin bunu tespit etmesinin hiçbir yolu yok.
Çalışma süresi izlemenin çoğu daha basit bir sorun için tasarlandı: "Sunucu yanıt veriyor mu?" Global kullanıcılara hizmet veren CDN hızlandırmalı siteler için bu artık doğru soru değil.
Çoğu izleme hizmeti, varsayılan olarak bir avuç ABD veya AB konumundan kontrol etme yöntemini kullanır. Cloudflare'in Singapur PoP'u düşerse, Oregon'dan gelen çekiniz yine de başarılı olacaktır; farklı ve sağlıklı bir noktaya ulaşır. Bu arada APAC kullanıcılarınız 502 hatası görüyor.
AWS'den Cloudflare'e kontrol çalıştırmak, gerçek kullanıcı trafiğini temsil etmeyen, optimize edilmiş yollar olan bulut omurga bağlantısını kullanır. AWS ap-southeast-1'den gelen sentetik kontrolünüz, yerel İSS'lerdeki kullanıcılar için başarısız olan ağ yolunu tam olarak atlayabilir.
CDN durum sayfaları, genellikle yüzlerce PoP üzerinden toplanan dahili görünümleri yansıtır. Altyapılarının %5'ini etkileyen bölgesel bir sorun, durum sayfası güncellemesini tetiklemeyebilir; ancak bu %5, Güneydoğu Asya'nın tamamını kapsayabilir.
HTTP kontrolleri size bir isteğin başarılı mı yoksa başarısız mı olduğunu söyler ancak nerede başarısız olduğunu söylemez. Etkilenen bölgeden traceroute ve gecikme dökümü verileri olmadan sorunun DNS mi, belirli bir ağ atlama noktası mı yoksa CDN uç noktanız mı olduğunu belirleyemezsiniz.
Cloudflare'de 310'dan fazla PoP var. İzlemeniz 3 konumdan kontrol yapıyorsa kullanıcılarınızın karşılaşabileceği avantajların %1'inden daha azını doğruluyorsunuz demektir. Bu, kesinti tespiti değil; en iyisini ummaktır.
Cloudflare kesintisi veya bölgesel CDN hatasının fark edilmediği her dakika, kullanıcılarınızı, gelirinizi ve hizmet verdiğinizin farkında bile olmadığınız pazarlara olan güveninizi kaybedersiniz.
Söz konusu saat dilimindeki iş saatleri sırasında meydana gelen bölgesel bir kesinti, saatlerce süren işlemlere, kayıtlara veya API çağrılarına mal olabilir. Kullanıcılar "siteniz benim için kapalı" e-postaları göndermezler; sadece ayrılırlar. Daha sonra bölgesel metriklerde net bir neden atfedilmeden bir düşüş göreceksiniz.
Kurumsal müşterilerin SLA'ları vardır. Platformunuza erişemedikleri zaman ve siz bir sorun olduğunu bile bilmiyorsanız, bu kötü bir konuşmadır. "Kesintiyi tespit edemedik" ifadesi güven oluşturan bir yanıt değildir; özellikle de güvenilirlik için para ödüyorlarsa.
Googlebot birden çok küresel konumdan tarama yapar. Bir bölgedeki CDN uç noktanız hatalar veya yavaş yanıtlar döndürüyorsa bu, tarama bütçesini, Önemli Web Verileri değerlendirmelerini ve son olarak sıralamaları etkiler. Belirli pazarlarda belirgin bir neden olmaksızın trafik düşüşleri görebilirsiniz.
Sorunu tespit ettiğinizde Ortalama Kurtarma Süresi (MTTR) başlar. Bölgesel bir Cloudflare kesintisi, siz bunu bir müşteri biletinden öğrenmeden önce kullanıcıları 2 saat boyunca etkiliyorsa, bu, geçerli MTTR'nize 2 saat eklenir. Proaktif tespit, gerçek kesinti süresi etkisini en aza indirmenin tek yoludur.
Bölgesel kesinti tespiti, arızaların nerede meydana geldiğini belirlemek için teşhis derinliğiyle kullanıcılarınızın bulunduğu yerden izlemeyi gerektirir.
Her izleme konumu farklı CDN kenarlarına ulaşır ve farklı ağ yollarından geçer. Bölgesel kesintileri tespit etmek için, anlamlı trafiğin olduğu her bölgede (Asya-Pasifik, Avrupa, Amerika, Orta Doğu, Afrika) düğümlere ihtiyacınız vardır. Yalnızca "uluslararası" değil, özellikle kullanıcılarınızın bulunduğu yer.
50'den fazla konumdan izleme, önemli CDN PoP'ları ve ISP yollarını kapsar.
Bir denetim Singapur'da başarısız olup başka her yerde başarılı olduğunda şunu bilmeniz gerekir: Denetim DNS mi? Belirli bir ağ atlaması mı? CDN kenarı mı? Etkilenen konumdaki Traceroute ve MTR, temel nedeni teşhis etmek ve bunu Cloudflare'e, İSS'nize veya barındırma sağlayıcınıza iletmek için ihtiyaç duyduğunuz kanıtı sağlar.
Teşhis verileri, "bir şeyin bozuk olduğunu" eyleme dönüştürülebilir temel nedene dönüştürür.
Tokyo'dan 400 ms normal mi yoksa bu Cloudflare kenar bozulması mı? Konum başına geçmiş veriler, yavaş arızaları tespit etmenize olanak tanıyan temel çizgiler oluşturur; ciddi arızaları tetiklemeyen ancak kullanıcı deneyimini olumsuz etkileyen gecikme artışları. Bölgesel bir CDN sorununu tam bir kesintiye dönüşmeden yakalayabilirsiniz.
Temel hatlar, bozulmaları kesintiye dönüşmeden yakalar.
Cloudflare kesintilerini ve bölgesel CDN hatalarını kullanıcılarınız bildirmeden önce yakalayan izlemeyi uygulamaya yönelik adım adım kılavuz.
Kullanıcılarınızın nerede olduğunu belirlemek için analizlerinizi kontrol edin. Trafiğin %20'si Asya-Pasifik'ten geliyorsa, orada birden fazla izleme düğümüne ihtiyacınız vardır (Singapur, Tokyo, Sidney, Mumbai). İzleme kapsamını gerçek kullanıcı dağıtımıyla eşleştirin.
Cloudflare veya CDN'nizden geçen birincil URL'leriniz için HTTP monitörleri ayarlayın. Bunlar doğrudan kaynağınıza değil, CDN sınırına ulaşmalıdır. Uygulama alanınızı, API uç noktalarınızı ve tüm kritik genel sayfalarınızı ekleyin.
Farklı bölgelerin farklı temel gecikme süreleri vardır. Mantıklı eşikleri yapılandırın: Avrupa'dan 500 ms kabul edilebilir olabilir, ancak ABD-Doğu'dan 500 ms (kökeniniz orada olduğunda) bir CDN uç sorununa işaret eder. Gerçekçi temel çizgileri belirlemek için geçmiş verileri kullanın.
Yalnızca tüm konumların arızalanması durumunda değil, belirli bölgelerin arızalanması durumunda tetiklenecek uyarılar ayarlayın. Yalnızca Singapur'daki bir arıza hâlâ bilmeye değer bir kesintidir. Yüksek öncelikli uyarıları Slack, PagerDuty veya olay yönetimi sisteminize yönlendirin.
Bir uyarı tetiklendiğinde hızlı bir şekilde şunu belirlemeniz gerekir: Bu Cloudflare'in sorunu mu? Ağ yolu sorunu mu? DNS'ler mi? Teşhis verilerini anında toplayabilmek için izleme konumlarından isteğe bağlı traceroute ve MTR'yi etkinleştirin.
Süreci belgeleyin: Cloudflare bölgesel kesintisi nasıl doğrulanır? Cloudflare'in durum API'sinin nerede kontrol edileceği. Kanıtlı bir bilet nasıl açılır? Hangi azaltımları uygulayabilirsiniz (yük devretme, önbellek atlama vb.). Bunun hazır olması MTTR'yi önemli ölçüde azaltır.
Bölgeye göre gecikmeyi ve çalışma süresini incelemek için haftalık bir takvim hatırlatıcısı ayarlayın. Kalıpları arayın: APAC sürekli olarak daha mı yavaş? Belirli bir yerde düzenli olarak patlamalar var mı? Proaktif inceleme, kullanıcıları önemli ölçüde etkilemeden önce yavaş yavaş gerçekleşen bozulmaları yakalar.
Bölgesel kesintilerin kabul edilemez olduğu hizmetler için, DNS'nin sağlayıcılar arasında yük devretebildiği çoklu CDN stratejisini düşünün. Bu, her CDN'nin bağımsız olarak izlenmesini ve trafiği değiştirebilecek otomasyona sahip olmayı gerektirir. Bu karmaşıklıktır, ancak dayanıklılıktır.
Latency Global tam olarak bu tür sorunları (Cloudflare kesintileri, bölgesel CDN arızaları ve tek konumlu izlemenin gözden kaçırdığı ağ sorunları) tespit etmek için tasarlandı. Tüm önemli CDN PoP bölgelerini kapsayan 6 kıtada 70'ten fazla gerçek konumdan izliyoruz.
Her kontrol, tam zamanlama dökümünü içerir - DNS çözümlemesi, TCP bağlantısı, TLS anlaşması, TTFB ve toplam yanıt süresi. Belirli bir bölgede bir hata oluştuğunda, sorunun ağ yolunun tam olarak neresinde oluştuğunu belirlemek için bu konumdan traceroute ve MTR'yi çalıştırabilirsiniz. Fiyatlandırma basittir: 5 monitör için ayda 5 ABD doları, tüm konumlar dahildir.
Bölgesel kesinti tespiti, birçok konumda altyapı gerektirir; bu nedenle çoğu izleme aracı ya bunu sunmaz ya da kurumsal fiyatlar talep eder. Önemli olana odaklanıyoruz: kapsam ve teşhis derinliği.
Bir CDN ağındaki belirli uç sunucular veya Varlık Noktaları (PoP'ler) başarısız olduğunda veya bozulduğunda, diğer uçlar çalışır durumda kaldığında bölgesel bir CDN kesintisi meydana gelir. Örneğin Cloudflare'in ABD ve Avrupa sınırları iyi çalışırken Singapur PoP'sinde sorunlar olabilir. Etkilenen uç üzerinden yönlendirme yapan kullanıcılar hatalarla veya yavaş performansla karşılaşıyor; başka yerlerdeki kullanıcılar hiçbir şey fark etmez. Bu kesintiler, yalnızca etkilenmeyen bölgelerden kontrol edilen izleme tarafından görülmez.
CDN durum sayfaları genellikle PoP başına durumu değil, toplu genel durumu gösterir. Kenarların %5'i etkilendiğinde, altyapının %95'i çalıştığından genel durum "Çalışır durumda" kalabilir. Durum sayfalarının da güncelleme gecikmesi vardır; sorunların algılanması, doğrulanması ve yayınlanması zaman alır. Ayrıca, bazı sorunlar kamuya açıklama eşiğini karşılamamasına rağmen yine de kullanıcılarınızı etkilemektedir. Birden fazla konumdan bağımsız izleme, bölgesel kullanılabilirlik hakkında temel gerçekleri elde etmenin tek yoludur.
En azından kullanıcılarınızın bulunduğu her büyük bölgede izleme konumlarına ihtiyacınız var: en azından Kuzey Amerika, Avrupa ve Asya-Pasifik. Daha iyi kapsam için, küresel olarak dağıtılan 50'den fazla konum, bölgesel sorunların çoğunu yakalayacaktır. Önemli olan, izleme kapsamını kullanıcı coğrafyanızla eşleştirmektir; kullanıcılarınızın %30'u APAC'taysa, orada birden fazla düğüme ihtiyacınız vardır (Singapur, Tokyo, Sidney, Mumbai). Önemli olan her CDN PoP'u eşleştirmek değil, büyük bölgesel grupları kapsamak.
Öncelikle teşhis kanıtlarını toplayın: etkilenen konumdan traceroute ve MTR, HTTP yanıt kodları ve zamanlama verileri ve zaman damgaları. Herhangi bir bildirim için Cloudflare'in durum sayfasını ve Twitter'ı kontrol edin. Açıkça bir Cloudflare sorunuysa kanıtlarınızla birlikte bir destek bildirimi açın. Etkiyi anında azaltmak için şunları göz önünde bulundurun: etkilenen bölge için Cloudflare'i geçici olarak atlamayı (kaynakınız bunu kaldırabiliyorsa), çoklu CDN yeteneğiniz varsa yedek bir CDN'yi etkinleştirmeyi veya Cloudflare sorunu çözerken sorunu onaylamak için durum sayfanızı güncellemeyi düşünün. Olay sonrası inceleme için her şeyi belgeleyin.
Evet, uygun izleme cihazlarıyla. Tam HTTP kontrolü zamanlaması şunları gösterir: DNS çözümleme süresi (DNS başarısız olursa veya yavaşsa, bunun bir DNS sorunu olduğunu bilirsiniz), TCP bağlantı süresi (ağ yolu sorunları), TLS anlaşması süresi (sertifika veya kripto sorunları) ve TTFB/yanıt süresi (kaynak veya uç işleme sorunları). Traceroute ağ yolunu ve paketlerin nerede bırakıldığını veya geciktirildiğini gösterir. Etkilenen bölgeden ve sağlıklı bölgelerden alınan bu verileri karşılaştırarak, istek zincirinde hatanın tam olarak nerede oluştuğunu belirleyebilirsiniz.
1 dakikalık kontrol aralıkları ile kesintiyi başladıktan 1-2 dakika sonra tespit edebilirsiniz. Çoğu izleme hizmeti, geçici uyarı sinyallerinden kaçınmak için art arda 2-3 arızadan sonra kesintiyi doğrular; dolayısıyla gerçekçi algılama süresi 2-5 dakikadır. Bunu, destek bildirimleri aracılığıyla ortaya çıkması saatler alabilen, müşteri tarafından bildirilen kesintilerle karşılaştırın. MTTR'deki fark önemlidir; 5 dakika ile 2 saat arasındaki süre, kullanıcı üzerinde çok farklı bir etki anlamına gelir.
Kesinlikle. Hızlı bir şekilde Akamai, AWS CloudFront, Google Cloud CDN, Azure CDN ve diğer CDN'lerde bölgesel kesintiler yaşanabilir. Aynı ilkeler geçerlidir: CDN'ler dağıtılmış altyapıya sahiptir ve herhangi bir dağıtılmış sistemde kısmi arızalar olabilir. Algılama yaklaşımı aynıdır: Hangi CDN'yi kullanırsanız kullanın, belirli kenarları veya bölgeleri etkileyen sorunları yakalamak için birden fazla küresel konumdan izleyin.
Bölgesel kesintiler hakkında bilgi edinmek için CDN durum sayfalarına ve müşteri biletlerine güvenmeyi bırakın. Uç noktalarınızı ekleyin, izleme konumlarınızı seçin ve Cloudflare, Fastly veya yığınınızın herhangi bir bölümünün herhangi bir bölgede arızalanması durumunda dakikalar içinde bilgi edinin.
Ayda 5 ABD doları • 70'den fazla konum (yakında +40 daha) • Sözleşme yok • İstediğiniz zaman iptal edin