Giám sát lỗi 5xx cho website: Theo dõi error rate trước khi người dùng báo lỗi

Giám sát lỗi 5xx cho website giúp phát hiện khi server hoặc application trả lỗi như 500, 502, 503 hoặc 504 trước khi vấn đề trở thành downtime diện rộng. Đây là lớp monitoring cần thiết cho website có traffic, API, checkout, form hoặc nhiều dependency.

Tóm tắt: Không nên chỉ alert khi website “down hoàn toàn”. Error-rate monitoring cần theo dõi tỷ lệ 5xx theo thời gian, endpoint bị ảnh hưởng, latency, resource và deployment gần nhất để phát hiện degradation sớm.

Lỗi 5xx là gì?

Nhóm HTTP 5xx cho biết server hoặc hệ thống phía sau không thể hoàn tất request như kỳ vọng. Một vài mã thường gặp:

• 500: lỗi application/server chung;
• 502: gateway nhận response không hợp lệ từ upstream;
• 503: service tạm không khả dụng;
• 504: upstream timeout.

Mã cụ thể giúp triage, nhưng điều quan trọng hơn là phạm vi, tỷ lệ và xu hướng lỗi.

Vì sao uptime monitor chưa đủ?

Một website có thể vẫn trả 200 ở homepage nhưng một số route quan trọng đang 500. Uptime check đơn giản dễ bỏ sót lỗi chỉ xảy ra ở checkout, admin, API hoặc một nhóm request. Vì vậy Uptime Monitoring nên được bổ sung bằng error-rate monitoring.

Cần theo dõi 5xx theo tỷ lệ, không chỉ số lượng tuyệt đối

10 lỗi trong 1 triệu request khác hoàn toàn 10 lỗi trong 20 request. Monitoring nên theo dõi error rate theo cửa sổ thời gian, endpoint và traffic để tránh alert sai.

Những dữ liệu nên có khi alert 5xx

• status code;
• endpoint/route;
• tỷ lệ lỗi;
• request volume;
• latency;
• timestamp;
• deployment/change gần nhất;
• upstream dependency;
• resource signal như CPU/memory nếu có;
• correlation/request ID nếu hệ thống hỗ trợ.

5xx thường liên quan những nguyên nhân nào?

• bug sau deploy;
• PHP fatal error;
• database timeout hoặc connection issue;
• upstream API lỗi;
• resource saturation;
• cache/proxy misconfiguration;
• maintenance hoặc autoscaling chậm;
• DNS/TLS giữa các service;
• plugin/theme conflict.

Không nên suy luận root cause chỉ từ mã 5xx. Alert là điểm bắt đầu triage, không phải kết luận.

Cách đặt severity

• P1: error rate cao trên route business-critical hoặc 5xx diện rộng;
• P2: lỗi tăng rõ trên một nhóm endpoint nhưng còn workaround;
• P3: spike ngắn, một route ít quan trọng hoặc lỗi đã tự phục hồi.

Severity nên liên kết với SLA vận hành website để tránh mỗi tool dùng một ngôn ngữ khác nhau.

Runbook khi 5xx tăng

1. xác nhận phạm vi và endpoint;
2. so với change/deploy gần nhất;
3. kiểm tra log ứng dụng và web server;
4. kiểm tra database/upstream API;
5. kiểm tra resource và saturation;
6. rollback change nếu có bằng chứng phù hợp;
7. smoke test route critical;
8. theo dõi error rate sau recovery.

5xx và API Monitoring

Nếu lỗi đến từ upstream hoặc integration, API Monitoring giúp phân biệt application lỗi với dependency ngoài chậm hoặc timeout.

5xx và transaction monitoring

Một spike 5xx có ý nghĩa khác nhau tùy route. Nếu 5xx xảy ra ở checkout hoặc form, cần kết hợp với monitoring hành trình tạo lead và checkout để đo business impact thực tế.

Checklist triển khai error-rate monitoring

• thu thập status code theo route;
• theo dõi request volume;
• tính error rate theo cửa sổ thời gian;
• phân tách endpoint critical;
• gắn deployment marker nếu có;
• correlate với latency/resource;
• đặt severity;
• gắn runbook;
• test alert;
• review threshold định kỳ.

FAQ

Một lỗi 500 có cần P1 không?

Không. P1 phải dựa vào impact, tỷ lệ lỗi và route bị ảnh hưởng. Alert mỗi lỗi đơn lẻ sẽ tạo noise.

502 và 504 có luôn do hosting không?

Không. Có thể do reverse proxy, upstream application, API ngoài, timeout hoặc resource. Cần triage theo dependency chain.

Có nên theo dõi 4xx cùng 5xx?

Có thể, nhưng search task khác. 4xx thường liên quan request/client/routing, còn bài này tập trung server-side failure và error rate 5xx.

Kết luận

Giám sát 5xx giúp phát hiện degradation trước khi toàn website down. Khi theo dõi error rate, route, latency, change và dependency cùng nhau, đội vận hành có thể khoanh vùng nhanh hơn và phản ứng theo mức ảnh hưởng thực tế.

Trong Website Monitoring, error-rate monitoring là lớp nối giữa uptime, application health và incident response.

Từ 5xx Monitoring sang Application Observability

5xx là symptom ở lớp HTTP; để tìm exception, release regression và request context phía sau symptom đó, xem Application Error Monitoring. Khi cần query event theo request/release một cách nhất quán, dùng Structured Logging; toàn bộ lớp metrics, logs, traces và SLO được tổ chức trong Website Observability.