Awarie Cloudflare, regionalne awarie CDN i degradacje na poziomie brzegowym nie zawsze są widoczne na stronach stanu. Kiedy punkt POP Twojej sieci CDN w Tokio ulegnie awarii, ale jej status globalny zmieni się na zielony, Twój monitoring z Wirginii tego nie wykryje.
Wykrywanie regionalnych przestojów wymaga monitorowania miejsca, w którym faktycznie znajdują się użytkownicy — a nie tylko miejsca, w którym znajduje się infrastruktura.
Jest 3 nad ranem. Twój dyżurny inżynier otrzymuje sygnał ping w związku z sukcesem klienta: „Trzej klienci korporacyjni w Singapurze zgłosili, że nie mogą uzyskać dostępu do aplikacji. Zaczęło się około dwóch godzin temu”.
Sprawdzasz pulpit monitorujący – wszystko jest zielone. Strona stanu Cloudflare — działa. AWS — bez incydentów. Twój APM — szczęśliwe małe wykresy. Prosisz więc klientów, aby spróbowali ponownie, wyczyścili pamięć podręczną i sprawdzili swoją sieć.
Ale to się ciągle dzieje. Więcej biletów z tego samego regionu. W końcu ktoś uruchamia trasowanie z singapurskiego VPS i odkrywa: ruch trafia na krawędź Cloudflare, która zwraca 502. W sieci CDN występuje przestój regionalny wpływający na jeden punkt sprzedaży — i nic w stosie monitorowania nie sprawdza tego regionu.
Dwie godziny przerwy. Dla konkretnej geografii. Zerowe alerty. To jest właśnie ten słaby punkt, o którym mówi ta strona.
Niezależnie od tego, czy jest to awaria Cloudflare, awaria Fastly Edge, czy regionalna degradacja Akamai — wykrycie tych problemów wymaga monitorowania w dotkniętych regionach. W ten sposób wychwytujesz problemy, zanim staną się eskalacją u klienta.
Internet nie jest pojedynczą siecią. Żądanie z Sydney przechodzi przez zupełnie inną infrastrukturę niż żądanie z Frankfurtu. Jeśli jakikolwiek element tej ścieżki regionalnej ulegnie awarii, dotyczy to tylko użytkowników w tym regionie.
Sieci CDN, takie jak Cloudflare, Fastly i Akamai, obsługują setki punktów obecności (PoP) na całym świecie. Kiedy na konkretnym serwerze brzegowym lub PoP występują problemy — awaria sprzętu, błędna konfiguracja lub problemy z wydajnością — dotyczy to tylko użytkowników przekierowanych do tego brzegu. Globalny status sieci CDN pozostaje „operacyjny”, ponieważ 95% krawędzi jest w porządku.
Przykład: w czerwcu 2022 r. Cloudflare miała 30-minutową awarię, która dotknęła 19 centrów danych ze względu na zmianę konfiguracji sieci. Użytkownicy w tych regionach zauważyli błędy; użytkownicy w innych miejscach nie doświadczyli niczego niezwykłego.
DNS to pierwszy krok w każdym żądaniu. Kiedy na serwerach DNS Cloudflare 1.1.1.1 lub Twojej CDN występują problemy w określonym regionie – źle skonfigurowana trasa anycast, przeciążony serwer nazw – użytkownicy w tym regionie nie mogą rozpoznać Twojej domeny. Ich przeglądarka wyświetla po prostu „DNS_PROBE_FINISHED_NXDOMAIN”.
Przykład: regionalne problemy z DNS mogą być spowodowane filtrowaniem na poziomie dostawcy usług internetowych, problemami z lokalnym programem rozpoznawania nazw lub problemami z routingiem anycast, które dotyczą tylko określonych obszarów geograficznych.
Wycieki, przejęcia i błędne konfiguracje tras BGP mogą przekierować ruch na nieoptymalne ścieżki lub całkowicie go zablokować. Gdy główny operator w regionie ma problemy z routingiem, ruch z tego regionu do Twojej sieci CDN lub punktu początkowego może się nie powieść — nawet jeśli oba punkty końcowe działają doskonale.
Przykład: incydenty BGP regularnie wpływają na tysiące sieci. Pojedyncza źle skonfigurowana ścieżka AS może sprawić, że Twoja witryna będzie nieosiągalna z całych krajów przez wiele godzin, a jednocześnie będzie wyglądać dobrze z Twojej lokalizacji monitorowania.
Główni dostawcy usług internetowych w określonych krajach mogli pogorszyć łączność z Twoją siecią CDN z powodu sporów peeringowych, zatorów lub problemów z infrastrukturą. Użytkownicy Telstry w Australii mogą doświadczyć awarii, podczas gdy użytkownicy Optus w tym samym mieście nie mają żadnych problemów – ponieważ ruch odbywa się różnymi ścieżkami.
Przykład: Spory peeringowe między dostawcami usług internetowych a dostawcami usług w chmurze w przeszłości powodowały wielotygodniowe degradacje, które dotykały miliony użytkowników na określonych rynkach.
Wspólny wątek: wszystkie te awarie mają zasięg geograficzny. Twoje pochodzenie się skończyło. Konfiguracja CDN jest poprawna. Jednak gdzieś pomiędzy Twoją krawędzią a użytkownikami w określonym regionie coś się zepsuło — a Twoje monitorowanie, które sprawdza z jednej lokalizacji w Wirginii, nie jest w stanie tego wykryć.
Większość monitorowania czasu pracy została zaprojektowana z myślą o prostszym problemie: „Czy serwer odpowiada?” W przypadku witryn przyspieszanych przez CDN obsługujących użytkowników z całego świata nie jest to już właściwe pytanie.
Większość usług monitorowania domyślnie sprawdza w kilku lokalizacjach w USA lub UE. Jeśli Singapur PoP Cloudflare spadnie, Twój czek z Oregonu nadal się powiedzie — osiągnie inną, zdrową przewagę. Tymczasem użytkownicy w regionie Azji i Pacyfiku widzą błędy 502.
Uruchamianie kontroli z AWS do Cloudflare wykorzystuje łączność szkieletową chmury — zoptymalizowane ścieżki, które nie reprezentują rzeczywistego ruchu użytkowników. Twoje syntetyczne sprawdzenie z AWS ap-sutheast-1 może ominąć dokładną ścieżkę sieciową, która nie działa dla użytkowników lokalnych dostawców usług internetowych.
Strony stanu CDN odzwierciedlają ich widok wewnętrzny, często zagregowany dla setek punktów PoP. Problem regionalny wpływający na 5% ich infrastruktury może nie powodować aktualizacji strony stanu, ale te 5% może obejmować całą Azję Południowo-Wschodnią.
Kontrole HTTP informują, czy żądanie się powiodło, czy nie, ale nie informują, gdzie to się nie udało. Bez danych śledzenia tras i opóźnień z dotkniętego regionu nie można określić, czy problemem jest DNS, konkretny przeskok sieci czy brzeg CDN.
Cloudflare ma ponad 310 punktów PoP. Jeśli monitorujesz z 3 lokalizacji, sprawdzasz mniej niż 1% krawędzi, na które mogą natrafić użytkownicy. To nie jest wykrywanie przestojów — to nadzieja na najlepsze.
Z każdą minutą, w której awaria Cloudflare lub regionalna awaria CDN pozostaje niewykryta, tracisz użytkowników, przychody i zaufanie do rynków, z których możesz nawet nie zdawać sobie sprawy, że obsługujesz.
Regionalna awaria w godzinach pracy w tej strefie czasowej może kosztować godziny transakcji, rejestracji lub wywołań API. Użytkownicy nie wysyłają e-maili z informacją, że Twoja witryna jest niedostępna — po prostu ją opuszczają. Później zauważysz spadek wskaźników regionalnych, bez jasnego przypisania przyczyny.
Klienci korporacyjni mają umowy SLA. Kiedy nie mogą uzyskać dostępu do Twojej platformy, a Ty nawet nie wiesz, że wystąpił problem, jest to zła rozmowa. „Nie wykryliśmy awarii” nie jest odpowiedzią budującą zaufanie — zwłaszcza gdy płacą za niezawodność.
Googlebot indeksuje z wielu lokalizacji na całym świecie. Jeśli Twoja krawędź CDN w regionie zwraca błędy lub powolne odpowiedzi, ma to wpływ na budżet indeksowania, oceny Core Web Vitals i ostatecznie na rankingi. Możesz zauważyć spadek ruchu na określonych rynkach bez oczywistej przyczyny.
Średni czas do odzyskania (MTTR) rozpoczyna się w momencie wykrycia problemu. Jeśli regionalna awaria Cloudflare dotyka użytkowników przez 2 godziny, zanim dowiesz się o niej ze zgłoszenia klienta, do efektywnego MTTR zostaną dodane 2 godziny. Proaktywne wykrywanie to jedyny sposób na zminimalizowanie rzeczywistego wpływu przestojów.
Wykrywanie regionalnych przestojów wymaga monitorowania z miejsca, w którym znajdują się użytkownicy, oraz dogłębnej diagnostyki umożliwiającej identyfikację miejsc występowania awarii.
Każda lokalizacja monitorowania trafia na różne krawędzie CDN i przechodzi przez różne ścieżki sieciowe. Aby wykryć regionalne awarie, potrzebujesz węzłów w każdym regionie, w którym występuje znaczący ruch — w regionie Azji i Pacyfiku, Europie, obu Amerykach, Bliskim Wschodzie i Afryce. Nie tylko „międzynarodowe” – zwłaszcza tam, gdzie przebywają Twoi użytkownicy.
Monitorowanie z ponad 50 lokalizacji obejmuje główne punkty PoP CDN i ścieżki dostawców usług internetowych.
Kiedy kontrola w Singapurze kończy się niepowodzeniem, ale w innym miejscu kończy się sukcesem, musisz wiedzieć: czy chodzi o DNS? Konkretny przeskok sieciowy? Krawędź CDN? Traceroute i MTR z dotkniętej lokalizacji dostarczają dowodów potrzebnych do zdiagnozowania pierwotnej przyczyny i przekazania sprawy do Cloudflare, dostawcy usług internetowych lub dostawcy usług hostingowych.
Dane diagnostyczne zmieniają „coś jest zepsute” w pierwotną przyczynę, którą można podjąć.
Czy 400 ms od Tokio jest normalne, czy jest to degradacja krawędzi Cloudflare? Dane historyczne na lokalizację tworzą wartości bazowe, które pozwalają wykryć powolne awarie — wzrost opóźnień nie powoduje poważnych awarii, ale pogarsza komfort użytkownika. Możesz wykryć regionalny problem z CDN, zanim stanie się on pełną awarią.
Linie bazowe wychwytują degradacje, zanim staną się przestojami.
Przewodnik krok po kroku dotyczący wdrażania monitorowania, które wychwytuje awarie Cloudflare i regionalne awarie CDN, zanim użytkownicy je zgłoszą.
Sprawdź swoje statystyki, aby określić, gdzie znajdują się Twoi użytkownicy. Jeśli 20% ruchu pochodzi z regionu Azji i Pacyfiku, potrzebujesz tam wielu węzłów monitorowania — Singapur, Tokio, Sydney, Bombaj. Dopasuj zakres monitorowania do rzeczywistej dystrybucji użytkowników.
Skonfiguruj monitory HTTP dla głównych adresów URL przechodzących przez Cloudflare lub Twoją sieć CDN. Powinny one trafić na krawędź CDN, a nie bezpośrednio na Twoje źródło. Uwzględnij domenę aplikacji, punkty końcowe interfejsu API i wszelkie krytyczne strony publiczne.
Różne regiony mają różne opóźnienia podstawowe. Skonfiguruj progi, które mają sens: być może 500 ms od Europy jest akceptowalne, ale 500 ms od wschodu Stanów Zjednoczonych (jeśli tam znajduje się Twoje źródło) wskazuje na problem z krawędzią CDN. Użyj danych historycznych, aby ustalić realistyczne wartości bazowe.
Skonfiguruj alerty uruchamiane w przypadku awarii określonych regionów — a nie tylko w przypadku awarii wszystkich lokalizacji. Awaria występująca wyłącznie w Singapurze jest nadal przestojem, o którym warto wiedzieć. Kieruj alerty o wysokim priorytecie do Slack, PagerDuty lub systemu zarządzania incydentami.
Kiedy uruchomi się alert, musisz szybko ustalić: czy jest to problem Cloudflare? Problem ze ścieżką sieciową? DNS? Włącz na żądanie funkcję śledzenia tras i MTR z lokalizacji monitorowania, aby móc natychmiast zbierać dane diagnostyczne.
Udokumentuj proces: Jak zweryfikować regionalną awarię Cloudflare. Gdzie sprawdzić API statusu Cloudflare. Jak otworzyć bilet z dowodem. Jakie środki zaradcze można zastosować (przełączenie awaryjne, obejście pamięci podręcznej itp.). Posiadanie tego rozwiązania znacznie zmniejsza MTTR.
Ustaw cotygodniowe przypomnienie w kalendarzu, aby sprawdzić opóźnienia i czas pracy w poszczególnych regionach. Poszukaj wzorców: czy region APAC jest stale wolniejszy? Czy w określonym miejscu występują regularne sygnały? Przegląd proaktywny wychwytuje powolne degradacje, zanim będą one miały znaczący wpływ na użytkowników.
W przypadku usług, w przypadku których awarie regionalne są niedopuszczalne, należy rozważyć strategię wielu CDN, w której DNS może przełączać się awaryjnie między dostawcami. Wymaga to niezależnego monitorowania każdej sieci CDN i posiadania automatyzacji, która może przełączać ruch. To złożoność, ale to odporność.
Latency Global został zbudowany, aby wykrywać dokładnie tego rodzaju problemy — awarie Cloudflare, awarie regionalnych sieci CDN i problemy z siecią, których brakuje w monitorowaniu pojedynczej lokalizacji. Monitorujemy z 70+ rzeczywistych lokalizacji na 6 kontynentach, obejmujących wszystkie główne regiony PoP CDN.
Każde sprawdzenie obejmuje pełny podział czasu — rozdzielczość DNS, połączenie TCP, uzgadnianie TLS, TTFB i całkowity czas odpowiedzi. Jeśli coś ulegnie awarii w określonym regionie, możesz uruchomić polecenie Traceroute i MTR z tej lokalizacji, aby dokładnie określić, gdzie na ścieżce sieciowej wystąpił problem. Ceny są proste: 5 USD/miesiąc za 5 monitorów ze wszystkimi lokalizacjami.
Wykrywanie regionalnych przestojów wymaga infrastruktury w wielu lokalizacjach — dlatego większość narzędzi monitorujących albo jej nie oferuje, albo pobiera opłaty dla przedsiębiorstw. Koncentrujemy się na tym, co ważne: zasięgu i głębokości diagnostycznej.
Regionalna awaria sieci CDN ma miejsce, gdy określone serwery brzegowe lub punkty obecności (PoP) w sieci CDN ulegają awarii lub ulegają degradacji, podczas gdy inne brzegi nadal działają. Na przykład Cloudflare może mieć problemy z Singapurskim PoP, podczas gdy ich amerykańskie i europejskie brzegi działają dobrze. Użytkownicy przekierowujący przez dotkniętą krawędź doświadczają błędów lub niskiej wydajności; użytkownicy w innych miejscach niczego nie zauważają. Te awarie są niewidoczne dla monitorowania, które sprawdza tylko regiony, których nie dotyczą.
Strony stanu CDN zazwyczaj pokazują łączny stan globalny, a nie stan poszczególnych punktów sprzedaży. Gdy problem dotyczy 5% krawędzi, ogólny stan może pozostać „Działający”, ponieważ 95% infrastruktury działa. Strony stanu również charakteryzują się opóźnieniami w aktualizacji — wykrycie, zweryfikowanie i opublikowanie problemów wymaga czasu. Ponadto niektóre problemy nie spełniają progu publicznego ujawnienia, ale mimo to wpływają na użytkowników. Niezależny monitoring z wielu lokalizacji to jedyny sposób, aby uzyskać podstawową wiedzę na temat dostępności regionalnej.
Potrzebujesz lokalizacji monitorowania co najmniej w każdym większym regionie, w którym masz użytkowników: co najmniej w Ameryce Północnej, Europie i regionie Azji i Pacyfiku. Aby zapewnić lepszy zasięg, ponad 50 lokalizacji rozmieszczonych na całym świecie będzie w stanie wykryć większość problemów regionalnych. Kluczem jest dopasowanie zasięgu monitorowania do lokalizacji geograficznej użytkowników — jeśli 30% Twoich użytkowników znajduje się w regionie APAC, potrzebujesz tam wielu węzłów (Singapur, Tokio, Sydney, Bombaj). Nie chodzi o dopasowanie każdego PoP CDN, ale o uwzględnienie głównych grup regionalnych.
Najpierw zbierz dowody diagnostyczne: traceroute i MTR z dotkniętej lokalizacji, kody odpowiedzi HTTP i dane o czasie oraz znaczniki czasu. Sprawdź stronę stanu Cloudflare i Twittera, aby uzyskać potwierdzenie. Jeśli jest to wyraźnie problem Cloudflare, otwórz zgłoszenie do pomocy technicznej, przedstawiając swoje dowody. Aby natychmiast zaradzić problemowi, rozważ: tymczasowe ominięcie Cloudflare dla dotkniętego regionu (jeśli Twoje źródło może sobie z tym poradzić), włączenie zapasowej sieci CDN, jeśli masz możliwość obsługi wielu CDN lub zaktualizowanie strony stanu, aby potwierdzić problem do czasu, aż Cloudflare go rozwiąże. Udokumentuj wszystko do przeglądu po incydencie.
Tak, z odpowiednimi urządzeniami monitorującymi. Pełny czas sprawdzania HTTP pokazuje: czas rozpoznawania DNS (jeśli DNS zawodzi lub jest powolny, wiesz, że to problem DNS), czas połączenia TCP (problemy ze ścieżką sieciową), czas uzgadniania TLS (problemy z certyfikatem lub kryptowalutą) oraz czas TTFB/odpowiedzi (problemy z początkiem lub przetwarzaniem brzegowym). Traceroute pokazuje ścieżkę sieciową oraz miejsca, w których pakiety są odrzucane lub opóźniane. Porównując te dane z regionu, którego dotyczy problem, z regionami w dobrej kondycji, można dokładnie określić, gdzie w łańcuchu żądań występuje awaria.
Dzięki 1-minutowym interwałom kontrolnym możesz wykryć awarię w ciągu 1-2 minut od jej uruchomienia. Większość usług monitorujących potwierdza awarię po 2-3 kolejnych awariach, aby uniknąć ostrzegania w przypadku przejściowych impulsów, dlatego realistyczny czas wykrycia wynosi 2-5 minut. Porównaj to z awariami zgłaszanymi przez klientów, których ujawnienie za pośrednictwem zgłoszeń do pomocy technicznej może zająć kilka godzin. Różnica w MTTR jest znacząca — 5 minut w porównaniu z 2 godzinami oznacza zupełnie inny wpływ na użytkownika.
Absolutnie. Szybko Akamai, AWS CloudFront, Google Cloud CDN, Azure CDN i każda inna sieć CDN mogą doświadczyć regionalnych przestojów. Obowiązują te same zasady: sieci CDN mają infrastrukturę rozproszoną, a każdy system rozproszony może mieć częściowe awarie. Podejście do wykrywania jest takie samo — monitoruj z wielu lokalizacji na całym świecie, aby wychwycić problemy wpływające na określone krawędzie lub regiony, niezależnie od używanej sieci CDN.
Przestań polegać na stronach statusu CDN i biletach klientów, aby dowiedzieć się o regionalnych awariach. Dodaj swoje punkty końcowe, wybierz lokalizacje monitorowania i w ciągu kilku minut dowiedz się, kiedy Cloudflare, Fastly lub jakakolwiek część Twojego stosu ulegnie awarii w dowolnym regionie.
5 USD/miesiąc • Ponad 70 lokalizacji (+40 więcej wkrótce) • Brak umów • Anuluj w dowolnym momencie