Giám sát thời gian phản hồi

Tại sao thời gian phản hồi xứng đáng có cảnh báo riêng

Cảnh báo uptime tiêu chuẩn dựa trên tín hiệu nhị phân: up hoặc down. Vùng xám ở giữa – up nhưng chậm – chính là nơi hầu hết các sự cố hiện đại thực sự diễn ra. Một truy vấn cơ sở dữ liệu cấu hình sai bắt đầu mất 4 giây thay vì 50ms. Lỗi rò rỉ bộ nhớ làm tăng garbage collection. API bên ngoài mà backend gọi bắt đầu chập chờn. Không thứ nào trong số này làm trang gãy hoàn toàn, nhưng khiến nó không thể sử dụng được – và đó là những tín hiệu sớm của sự cố lớn sẽ xảy ra sau một hoặc hai tiếng.

Giám sát thời gian phản hồi phát hiện ra sự chậm lại trước khi nó thành sự cố lớn. Bạn cấu hình ngưỡng cho từng monitor, và khi thời gian phản hồi vượt qua ngưỡng trong vài lần kiểm tra liên tiếp, bạn nhận được cảnh báo. Trước khi cảnh báo được gửi đi, bạn còn thời gian để điều tra, scale thêm, giới hạn những lời gọi gây sự cố hoặc revert lại lần deploy vừa thực hiện.

Cách hoạt động của ngưỡng trong DiagnoSEO Uptime Monitoring

Mỗi monitor có thể cấu hình với hai tham số: rt_threshold_ms và rt_threshold_breaches. Tham số đầu là thời gian phản hồi tính bằng mili giây bạn cho là chấp nhận được. Tham số thứ hai là số lần liên tiếp phải vượt quá ngưỡng để cảnh báo được gửi. Mặc định ngưỡng bị tắt, và số lần vượt quá ngưỡng là ba.

Thiết kế hai tham số giúp tránh báo động giả. Jitter mạng là chuyện thường. Garbage collection pauses cũng vậy. Một lần nhảy lên 1 giây khi bình thường chỉ 200ms không đáng để báo động lúc 3h sáng. Nhưng ba lần liên tục 1 giây thì khác – đó là sự chậm ổn định, không phải chỉ thoáng qua. Hãy đặt ngưỡng dựa trên hành vi bình thường bạn quan sát cộng một mức độ dự phòng hợp lý: nếu p95 thường là 400ms thì ngưỡng 1000ms. Nếu p95 là 50ms (API nội bộ) thì ngưỡng nên là 200ms.

Kết hợp tốt với gì

Cảnh báo thời gian phản hồi hoạt động tốt nhất khi kết hợp với các tín hiệu khác của monitor. Một cái nhìn toàn cảnh: ngưỡng thời gian phản hồi báo hiệu hệ thống đang xuống cấp; mã HTTP báo khi nào thực sự bị lỗi; cảnh báo SSL/domain – cho những sự cố theo giờ; cảnh báo thay đổi DNS – cho trôi cấu hình. Bốn tín hiệu này kết hợp trên cùng một monitor biến câu hỏi nhị phân “hoạt động không” thành observability thực thụ.

Dashboard cũng giúp bạn trong chuyện này. Mỗi monitor hiển thị sparkline các thời gian phản hồi gần nhất – một chỉ số trực quan nhanh về dấu hiệu xuống cấp. Màn hình chi tiết cho thấy trung bình 24h, 7d và 30d. Nếu bạn thấy trung bình đang tăng dần từng tuần – đó là dấu hiệu sớm đáng điều tra, trước khi vượt ngưỡng cảnh báo.

Ngưỡng thực tế cho từng loại trang

