Code xong chạy được là chưa đủ – phải biết khi nào nó "chết" nữa chứ 😅
Bạn đang triển khai ứng dụng trên Kubernetes, Docker hay môi trường production nào? Và bạn từng "toát mồ hôi" vì service chết mà không ai báo?
1. Tổng quan Healthcheck trong .NET
Khi xây dựng hệ thống phân tán, đặc biệt là các ứng dụng chạy trên container và orchestrator như Kubernetes, Healthchecks là thành phần không thể thiếu để đảm bảo dịch vụ luôn sẵn sàng, ổn định và dễ giám sát.
Mục đích của Healthcheck giúp phát hiện sớm sự cố và đảm bảo hệ thống vận hành ổn định. .NET cung cấp tính năng healthcheck, cho phép kiểm tra trạng thái API, database, external service và xuất kết quả qua các endpoint như /health, /healthz...
Tại sao Health Checks quan trọng?
Đảm bảo tính sẵn sàng: Chỉ định tuyến lưu lượng truy cập đến các phiên bản ứng dụng khỏe mạnh.
Giám sát: Cung cấp cái nhìn sâu sắc về tình trạng của ứng dụng và các dịch vụ mà nó phụ thuộc.
Tự phục hồi: Cho phép các công cụ điều phối tự động khởi động lại các phiên bản bị lỗi hoặc loại bỏ chúng khỏi nhóm dịch vụ.
Gỡ lỗi nhanh chóng: Giúp xác định và cô lập các vấn đề trong môi trường phân tán.
Các loại Health Checks chính:
Liveness Probe (Kiểm tra sự sống): Xác định xem ứng dụng có đang chạy hay không. Nếu một liveness probe thất bại, container thường sẽ được khởi động lại.
Readiness Probe (Kiểm tra sự sẵn sàng): Xác định xem ứng dụng có sẵn sàng chấp nhận lưu lượng truy cập hay không. Nếu một readiness probe thất bại, container sẽ bị loại bỏ khỏi các điểm cuối dịch vụ cho đến khi nó sẵn sàng trở lại.
2. Các công cụ Giám sát phổ biến
HealthChecks.UI
Mô tả: Dashboard trực quan cho healthcheck, tích hợp sâu với .NET HealthChecks.
Ưu điểm: Miễn phí, dễ triển khai, phù hợp team nhỏ/dev/test.
Nhược điểm: Giao diện cơ bản, ít tính năng cảnh báo nâng cao.
Mô tả: Thu thập log, healthcheck, phân tích và hiển thị trên Kibana.
Ưu điểm: Phân tích log mạnh, dashboard tuỳ biến, tìm kiếm nhanh.
Nhược điểm: Cài đặt, vận hành phức tạp, tốn tài nguyên hệ thống.
Cấu hình: Tối thiểu 8 vCPU, 32-128GB RAM cho node Elasticsearch; nên dùng SSD, lưu trữ từ 50GB trở lên cho production.
Dynatrace, AppDynamics, SolarWinds (Enterprise)
Mô tả: Giải pháp thương mại, giám sát toàn diện healthcheck, hiệu năng, tracing, alerting.
Ưu điểm: Tích hợp sâu, tự động phát hiện service .NET, dashboard mạnh, AI phân tích, hỗ trợ kỹ thuật chuyên nghiệp.
Nhược điểm: Chi phí cao, yêu cầu phần cứng mạnh, thường chạy trên server riêng hoặc cloud.
Khuyến Nghị Lựa Chọn
Startup, dự án nhỏ: HealthChecks.UI - tiết kiệm chi phí, dễ triển khai.
Doanh nghiệp vừa: Prometheus + Grafana hoặc Elastic Stack - ưu tiên dashboard trực quan, cảnh báo mạnh.
Doanh nghiệp lớn: Dynatrace, AppDynamics, SolarWinds – tận dụng AI, alerting nâng cao, hỗ trợ kỹ thuật từ các nhà cung cấp.
3. Cấu hình tự động gửi cảnh báo khi dịch vụ không ổn định
HealthChecks.UI + Webhook Notification
HealthChecks.UI hỗ trợ gửi cảnh báo tự động qua webhook khi phát hiện dịch vụ không ổn định. Bạn có thể cấu hình webhook để gửi thông báo đến Slack, Microsoft Teams, email, hoặc bất kỳ endpoint nào hỗ trợ HTTP.
Cấu hình cơ bản trong appsettings.json:
{
"HealthChecksUI": {
"HealthChecks": [
{
"Name": "HTTP-Api-Basic",
"Uri": "http://localhost:5000/health"
}
],
"Webhooks": [
{
"Name": "Slack Notification", // Gọi tới Slack hoặc Teams
"Uri": "https://hooks.slack.com/services/your/slack/webhook",
"Payload": "{\"text\": \"Service [[LIVENESS]] is DOWN: [[FAILURE]]\"}",
"RestoredPayload": "{\"text\": \"Service [[LIVENESS]] is UP again!\"}"
}
],
"EvaluationTimeInSeconds": 10,
"MinimumSecondsBetweenFailureNotifications": 60
}
}
EvaluationTimeInSeconds: Khoảng thời gian kiểm tra lại healthcheck (giây).
MinimumSecondsBetweenFailureNotifications: Thời gian tối thiểu giữa các lần gửi cảnh báo để tránh spam.
Payloadvà RestoredPayload: Nội dung thông báo khi dịch vụ down/up, có thể tuỳ biến với các biến như [[LIVENESS]], [[FAILURE]].
Lưu ý: Có thể cấu hình webhook bằng code để kiểm soát nâng cao hơn, ví dụ chỉ gửi cảnh báo trong giờ làm việc hoặc tuỳ biến message theo trạng thái dịch vụ
Prometheus + Alertmanager
Nếu bạn sử dụng Prometheus để scrape endpoint healthcheck, có thể cấu hình cảnh báo qua Alertmanager để gửi email, Slack, PagerDuty...
Có thể mở rộng gửi qua email, webhook, hoặc các hệ thống cảnh báo khác
Best practice khi cấu hình cảnh báo
Tránh spam: Sử dụng tham số giới hạn tần suất gửi cảnh báo (MinimumSecondsBetweenFailureNotifications hoặc for trong Prometheus) để tránh gửi quá nhiều thông báo khi dịch vụ chập chờn.
Tuỳ biến nội dung: Sử dụng biến động trong payload để thông tin cảnh báo rõ ràng, dễ hiểu, để người quản trị có thể nhận biết ngay dịch vụ nào đang có vấn đề.
Kiểm tra lại các kênh cảnh báo: Đảm bảo webhook/email/slack channel hoạt động, tránh mất cảnh báo quan trọng.
Test thử: Luôn kiểm tra lại cấu hình bằng cách cố tình/đặt lịch làm dịch vụ unhealthy để xác nhận hệ thống gửi cảnh báo đúng như mong muốn.
Kết luận
Kết hợp healthcheck với công cụ giám sát hiện đại giúp phát hiện sự cố sớm, tối ưu vận hành, tăng độ tin cậy hệ thống. Hãy lựa chọn giải pháp phù hợp với quy mô hệ thống, hạ tầng hiện có để hệ thống luôn ổn định, hiệu quả.