Sự cố ngừng hoạt động của Cloudflare, lỗi CDN khu vực và sự xuống cấp ở cấp độ biên không phải lúc nào cũng hiển thị trên các trang trạng thái. Khi Tokyo POP của CDN của bạn ngừng hoạt động nhưng trạng thái toàn cầu của chúng hiển thị màu xanh lục, việc giám sát của bạn từ Virginia sẽ không phát hiện được.
Việc phát hiện mất điện trong khu vực yêu cầu giám sát từ vị trí thực sự của người dùng — không chỉ vị trí cơ sở hạ tầng của bạn.
Bây giờ là 3 giờ sáng. Kỹ sư trực của bạn nhận được thông báo về sự thành công của khách hàng: "Ba khách hàng doanh nghiệp ở Singapore cho biết họ không thể truy cập ứng dụng. Đã bắt đầu khoảng hai giờ trước."
Bạn kiểm tra bảng điều khiển giám sát của mình - mọi thứ đều có màu xanh lá cây. Trang trạng thái của Cloudflare — đang hoạt động. AWS — không có sự cố nào. APM của bạn - những biểu đồ nhỏ vui vẻ. Vì vậy, bạn yêu cầu khách hàng thử lại, xóa bộ nhớ đệm, kiểm tra mạng của họ.
Nhưng nó cứ xảy ra. Nhiều vé hơn từ cùng một khu vực. Cuối cùng, ai đó chạy traceroute từ VPS Singapore và phát hiện ra: lưu lượng truy cập đang chạm tới biên Cloudflare và trả về 502 giây. CDN sự cố ngừng hoạt động trong khu vực ảnh hưởng đến một PoP — và không có gì trong ngăn xếp giám sát của bạn đang kiểm tra từ khu vực đó.
Hai giờ ngừng hoạt động. Đối với một địa lý cụ thể. Không có cảnh báo. Đó chính là điểm mù mà trang này hướng tới.
Cho dù đó là sự cố ngừng hoạt động của Cloudflare, lỗi Fastly edge hay sự xuống cấp của khu vực Akamai — việc phát hiện những vấn đề này đòi hỏi phải có sự giám sát từ các khu vực bị ảnh hưởng. Đó là cách bạn nắm bắt được vấn đề trước khi chúng trở thành khiếu nại của khách hàng.
Internet không phải là một mạng duy nhất. Yêu cầu từ Sydney đi qua cơ sở hạ tầng hoàn toàn khác với yêu cầu từ Frankfurt. Khi bất kỳ phần nào của đường dẫn khu vực đó bị lỗi thì chỉ người dùng trong khu vực đó bị ảnh hưởng.
CDN như Cloudflare, Fastly và Akamai vận hành hàng trăm Điểm hiện diện (PoP) trên toàn cầu. Khi một máy chủ biên hoặc PoP cụ thể gặp sự cố - lỗi phần cứng, cấu hình sai hoặc vấn đề về dung lượng - chỉ những người dùng được định tuyến đến biên đó mới bị ảnh hưởng. Trạng thái toàn cầu của CDN vẫn "hoạt động" vì 95% các cạnh đều ổn.
Ví dụ: Vào tháng 6 năm 2022, Cloudflare đã ngừng hoạt động 30 phút, ảnh hưởng đến 19 trung tâm dữ liệu do thay đổi cấu hình mạng. Người dùng ở những khu vực đó đã thấy lỗi; người dùng ở nơi khác không gặp phải điều gì bất thường.
DNS là bước đầu tiên trong mọi yêu cầu. Khi 1.1.1.1 của Cloudflare hoặc máy chủ DNS của CDN của bạn gặp sự cố ở một khu vực cụ thể — tuyến đường Anycast bị định cấu hình sai, máy chủ tên quá tải — người dùng trong khu vực đó không thể phân giải miền của bạn. Trình duyệt của họ chỉ hiển thị "DNS_PROBE_FINISHED_NXDOMAIN."
Ví dụ: Sự cố DNS khu vực có thể do tính năng lọc cấp ISP, sự cố trình phân giải cục bộ hoặc sự cố định tuyến Anycast chỉ ảnh hưởng đến một số khu vực địa lý nhất định gây ra.
Rò rỉ, chiếm quyền điều khiển và cấu hình sai tuyến BGP có thể chuyển hướng lưu lượng truy cập qua các đường dẫn dưới mức tối ưu hoặc tạo lỗ đen hoàn toàn. Khi một nhà cung cấp dịch vụ chính trong một khu vực gặp sự cố định tuyến, lưu lượng truy cập từ khu vực đó đến CDN hoặc điểm gốc của bạn có thể không thành công — mặc dù cả hai điểm cuối đều hoạt động hoàn hảo.
Ví dụ: Sự cố BGP thường xuyên ảnh hưởng đến hàng nghìn mạng. Một đường dẫn AS bị định cấu hình sai có thể khiến toàn bộ các quốc gia không thể truy cập trang web của bạn trong nhiều giờ trong khi vẫn hiển thị bình thường từ vị trí giám sát của bạn.
Các ISP chính ở các quốc gia cụ thể có thể đã làm giảm khả năng kết nối với CDN của bạn do tranh chấp ngang hàng, tắc nghẽn hoặc sự cố cơ sở hạ tầng. Người dùng trên Telstra ở Úc có thể gặp lỗi trong khi người dùng trên Optus ở cùng thành phố không gặp vấn đề gì — vì lưu lượng truy cập đi qua các đường dẫn khác nhau.
Ví dụ: Tranh chấp ngang hàng giữa ISP và nhà cung cấp đám mây trước đây đã gây ra tình trạng xuống cấp trong nhiều tuần, ảnh hưởng đến hàng triệu người dùng ở các thị trường cụ thể.
Điểm chung: Tất cả những lỗi này đều phạm vi địa lý. Nguồn gốc của bạn đã lên. Cấu hình CDN của bạn là chính xác. Nhưng ở đâu đó giữa biên của bạn và người dùng ở một khu vực cụ thể, đã xảy ra sự cố — và hoạt động giám sát kiểm tra từ một địa điểm ở Virginia của bạn không có cách nào để phát hiện ra điều đó.
Hầu hết việc giám sát thời gian hoạt động được thiết kế cho một vấn đề đơn giản hơn: "Máy chủ có phản hồi không?" Đối với các trang web được tăng tốc CDN phục vụ người dùng toàn cầu, đó không còn là câu hỏi phù hợp nữa.
Hầu hết các dịch vụ giám sát mặc định kiểm tra từ một số địa điểm ở Hoa Kỳ hoặc EU. Nếu PoP Singapore của Cloudflare không hoạt động, séc của bạn từ Oregon vẫn sẽ thành công — nó đạt đến một khía cạnh lành mạnh khác. Trong khi đó, người dùng APAC của bạn đang gặp lỗi 502.
Việc chạy kiểm tra từ AWS đến Cloudflare sử dụng kết nối đường trục đám mây — các đường dẫn được tối ưu hóa không thể hiện lưu lượng truy cập thực của người dùng. Kiểm tra tổng hợp của bạn từ AWS ap-southeast-1 có thể bỏ qua đường dẫn mạng chính xác đang bị lỗi đối với người dùng trên các ISP địa phương.
Các trang trạng thái CDN phản ánh chế độ xem nội bộ của chúng, thường được tổng hợp trên hàng trăm PoP. Một vấn đề khu vực ảnh hưởng đến 5% cơ sở hạ tầng của họ có thể không kích hoạt cập nhật trang trạng thái - nhưng 5% đó có thể bao gồm toàn bộ Đông Nam Á.
Kiểm tra HTTP cho bạn biết yêu cầu thành công hay thất bại, nhưng không cho biết nơi yêu cầu đó không thành công. Nếu không có dữ liệu phân tích theo dõi và độ trễ từ khu vực bị ảnh hưởng, bạn không thể xác định xem sự cố là do DNS, bước nhảy mạng cụ thể hay biên CDN của bạn.
Cloudflare có hơn 310 PoP. Nếu giám sát của bạn kiểm tra từ 3 vị trí, thì bạn đang xác minh ít hơn 1% các giới hạn mà người dùng của bạn có thể chạm tới. Đó không phải là phát hiện ngừng hoạt động - đó là hy vọng điều tốt nhất.
Mỗi phút Cloudflare ngừng hoạt động hoặc lỗi CDN khu vực mà không bị phát hiện, bạn sẽ mất đi người dùng, doanh thu và niềm tin vào những thị trường mà bạn thậm chí có thể không nhận ra mình đang phục vụ.
Sự cố ngừng hoạt động trong khu vực trong giờ làm việc ở múi giờ đó có thể làm mất hàng giờ giao dịch, đăng ký hoặc lệnh gọi API. Người dùng không gửi email "trang web của bạn không hoạt động đối với tôi" — họ chỉ rời đi. Sau này, bạn sẽ thấy các chỉ số khu vực sụt giảm mà không có nguyên nhân rõ ràng.
Khách hàng doanh nghiệp có SLA. Khi họ không thể truy cập vào nền tảng của bạn và bạn thậm chí còn không biết rằng có sự cố, đó là một cuộc trò chuyện tồi tệ. "Chúng tôi không phát hiện ra sự cố ngừng hoạt động" không phải là câu trả lời tạo dựng niềm tin — đặc biệt khi họ trả tiền cho độ tin cậy.
Googlebot thu thập dữ liệu từ nhiều vị trí trên toàn cầu. Nếu CDN của bạn trong một khu vực trả về lỗi hoặc phản hồi chậm, điều đó sẽ ảnh hưởng đến ngân sách thu thập dữ liệu, đánh giá Core Web Vitals và cuối cùng là thứ hạng. Bạn có thể thấy lưu lượng truy cập giảm ở các thị trường cụ thể mà không có nguyên nhân rõ ràng.
Thời gian trung bình để khôi phục (MTTR) bắt đầu khi bạn phát hiện sự cố. Nếu sự cố ngừng hoạt động của Cloudflare trong khu vực ảnh hưởng đến người dùng trong 2 giờ trước khi bạn nhận được thông tin về sự cố đó từ phiếu yêu cầu của khách hàng, thì đó là 2 giờ được thêm vào MTTR hiệu quả của bạn. Phát hiện chủ động là cách duy nhất để giảm thiểu tác động thời gian ngừng hoạt động thực tế.
Việc phát hiện mất điện trong khu vực yêu cầu giám sát từ vị trí của người dùng, với chẩn đoán chuyên sâu để xác định vị trí xảy ra lỗi.
Mỗi vị trí giám sát chạm vào các biên CDN khác nhau và đi qua các đường dẫn mạng khác nhau. Để phát hiện tình trạng ngừng hoạt động trong khu vực, bạn cần có các nút ở mọi khu vực nơi bạn có lưu lượng truy cập đáng kể — Châu Á-Thái Bình Dương, Châu Âu, Châu Mỹ, Trung Đông, Châu Phi. Không chỉ "quốc tế" — cụ thể là người dùng của bạn ở đâu.
Giám sát từ hơn 50 địa điểm bao gồm các đường dẫn CDN PoP và ISP chính.
Khi kiểm tra không thành công ở Singapore nhưng thành công ở mọi nơi khác, bạn cần biết: đó có phải là DNS không? Một bước nhảy mạng cụ thể? Cạnh CDN? Traceroute và MTR từ vị trí bị ảnh hưởng cung cấp bằng chứng bạn cần để chẩn đoán nguyên nhân cốt lõi và chuyển đến Cloudflare, ISP hoặc nhà cung cấp dịch vụ lưu trữ của bạn.
Dữ liệu chẩn đoán biến "sự cố xảy ra" thành nguyên nhân gốc rễ có thể xử lý được.
400ms từ Tokyo là bình thường hay đó là sự xuống cấp của biên Cloudflare? Dữ liệu lịch sử trên mỗi vị trí xây dựng các đường cơ sở cho phép bạn phát hiện lỗi chậm — độ trễ tăng lên không gây ra lỗi cứng nhưng làm giảm trải nghiệm người dùng. Bạn có thể nắm bắt được sự cố CDN khu vực trước khi nó ngừng hoạt động hoàn toàn.
Đường cơ sở nắm bắt được sự xuống cấp trước khi chúng ngừng hoạt động.
Hướng dẫn từng bước về cách triển khai giám sát nhằm phát hiện sự cố ngừng hoạt động của Cloudflare và lỗi CDN khu vực trước khi người dùng của bạn báo cáo chúng.
Kiểm tra số liệu phân tích của bạn để xác định người dùng của bạn đang ở đâu. Nếu 20% lưu lượng truy cập đến từ Châu Á-Thái Bình Dương, bạn cần có nhiều nút giám sát ở đó - Singapore, Tokyo, Sydney, Mumbai. Kết hợp phạm vi giám sát với phân bổ người dùng thực tế.
Thiết lập màn hình HTTP cho các URL chính đi qua Cloudflare hoặc CDN của bạn. Những thứ này sẽ chạm vào cạnh CDN chứ không phải trực tiếp vào nguồn gốc của bạn. Bao gồm miền ứng dụng, điểm cuối API và mọi trang công khai quan trọng của bạn.
Các khu vực khác nhau có độ trễ cơ bản khác nhau. Định cấu hình các ngưỡng hợp lý: có thể 500 mili giây từ Châu Âu là chấp nhận được, nhưng 500 mili giây từ Miền Đông Hoa Kỳ (khi nguồn gốc của bạn ở đó) cho thấy có vấn đề về biên CDN. Sử dụng dữ liệu lịch sử để thiết lập đường cơ sở thực tế.
Thiết lập cảnh báo sẽ kích hoạt khi các khu vực cụ thể bị lỗi — không chỉ khi tất cả các vị trí đều bị lỗi. Sự cố chỉ xảy ra ở Singapore vẫn là một sự cố ngừng hoạt động đáng để biết. Định tuyến các cảnh báo có mức độ ưu tiên cao tới Slack, PagerDuty hoặc hệ thống quản lý sự cố của bạn.
Khi cảnh báo kích hoạt, bạn cần nhanh chóng xác định: đây có phải là sự cố của Cloudflare không? Một vấn đề về đường dẫn mạng? DNS? Kích hoạt theo dõi theo yêu cầu và MTR từ các vị trí giám sát để bạn có thể thu thập dữ liệu chẩn đoán ngay lập tức.
Ghi lại quy trình: Cách xác minh sự cố ngừng hoạt động khu vực của Cloudflare. Nơi kiểm tra API trạng thái của Cloudflare. Làm thế nào để mở một vé với bằng chứng. Bạn có thể áp dụng những biện pháp giảm thiểu nào (chuyển đổi dự phòng, bỏ qua bộ đệm, v.v.). Chuẩn bị sẵn sàng điều này sẽ làm giảm đáng kể MTTR.
Đặt lời nhắc lịch hàng tuần để xem lại độ trễ và thời gian hoạt động ở mỗi khu vực. Tìm kiếm các mô hình: APAC có luôn chậm hơn không? Có những đốm sáng thường xuyên ở một vị trí cụ thể không? Đánh giá chủ động phát hiện sự xuống cấp chậm trước khi chúng tác động đáng kể đến người dùng.
Đối với các dịch vụ không thể chấp nhận được tình trạng ngừng hoạt động trong khu vực, hãy xem xét chiến lược đa CDN trong đó DNS có thể chuyển đổi dự phòng giữa các nhà cung cấp. Điều này đòi hỏi phải giám sát từng CDN một cách độc lập và có tính năng tự động hóa có thể chuyển đổi lưu lượng truy cập. Đó là sự phức tạp, nhưng đó là khả năng phục hồi.
Latency Global được xây dựng để phát hiện chính xác loại vấn đề này — sự cố ngừng hoạt động của Cloudflare, lỗi CDN khu vực và các sự cố mạng mà việc giám sát một vị trí đã bỏ sót. Chúng tôi giám sát từ hơn 70 địa điểm thực trên 6 châu lục, bao gồm tất cả các khu vực CDN PoP chính.
Mọi kiểm tra đều bao gồm phân tích đầy đủ về thời gian - độ phân giải DNS, kết nối TCP, bắt tay TLS, TTFB và tổng thời gian phản hồi. Khi có sự cố xảy ra ở một khu vực cụ thể, bạn có thể chạy traceroute và MTR từ vị trí đó để xác định chính xác vị trí xảy ra sự cố trong đường dẫn mạng. Giá cả rất đơn giản: $5/tháng cho 5 màn hình, bao gồm tất cả các vị trí.
Việc phát hiện mất điện trong khu vực yêu cầu cơ sở hạ tầng ở nhiều địa điểm — đó là lý do tại sao hầu hết các công cụ giám sát không cung cấp tính năng này hoặc tính phí doanh nghiệp. Chúng tôi tập trung vào những gì quan trọng: phạm vi bao phủ và độ sâu chẩn đoán.
Sự cố ngừng hoạt động CDN khu vực xảy ra khi các máy chủ biên cụ thể hoặc Điểm hiện diện (PoP) trong mạng CDN bị lỗi hoặc xuống cấp, trong khi các biên khác vẫn hoạt động. Ví dụ: Cloudflare có thể gặp sự cố với PoP Singapore của họ trong khi các biên giới ở Hoa Kỳ và Châu Âu của họ hoạt động tốt. Người dùng định tuyến qua cạnh bị ảnh hưởng gặp lỗi hoặc hiệu suất chậm; người dùng ở nơi khác không nhận thấy bất cứ điều gì. Những sự cố ngừng hoạt động này là vô hình đối với việc giám sát mà chỉ kiểm tra từ các khu vực không bị ảnh hưởng.
Các trang trạng thái CDN thường hiển thị trạng thái toàn cầu tổng hợp, không phải trạng thái trên mỗi PoP. Khi 5% cạnh bị ảnh hưởng, trạng thái tổng thể có thể vẫn là "Đang hoạt động" vì 95% cơ sở hạ tầng đang hoạt động. Các trang trạng thái cũng có độ trễ cập nhật — cần có thời gian để phát hiện, xác minh và đăng sự cố. Ngoài ra, một số vấn đề chưa đáp ứng được ngưỡng tiết lộ công khai nhưng vẫn ảnh hưởng đến người dùng của bạn. Giám sát độc lập từ nhiều địa điểm là cách duy nhất để có được thông tin cơ bản về tính khả dụng của khu vực.
Tối thiểu, bạn cần các địa điểm giám sát ở mọi khu vực chính nơi bạn có người dùng: tối thiểu là Bắc Mỹ, Châu Âu và Châu Á-Thái Bình Dương. Để có phạm vi phủ sóng tốt hơn, hơn 50 địa điểm được phân bổ trên toàn cầu sẽ nắm bắt được hầu hết các vấn đề trong khu vực. Điều quan trọng là làm cho phạm vi giám sát phù hợp với khu vực địa lý của người dùng — nếu 30% người dùng của bạn ở APAC thì bạn cần có nhiều nút ở đó ( Singapore, Tokyo, Sydney, Mumbai). Đây không phải là việc kết hợp mọi CDN PoP mà còn bao gồm các nhóm khu vực chính.
Đầu tiên, thu thập bằng chứng chẩn đoán: traceroute và MTR từ vị trí bị ảnh hưởng, mã phản hồi HTTP và dữ liệu thời gian cũng như dấu thời gian. Kiểm tra trang trạng thái của Cloudflare và Twitter để biết bất kỳ xác nhận nào. Nếu đó rõ ràng là sự cố của Cloudflare, hãy mở phiếu hỗ trợ kèm theo bằng chứng của bạn. Để giảm thiểu ngay lập tức, hãy cân nhắc: tạm thời bỏ qua Cloudflare cho khu vực bị ảnh hưởng (nếu nguồn gốc của bạn có thể xử lý được), bật CDN dự phòng nếu bạn có khả năng đa CDN hoặc cập nhật trang trạng thái của bạn để xác nhận sự cố trong khi Cloudflare giải quyết. Ghi lại mọi thứ để xem xét sau sự cố.
Có, với thiết bị giám sát thích hợp. Thời gian kiểm tra HTTP đầy đủ hiển thị: thời gian phân giải DNS (nếu DNS bị lỗi hoặc chậm, bạn biết đó là sự cố DNS), thời gian kết nối TCP (sự cố đường dẫn mạng), thời gian bắt tay TLS (vấn đề về chứng chỉ hoặc mật mã) và TTFB/thời gian phản hồi (vấn đề xử lý nguồn gốc hoặc biên). Traceroute hiển thị đường dẫn mạng và nơi các gói bị mất hoặc bị trì hoãn. Bằng cách so sánh dữ liệu này từ khu vực bị ảnh hưởng với khu vực khỏe mạnh, bạn có thể xác định chính xác vị trí xảy ra lỗi trong chuỗi yêu cầu.
Với khoảng thời gian kiểm tra 1 phút, bạn có thể phát hiện sự cố ngừng hoạt động trong vòng 1-2 phút kể từ khi bắt đầu. Hầu hết các dịch vụ giám sát đều xác nhận ngừng hoạt động sau 2-3 lần thất bại liên tiếp để tránh cảnh báo về các lỗi tạm thời, do đó thời gian phát hiện thực tế là 2-5 phút. Hãy so sánh điều này với những lần ngừng hoạt động do khách hàng báo cáo, có thể mất hàng giờ để thông qua phiếu hỗ trợ. Sự khác biệt về MTTR là đáng kể — 5 phút so với 2 giờ có nghĩa là tác động đến người dùng rất khác nhau.
Tuyệt đối. Nhanh chóng, Akamai, AWS CloudFront, Google Cloud CDN, Azure CDN và bất kỳ CDN nào khác đều có thể gặp phải tình trạng ngừng hoạt động trong khu vực. Các nguyên tắc tương tự cũng được áp dụng: CDN có cơ sở hạ tầng phân tán và bất kỳ hệ thống phân tán nào cũng có thể gặp lỗi một phần. Phương pháp phát hiện giống nhau — giám sát từ nhiều vị trí trên toàn cầu để phát hiện các sự cố ảnh hưởng đến các cạnh hoặc khu vực cụ thể, bất kể bạn sử dụng CDN nào.
Hãy ngừng dựa vào các trang trạng thái CDN và phiếu khách hàng để tìm hiểu về tình trạng ngừng hoạt động trong khu vực. Thêm điểm cuối của bạn, chọn vị trí giám sát và biết trong vòng vài phút khi Cloudflare, Fastly hoặc bất kỳ phần nào trong ngăn xếp của bạn bị lỗi ở bất kỳ khu vực nào.
$5/tháng • Hơn 70 địa điểm (+40 địa điểm sớm hơn) • Không có hợp đồng • Hủy bất cứ lúc nào