Website của bạn tải trong 300 mili giây khi kiểm tra trên máy local. Bạn triển khai một mạng phân phối nội dung (CDN), một hệ thống máy chủ đặt rải rác tại nhiều vị trí để giữ bản sao nội dung gần người dùng hơn. Mọi thứ trông có vẻ nhanh. Bạn gọi đó là done.

Rồi một người dùng ở lục địa khác báo thời gian tải chậm. Bảng điều khiển giám sát của bạn không cho thấy vấn đề gì. Điều này dễ gây bối rối, nhưng lời giải thích rất đơn giản: kiểm tra từ một máy chỉ cho biết website của bạn hoạt động thế nào tại một vị trí. Nó không thể cho biết website hoạt động thế nào ở những nơi khác.

Hướng dẫn này chỉ cho bạn cách kiểm tra hiệu năng CDN từ dòng lệnh trên Linux. Bạn sẽ học cách đo tốc độ kết nối, kiểm tra xem CDN có đang phục vụ nội dung trong cache hay không, và kiểm tra hiệu năng từ nhiều khu vực. Mọi công cụ được dùng ở đây đều chạy được trên hệ thống Linux tiêu chuẩn.

Đến cuối bài, bạn sẽ trả lời được những câu hỏi sau:

  • DNS phân giải tên miền của bạn nhanh đến mức nào?
  • Mất bao lâu để thiết lập kết nối?
  • TLS handshake mất bao lâu?
  • Byte đầu tiên của nội dung đến nhanh thế nào?
  • CDN có thực sự phục vụ yêu cầu từ cache không?
  • Hiệu năng có khác nhau theo khu vực không?

Vì sao dòng lệnh phù hợp cho việc này

Các công cụ dựa trên trình duyệt chỉ cho bạn tổng thời gian tải. Chúng gộp chung độ trễ mạng, thời gian thực thi JavaScript và thời gian render, nên rất khó tách xem thời gian thực sự rơi vào đâu.

Công cụ dòng lệnh curl giải quyết vấn đề này. Nó đo từng giai đoạn của một yêu cầu một cách riêng biệt và bỏ qua hoàn toàn việc render của trình duyệt, vì vậy các con số chỉ phản ánh phản hồi của mạng và máy chủ.

Đây là lệnh cơ bản để đo một yêu cầu:

curl -sS -o /dev/null -w \
'DNS: %{time_namelookup}s
Connect: %{time_connect}s
TLS: %{time_appconnect}s
TTFB: %{time_starttransfer}s
Total: %{time_total}s
IP: %{remote_ip}
' \
https://example.com/

Lệnh này dùng curl để đo và hiển thị chỉ số thời gian chi tiết cho một kết nối HTTPS tới example.com, mà không tải nội dung trang web thực tế.

Đầu ra mong đợi:

DNS: 0.049033s
Connect: 0.078883s
TLS: 0.114448s
TTFB: 0.150471s
Total: 0.150763s
IP: 104.20.23.154

Lệnh này loại bỏ phần thân phản hồi (-o /dev/null) và chỉ in dữ liệu thời gian. Hãy chạy nó với website của bạn để có phép đo thực tế đầu tiên.

Các chỉ số được hiển thị:

  • DNS (time_namelookup) – thời gian phân giải tên miền thành địa chỉ IP
  • Connect (time_connect) – thời gian thiết lập kết nối TCP connection
  • TLS (time_appconnect) – thời gian bắt tay TLS/SSL
  • TTFB (time_starttransfer) – thời gian cho đến khi byte đầu tiên tới nơi, tức phản hồi của máy chủ bắt đầu đến
  • Total (time_total) – tổng thời gian hoàn tất yêu cầu/phản hồi
  • IP (remote_ip) – địa chỉ IP mà kết nối đã dùng

Cách kiểm tra này hữu ích cho:

  • Giám sát hiệu năng – kiểm tra máy chủ phản hồi nhanh thế nào
  • Gỡ lỗi – xác định phần nào của kết nối bị chậm: DNS, mạng, TLS hay xử lý phía máy chủ
  • Kiểm tra sức khỏe – xác minh máy chủ truy cập được và phản hồi bình thường mà không cần tải nội dung lớn

Biến một yêu cầu thành hồ sơ hiệu năng