• Trang landing marketing: 1500ms là hợp lý. Thường tải nhiều hình và script tracker; tốc độ tuyệt đối ít quan trọng hơn sự ổn định.
• Trang sản phẩm/danh mục ecommerce: 800-1200ms. Ecommerce chậm giết chết chuyển đổi; ngưỡng chặt hơn sẽ phát hiện vấn đề sớm hơn.
• Dashboard ứng dụng: 500-800ms. Người dùng mong đợi sự linh hoạt. Dashboard chậm khiến sản phẩm có vẻ trục trặc.
• API public: 200-400ms cho endpoint đơn giản, cao hơn cho tính toán nặng. Hãy phân lớp chúng.
• Health check vi mô bên trong: 50-100ms. Phải phản hồi gần như tức thì; chậm là dấu hiệu của sự cố thật sự.

Dù chọn ngưỡng nào, đừng thiết lập rồi quên. Hãy đánh giá lại hàng quý dựa trên các xu hướng thực tế bạn thấy. Nếu liên tục nhận cảnh báo vượt ngưỡng nhưng không có vấn đề thực sự – ngưỡng quá chặt. Nếu gặp sự cố mà không thấy cảnh báo từ trước – ngưỡng quá rộng.

Định tuyến cảnh báo

Cảnh báo vượt ngưỡng được gửi qua các kênh như cảnh báo down/recovery: Email, Telegram, Slack, Discord, SMS. Cùng tôn trọng chế độ im lặng về đêm. Được ghi lại trên cùng một bảng alert. Khác biệt duy nhất là loại sự kiện ("threshold" thay vì "down") và nội dung thông báo – ghi rõ thời gian phản hồi hiện tại và ngưỡng cấu hình, giúp bạn thấy ngay mức độ vượt ngưỡng.

Cấu hình

Chỉnh sửa bất kỳ monitor nào. Trong form, đặt “Ngưỡng thời gian phản hồi (ms)” theo số bạn muốn. Tùy chọn chỉnh “số lần vượt liên tiếp” nếu mặc định là 3 không phù hợp dung sai của bạn. Lưu lại. Từ chu kỳ tới, mỗi lần kiểm tra sẽ so sánh thời gian phản hồi với ngưỡng và khi vượt quá liên tiếp số lần đã cấu hình bạn sẽ nhận thông báo.

Các câu hỏi thường gặp

• Chỉ số nào về thời gian phản hồi được ghi nhận?

  Time To First Byte (TTFB) — mili giây giữa lúc gửi request và nhận byte đầu tiên của phản hồi. Thêm tổng thời gian tải toàn bộ phản hồi. TTFB là chỉ số đơn hữu ích nhất để đánh giá sức khỏe máy chủ.

• Thời gian phản hồi “tốt” là bao nhiêu?

  Tùy vị trí và nội dung trang. Static trang dùng CDN: dưới 100ms là rất tốt, dưới 300ms là chấp nhận được. Ứng dụng động: dưới 500ms là ok, dưới 1000ms vẫn tạm ổn, trên 2000ms là chậm. So sánh với số liệu lịch sử của bạn thay vì các con số tuyệt đối.

• Tôi có thể nhận cảnh báo khi thời gian phản hồi vượt ngưỡng không?

  Có. Mỗi monitor có ngưỡng thời gian phản hồi tuỳ chọn. Nếu 3 lần kiểm tra liên tiếp vượt quá ngưỡng, bạn sẽ nhận cảnh báo "slow response". Yêu cầu 3 lần kiểm tra giúp tránh cảnh báo giả do mạng trục trặc thoáng qua.

• Thời gian phản hồi được đo ở đâu?

  Từ 13 điểm kiểm tra địa lý của chúng tôi (Châu Âu, Bắc Mỹ, Châu Á, Nam Mỹ, Châu Đại Dương). Nếu monitor là single-region thì lấy thời gian từ khu vực gần nhất. Nếu multi-region mỗi vùng đo riêng – rất hữu ích cho việc phát hiện vấn đề CDN theo vùng.

• Dashboard có hiển thị xu hướng thời gian phản hồi không?

  Có – trung bình lăn 30 ngày, max/min hằng ngày và các phân vị (p50, p95). Hữu ích cho lập kế hoạch dung lượng: nếu p95 từ 800ms tăng lên 1500ms trong tháng, máy chủ của bạn đang quá tải dù uptime % vẫn 100%.