Một con số đơn lẻ như “1.2 giây” không nói lên được nhiều điều. Một yêu cầu thực sự diễn ra theo từng giai đoạn, và mỗi giai đoạn có thể đo riêng.

Trình tự như sau:

DNS lookup
↓
TCP connection
↓
TLS handshake
↓
Request sent
↓
First byte received
↓
Transfer completed

Mỗi biến thời gian của curl tương ứng với một giai đoạn nói trên:

  • time_namelookup: thời gian phân giải tên miền thành địa chỉ IP
  • time_connect: thời gian mở kết nối TCP connection tới địa chỉ IP đó
  • time_appconnect: thời gian hoàn tất TLS handshake, quá trình thiết lập kết nối mã hóa
  • time_starttransfer: thời gian cho đến khi byte đầu tiên của phản hồi tới nơi, còn gọi là time to first byte (TTFB)
  • time_total: thời gian toàn bộ yêu cầu hoàn tất

Sự tách bạch này giúp bạn tìm ra nguồn gốc thực sự của sự chậm thay vì phải đoán:

  • Thời gian DNS cao là dấu hiệu vấn đề DNS.
  • Thời gian kết nối cao là dấu hiệu vấn đề mạng hoặc định tuyến.
  • TTFB cao trong khi thời gian kết nối bình thường cho thấy máy chủ hoặc CDN phản hồi chậm.
  • Khoảng cách lớn giữa TTFB và tổng thời gian cho thấy phản hồi lớn hoặc truyền tải chậm.

CDN có thực sự phục vụ yêu cầu?

Một phản hồi nhanh không phải lúc nào cũng có nghĩa CDN đang làm đúng việc. CDN có thể chuyển tiếp mọi yêu cầu tới máy chủ gốc thay vì phục vụ từ cache. Bạn có thể kiểm tra điều này qua các header phản hồi.

Chạy lệnh sau để xem header mà không tải phần thân:

curl -s -o /dev/null -D - https://example.com/ | grep -iE '(cache|age|served-by)'

Đầu ra mẫu:

age: 6687
cf-cache-status: HIT

Lệnh này gửi một yêu cầu GET bình thường, loại bỏ phần thân và chỉ in header. Tránh dùng curl -I khi kiểm tra kiểu này. Cờ đó gửi yêu cầu HEAD thay vì GET, và một số CDN xử lý HEAD khác với GET, trong khi người dùng thực tế gần như luôn gửi GET. Kiểm tra bằng HEAD có thể hiển thị trạng thái cache không khớp với những gì người dùng thực sự thấy.

Hãy tìm header trạng thái cache. Tên của header này tùy thuộc vào CDN bạn dùng:

  • Cloudflare dùng CF-Cache-Status, với các giá trị như HIT, MISS, EXPIRED, REVALIDATED, BYPASS hoặc DYNAMIC.
  • Fastly dùng X-Cache, với giá trị HIT hoặc MISS, cùng X-Cache-Hits cho biết đối tượng đó đã được phục vụ từ cache bao nhiêu lần. Fastly cũng đặt X-Served-By để ghi tên nút cache cụ thể, dù chỉ riêng header này không cho biết hit hay miss.
  • Amazon CloudFront dùng X-Cache, định dạng là Hit from cloudfront hoặc Miss from cloudfront.
  • Akamai và Azure CDN (classic) dùng các giá trị TCP_HIT và TCP_MISS cho X-Cache, nhưng cách họ phơi bày thông tin chẩn đoán này không giống nhau. Azure CDN (classic) thường trả về X-Cache trên các phản hồi thông thường. Còn X-Cache của Akamai về cơ bản là một header chẩn đoán và thường phải được yêu cầu một cách tường minh; trước đây người ta yêu cầu qua một header Pragma như Pragma: akamai-x-cache-on (có thể kết hợp với akamai-x-get-cache-key). Vì vậy, việc thiếu X-Cache trong một phản hồi Akamai thông thường không nên bị hiểu là cache miss. Akamai hiện khuyến nghị dùng cơ chế Enhanced Debug có xác thực cho mục đích này.

Header Age, khi hiện diện, cho biết nội dung đã được giữ trong cache bao nhiêu giây.

Phản hồi nhanh với trạng thái MISS nghĩa là CDN đã chuyển tiếp yêu cầu sang nguồn gốc. Phản hồi nhanh với trạng thái HIT nghĩa là CDN đang thực sự làm việc. Đây là hai việc hoàn toàn khác nhau, và chỉ một trong hai chứng tỏ CDN hoạt động như mong đợi.

Một lưu ý khi kiểm tra theo cách này:

curl không gửi những header mà trình duyệt gửi theo mặc định, chẳng hạn Accept-Encoding cho nén.

Một số CDN, trong đó có CloudFront, đưa phiên bản chuẩn hóa của Accept-Encoding vào cache key khi bật nén. Nếu thiếu header này, curl bị xem như đang yêu cầu nội dung không nén, và nội dung đó được lưu thành một bản cache riêng so với bản nén mà trình duyệt nhận được. Điều này có thể khiến yêu cầu curl đầu tiên của bạn bị miss dù trình duyệt luôn nhận hit, vì yêu cầu của bạn và yêu cầu khớp với các bản sao cache khác nhau.

Nếu kết quả từ curl của bạn báo miss nhưng người dùng thực tế vẫn thấy tải nhanh, hãy kiểm tra sự không khớp này trước khi kết luận rằng có vấn đề cache thực sự.

Ghi chú về Azure: Microsoft đang loại bỏ Azure CDN Standard from Microsoft (classic) để chuyển sang Azure Front Door. Kể từ tháng 8 năm 2025, Azure CDN from Microsoft (classic) không còn hỗ trợ tạo hồ sơ mới hoặc đăng ký tên miền mới, và dự kiến ngừng hoạt động hoàn toàn vào tháng 9 năm 2027. Các triển khai hiện có vẫn tiếp tục hoạt động cho đến thời điểm ngừng, vì vậy hành vi X-Cache nói trên vẫn còn phù hợp khi bạn kiểm tra một endpoint CDN classic. Với triển khai mới, hãy dùng Azure Front Door Standard hoặc Premium; Front Door cũng trả về X-Cache, bao gồm các giá trị như TCP_HIT, TCP_REMOTE_HIT và TCP_MISS, nhưng có thêm các header và quy ước chẩn đoán mới hơn.

Một phép đo là không đủ

Một yêu cầu đơn lẻ có thể gây hiểu lầm. Yêu cầu đầu tiên nhắm tới một URL có thể rơi vào cache lạnh, trong khi những yêu cầu sau lại trúng cache ấm. Điều kiện mạng cũng thay đổi từng khoảnh khắc.

Hãy chạy lặp lại cùng một yêu cầu nhiều lần:

for i in {1..10}; do
curl -sS -o /dev/null -w \
'%{http_code} %{time_starttransfer}s %{time_total}s\n' \
https://example.com/
done

Đầu ra mẫu:

200 0.146150s 0.146868s
200 0.231786s 0.232220s
200 0.077217s 0.077753s
200 0.240986s 0.241477s
200 0.682164s 0.682240s
200 0.132748s 0.133461s
200 0.410818s 0.933873s
200 0.087598s 0.088383s
200 0.256964s 0.745285s
200 0.679765s 0.882171s

Hãy nhìn vào xu hướng của cả mười kết quả, không chỉ một dòng. Cache lạnh thường thể hiện ở yêu cầu đầu tiên chậm hơn, sau đó các yêu cầu tiếp theo nhanh dần.

Các con số nhất quán cho thấy cache ổn định. Biến động lớn là dấu hiệu đáng điều tra. Giá trị trung vị thường hữu ích hơn giá trị trung bình, vì một ngoại lệ chậm có thể làm lệch số trung bình mà không phản ánh đúng hiệu năng điển hình.

Hiểu CDN cache thực sự đang làm gì

Công việc chính của CDN là lưu cache, không chỉ đơn thuần là đặt máy chủ gần người dùng về mặt địa lý. Vài thuật ngữ dưới đây giúp bạn theo dõi phần còn lại dễ hơn.

  • Cache hit: CDN tìm thấy bản sao nội dung còn hợp lệ trong kho lưu trữ và phục vụ trực tiếp.
  • Cache miss: CDN không tìm thấy bản sao hợp lệ và phải lấy nội dung từ máy chủ gốc.
  • TTL (time to live): khoảng thời gian CDN giữ một bản cache trước khi coi nó đã hết hạn.
  • Cache key: tập hợp các giá trị CDN dùng để quyết định hai yêu cầu có được trả về cùng một nội dung cache hay không.
  • Origin request: yêu cầu CDN gửi tới máy chủ thật của bạn, chỉ xảy ra khi cache miss.
  • Edge location: máy chủ CDN đặt gần người dùng, nơi lưu trữ và phục vụ nội dung cache.

Cache key quan trọng hơn nhiều người vẫn nghĩ. Nếu CDN của bạn đưa vào cache key những thành phần không cần thiết, ví dụ header yêu cầu thừa, cookie hoặc tham số truy vấn, nó sẽ tạo ra nhiều biến thể cache hơn.

Càng nhiều biến thể cache đồng nghĩa với càng nhiều cache miss, vì số yêu cầu khớp với một bản cache có sẵn sẽ giảm đi. Giữ cache key đơn giản thường cải thiện tỷ lệ hit, tức tỷ lệ phần trăm yêu cầu được phục vụ từ cache thay vì phải về origin.

Một chuyển hướng dành riêng cho Linux: IPv4 so với IPv6

Hầu hết hệ thống hiện nay hỗ trợ cả IPv4 lẫn IPv6. Hiệu năng giữa hai giao thức có thể khác nhau, tùy thuộc vào đường mạng và cách CDN định tuyến.

Bạn có thể dùng cờ -4 và -6 của curl để ép kiểm tra riêng từng giao thức:

# curl -4 -sS -o /dev/null -w '%{time_total}\n' https://example.com/
curl -4 -sS -o /dev/null -w '%{time_total}\n' https://example.com/
# curl -6 -sS -o /dev/null -w '%{time_total}\n' https://example.com/
curl -6 -sS -o /dev/null -w '%{time_total}\n' https://example.com/

Nếu một phiên bản chậm hơn hẳn, sự khác biệt có thể chỉ ra vấn đề định tuyến riêng cho giao thức đó. Điều này đáng kiểm tra, vì một số mạng xử lý IPv6 kém hiệu quả hơn IPv4, hoặc ngược lại.

Kiểm tra hiệu năng HTTP/3

Hầu hết CDN lớn hiện hỗ trợ HTTP/3, một phiên bản giao thức chạy trên QUIC thay vì TCP. QUIC là giao thức truyền tải xây dựng trên UDP. Nó giúp loại bỏ vấn đề head-of-line blocking, khi một gói tin bị mất làm trì hoãn mọi luồng trên cùng một kết nối. Nhờ đó HTTP/3 có thể nhanh hơn đáng kể trên những mạng có tỷ lệ mất gói cao, chẳng hạn kết nối di động.

Bản dựng curl của bạn cần có hỗ trợ QUIC để kiểm tra HTTP/3, và điều này thường không xuất hiện trong gói cài đặt Linux mặc định. Kiểm tra bản dựng của bạn:

# curl --version | grep -i http3
curl --version | grep -i http3

Nếu thiếu hỗ trợ HTTP/3, bạn vẫn có thể xác nhận máy chủ có cung cấp giao thức này hay không bằng cách kiểm tra header phản hồi Alt-Svc:

# curl -s -o /dev/null -D - https://example.com/ | grep -i alt-svc
curl -s -o /dev/null -D - https://example.com/ | grep -i alt-svc

Nếu bản dựng curl của bạn hỗ trợ HTTP/3, hãy so sánh trực tiếp với HTTP/2:

# FORMAT='Protocol: %{http_version}  Total: %{time_total}s\n'
curl -s -o /dev/null --http2 -w '%{http_version} %{time_total}\n' https://example.com/
# curl -s -o /dev/null --http2 -w "$FORMAT" https://example.com/ curl -s -o /dev/null --http3 -w "$FORMAT" https://example.com/
curl -s -o /dev/null --http3 -w '%{http_version} %{time_total}\n' https://example.com/

Kiểm tra giá trị %{http_version} trong đầu ra để biết giao thức nào thực sự được dùng.

Khi bạn dùng --http3, curl thử kết nối QUIC trước, sau đó tự động fallback sang HTTP/2 nếu QUIC thất bại hoặc quá chậm. Fallback này diễn ra âm thầm, nên yêu cầu vẫn thành công ngay cả khi HTTP/3 không hoạt động. Trường phiên bản trong đầu ra là cách duy nhất đáng tin cậy để biết giao thức nào đã được sử dụng.

DNS là một phần của đường đi, không chỉ là tra cứu

Phân giải DNS không tách rời khỏi hiệu năng CDN. Nó nằm ngay trên đường đi. Nhiều CDN dùng DNS để định tuyến người dùng tới một edge location gần đó, nên địa chỉ IP nhận được từ một truy vấn DNS có thể thay đổi tùy theo vị trí của bạn.

Kiểm tra phân giải hiện tại bằng dig:

# dig example.com
dig example.com

Nếu muốn đầu ra ngắn gọn chỉ có địa chỉ IP đã phân giải:

# dig +short example.com
dig +short example.com

Hãy tách ba thứ trong đầu: bước phân giải DNS, địa chỉ IP mà nó trả về, và edge location CDN thực sự xử lý yêu cầu HTTP của bạn.

Lệnh dig chỉ cho bạn hai thứ đầu tiên. Nó không xác nhận cơ sở vật lý nào đã phục vụ yêu cầu. Các header phản hồi, như đã đề cập ở phần trước, là nguồn thông tin tốt hơn cho việc đó.

Nhận ra giới hạn: một máy, một điểm quan sát

Mọi phép đo cho tới lúc này đều xuất phát từ một máy, tại một vị trí. Đây là giới hạn trung tâm của toàn bộ phương pháp nêu trên. Các con số bạn thu được là chính xác, nhưng chúng chỉ mô tả hiệu năng từ đúng nơi bạn đang đứng.

Điều này quan trọng vì CDN định tuyến người dùng tới các edge location khác nhau tùy theo nguồn gốc yêu cầu. Một CDN hoạt động tốt với bạn vẫn có thể định tuyến người dùng ở khu vực khác tới một edge location chậm hoặc bị cấu hình sai, và bạn sẽ không bao giờ thấy điều đó từ máy của mình.

Bước tiếp theo là chạy cùng các phép kiểm tra từ nhiều khu vực rồi so sánh kết quả. Bạn không đi tìm con số nhanh nhất duy nhất, mà đang tìm các mẫu hình:

  • Có khu vực nào chậm hơn những khu vực khác một cách nhất quán không?
  • TTFB có biến động lớn giữa các khu vực không?
  • Các khu vực khác nhau có nhận trạng thái cache khác nhau cho cùng một nội dung không?
  • Có khu vực nào đang đi tới một edge location khác với dự kiến không?
  • Hiệu năng IPv4 hay IPv6 có khác biệt theo khu vực không?

Gửi yêu cầu từ nhiều khu vực

Để kiểm tra từ nhiều khu vực, bạn cần những yêu cầu thực sự xuất phát từ các khu vực đó. Có vài cách thực tế để làm việc này.

Cách thứ nhất là dùng hạ tầng bạn đã kiểm soát ở những nơi khác, ví dụ máy chủ hiện có hoặc văn phòng chi nhánh. Cách này cho bạn toàn quyền kiểm soát môi trường kiểm tra, nhưng chỉ khả thi nếu bạn đã có sẵn thứ gì đó đang chạy tại các khu vực mình quan tâm.

Cách thứ hai là tạo máy ảo đám mây ngắn hạn ở các khu vực mục tiêu, dùng nhà cung cấp như DigitalOcean hoặc Hetzner. Cách này phù hợp cho những đợt kiểm tra không thường xuyên hoặc chỉ một lần, dù bạn sẽ mất thời gian thiết lập và dỡ bỏ mỗi khi muốn chạy.

Cách thứ ba, hữu ích cho những nhóm không muốn cung cấp và duy trì máy chủ kiểm tra ở mọi khu vực, là định tuyến lưu lượng kiểm tra qua các endpoint proxy phân tán theo địa lý. Trong một số thiết lập, các proxy xoay vòng chuyên dụng có thể cung cấp một nhóm endpoint khu vực được kiểm soát cho những lần chạy lặp lại, giúp tránh việc phải quản lý hạ tầng riêng tại từng vị trí.

Mỗi lựa chọn đều là một sự trade-off giữa mức kiểm soát, công sức thiết lập và tần suất bạn dự định chạy kiểm tra. Hãy chọn phương án khớp với nhu cầu về tần suất và số khu vực cần bao phủ.

Xây dựng một bài kiểm tra lặp lại được

Khi đã có thể gửi yêu cầu từ nhiều khu vực, hãy gộp mọi thứ đã trình bày vào một script. Với mỗi yêu cầu, ghi lại:

  • timestamp
  • khu vực
  • mã trạng thái HTTP
  • địa chỉ IP từ xa
  • thời gian DNS
  • thời gian kết nối
  • thời gian TLS
  • TTFB
  • tổng thời gian

Định dạng đầu ra gợi ý:

timestamp,region,status,remote_ip,dns,connect,tls,ttfb,total   # timestamp,region,status,remote_ip,dns,connect,tls,ttfb,total
2026-09-05T09:00:00Z,eu-west,200,104.16.1.1,0.012,0.034,0.089,0.145,0.210   # 2026-09-05T09:00:00Z,eu-west,200,104.16.1.1,0.012,0.034,0.089,0.145,0.210
2026-09-05T09:00:00Z,ap-southeast,200,104.16.2.5,0.028,0.061,0.140,0.310,0.402   # 2026-09-05T09:00:00Z,ap-southeast,200,104.16.2.5,0.028,0.061,0.140,0.310,0.402

Bạn có thể chuyển đầu ra này vào tệp CSV, một cơ sở dữ liệu nhẹ như SQLite, hoặc một hệ thống giám sát như Prometheus. Chạy script theo lịch bằng cron sẽ biến một phép kiểm tra đơn lẻ thành bản ghi hiệu năng liên tục theo thời gian.

Diễn giải kết quả

Khi đã có dữ liệu từ nhiều yêu cầu và nhiều khu vực, hãy dùng các mẫu hình sau để định hướng việc điều tra:

  • Thời gian DNS cao: kiểm tra cấu hình DNS và hiệu năng của resolver bạn đang dùng.
  • Thời gian kết nối cao, thời gian DNS bình thường: kiểm tra khoảng cách mạng và định tuyến tới khu vực đó.
  • TTFB cao, thời gian kết nối bình thường: kiểm tra khâu xử lý của CDN hoặc máy chủ gốc, cùng trạng thái cache.
  • TTFB thấp, tổng thời gian cao: kiểm tra kích thước phản hồi và tốc độ truyền tải.
  • Một khu vực chậm hơn các khu vực khác một cách nhất quán: kiểm tra định tuyến, điều hướng DNS và vùng phủ của CDN tại khu vực đó.
  • Biến động lớn giữa các lần chạy lặp lại: hãy dựa vào xu hướng của nhiều yêu cầu, không dựa vào một kết quả đơn lẻ.

Những mẫu hình này giúp biến các con số thô thành điểm khởi đầu để xử lý sự cố thực tế.

Điều curl sẽ không cho bạn biết

Kiểm tra từ dòng lệnh có một giới hạn cần nói rõ. curl đo hiệu năng ở tầng mạng và tầng HTTP. Nó không chạy JavaScript, không render trang, không tải hình ảnh theo đúng thứ tự trình duyệt vẫn làm, và không đo độ dịch chuyển bố cục.

Vì vậy, kiểm tra CLI không phải là sự thay thế trọn vẹn cho kiểm tra hiệu năng dựa trên trình duyệt. Nó bổ sung cho công cụ đó. Dùng curl để cô lập các vấn đề mạng và máy chủ. Dùng công cụ của trình duyệt hoặc dịch vụ giám sát tổng hợp để đo trải nghiệm đầy đủ của người dùng, bao gồm cả render lẫn hành vi phía client-side.

Kết luận: Đo những gì người dùng thực sự trải nghiệm

Một CDN không thành công chỉ vì nó đã được bật. Câu hỏi thực sự là liệu nó có phân phối nội dung của bạn nhanh chóng và nhất quán tới người dùng ở đúng nơi họ đang sống hay không.

Quy trình trong bài này đi theo một vòng lặp đơn giản: đo, kiểm tra, lặp lại, so sánh, chẩn đoán và đo tiếp. Bắt đầu bằng một yêu cầu đơn lẻ trên chính máy của bạn. Kiểm tra xem CDN có thực sự lưu cache hay không. Lặp lại phép đo để loại bỏ nhiễu.

Sau đó mở rộng phương pháp tương tự ra nhiều khu vực, bằng hạ tầng sẵn có, máy chủ đám mây tạm thời hoặc các endpoint proxy phân tán, tùy theo tần suất bạn cần kiểm tra và số khu vực cần bao phủ.

Công cụ dòng lệnh cho bạn toàn bộ quy trình này mà không cần phần mềm giám sát trả phí. Thứ duy nhất cần xây dựng là thói quen kiểm tra.