Tự host xong chưa đủ: phải biết app đang sống, đang lỗi, sắp chết lúc nào
Self-hosted app hấp dẫn vì kiểm soát dữ liệu, giảm chi phí dài hạn, linh hoạt triển khai. Nhưng đổi lại, bạn tự nhận luôn một việc rất dễ bị xem nhẹ: giám sát. App chạy được hôm nay chưa nghĩa là tuần sau vẫn ổn. Một chứng chỉ SSL hết hạn, disk đầy, reverse proxy lỗi, DB treo vài phút → người dùng thấy “web chết”, còn bạn chỉ biết khi có người nhắn.
Tin tốt: giám sát uptime, log, cảnh báo không cần phải thành một “hệ observability” đồ sộ. Với phần lớn self-hosted app, chỉ cần làm đúng 3 lớp cơ bản là đã giảm rất nhiều rủi ro:
– Uptime monitoring → biết dịch vụ còn phản hồi không
– Log monitoring → biết lỗi gì đang xảy ra
– Alerting → biết lúc nào cần hành động ngay
Bài này tập trung vào cách làm dễ áp dụng, chi phí thấp, triển khai thực tế cho cá nhân, homelab, VPS nhỏ, hoặc team vận hành ít người.
1. Tư duy đúng: đừng bắt đầu từ dashboard, hãy bắt đầu từ câu hỏi
Sai lầm phổ biến: cài rất nhiều công cụ rồi mở dashboard đẹp mắt, nhưng khi sự cố xảy ra vẫn không biết phải nhìn vào đâu.
Cách làm hiệu quả hơn: bắt đầu từ 3 câu hỏi:
1.1 App của bạn có “sống” không?
Đây là lớp cơ bản nhất. Một URL không phản hồi, trả 500, timeout, SSL lỗi → phải biết ngay.
Ví dụ cần kiểm tra:
– Trang chủ có trả 200 OK không
– API /health có hoạt động không
– HTTPS có còn hợp lệ không
– Reverse proxy có đang route đúng không
1.2 Nếu app “sống” nhưng người dùng vẫn lỗi, nguyên nhân ở đâu?
Lúc này uptime check chưa đủ. App vẫn trả 200 nhưng login lỗi, queue kẹt, DB từ chối kết nối, disk sắp đầy. Bạn cần log để truy vết.
Nguồn log nên có:
– Application log → lỗi business, stack trace
– Web server/reverse proxy log → request, response code, latency
– System log → disk, memory, service restart, kernel issue
– Container log nếu dùng Docker
1.3 Khi nào thì cần bị đánh thức?
Không phải lỗi nào cũng đáng gửi alert. Nếu mỗi cảnh báo đều ping điện thoại, bạn sẽ nhanh chóng “lờ” mọi thông báo.
Nguyên tắc:
– Cảnh báo ngay → downtime, SSL sắp hết hạn, disk gần đầy, DB không kết nối
– Chỉ ghi nhận/log → 1-2 lỗi lẻ tẻ, retry tự hồi
– Tổng hợp định kỳ → warning nhẹ, xu hướng tăng chậm
2. Giám sát uptime: lớp đơn giản nhất, giá trị lớn nhất
Nếu chỉ được chọn một thứ để làm đầu tiên, hãy chọn uptime monitoring.
2.1 Nên theo dõi gì?
Tối thiểu:
– URL public của app
– Endpoint /health hoặc /ready
– Reverse proxy/nginx
– SSL certificate expiration
Nếu app nội bộ, có thể kiểm tra:
– TCP port còn mở không
– Ping giữa các node
– Service process còn chạy không
2.2 Dùng công cụ nào?
Một lựa chọn rất hợp self-hosted là:
– Uptime Kuma → dễ cài, UI rõ, hỗ trợ HTTP/TCP/ping/SSL, gửi notification tốt
Điểm mạnh:
– Triển khai nhanh bằng Docker
– Phù hợp cá nhân/team nhỏ
– Có thể monitor cả dịch vụ public lẫn private
– Thiết lập cảnh báo qua Telegram, Discord, Slack, email, webhook
2.3 Cấu hình tối thiểu nên có
Với mỗi app, tạo ít nhất 2 monitor:
– HTTP(s) monitor cho URL người dùng truy cập
– Keyword/status monitor cho endpoint health
Ví dụ:
– https://app.example.com → kiểm tra status code
– https://app.example.com/health → kiểm tra response chứa "ok"
Như vậy:
– Homepage chết → biết ngay
– Homepage còn nhưng backend hỏng → health check phát hiện
2.4 Sai lầm thường gặp
– Chỉ monitor cổng mở → app lỗi logic vẫn không phát hiện
– Chỉ monitor từ bên trong server → mạng ngoài lỗi không biết
– Đặt interval quá ngắn → tăng noise
– Không cấu hình retry → alert giả khi mạng chập chờn
Mức hợp lý với self-hosted app thường là:
– Check mỗi 1–5 phút
– Alert sau 2–3 lần fail liên tiếp
3. Log: nơi sự cố lộ nguyên hình
Uptime cho bạn biết có vấn đề. Log cho bạn biết vấn đề là gì.
3.1 Nên gom log về một chỗ
Khi app lỗi, việc SSH vào từng máy, xem từng file log rất mất thời gian. Tốt hơn: gom log tập trung.
Hướng nhẹ, dễ làm:
– Docker logs + log rotation
– journald/system logs
– Một stack log tập trung như:
– Loki + Promtail + Grafana
– hoặc ELK/OpenSearch nếu cần mạnh hơn nhưng nặng hơn
Với self-hosted quy mô nhỏ, Loki thường là lựa chọn cân bằng hơn:
– Nhẹ hơn ELK
– Tích hợp Grafana tốt
– Đủ dùng để tra lỗi, lọc theo service/container/time
3.2 Log gì là hữu ích?
Không phải log càng nhiều càng tốt. Mục tiêu: đủ để điều tra.
Nên có:
– Timestamp rõ ràng
– Mức độ log: INFO, WARN, ERROR
– Tên service/app
– Request ID hoặc trace ID nếu có
– Thông điệp lỗi đầy đủ
– Stack trace khi exception
Ví dụ hữu ích:
– db connection refused
– disk quota exceeded
– authentication failed for user
– upstream timed out
– 502 bad gateway
Ví dụ kém hữu ích:
– something went wrong
– unknown error
– log quá nhiều dữ liệu rác, không phân mức
3.3 Đừng quên log của hạ tầng
Nhiều sự cố không nằm trong code app:
– Nginx trả 502/504
– Docker container restart liên tục
– Disk usage 95%
– OOM killer giết process
– Certbot renew thất bại
Nếu chỉ xem log ứng dụng → rất dễ chẩn đoán sai.
4. Cảnh báo: ít nhưng trúng
Alert tốt không phải alert nhiều. Alert tốt là alert khiến bạn hành động đúng lúc.
4.1 Kênh gửi cảnh báo phù hợp
Với self-hosted app, thực dụng nhất thường là:
– Telegram → nhanh, miễn phí, dễ dùng
– Discord/Slack → hợp team nhỏ
– Email → nên có, nhưng không nên là kênh duy nhất
– Webhook → nếu muốn nối sang hệ khác
Nếu app quan trọng, nên có 2 kênh:
– 1 kênh realtime: Telegram/Slack
– 1 kênh backup: email
4.2 Nên cảnh báo gì?
Bộ cảnh báo tối thiểu:
– App không phản hồi trong X phút
– SSL sắp hết hạn
– Disk > 80% hoặc 90%
– RAM/CPU tăng bất thường kéo dài
– Container/service restart liên tục
– Tỷ lệ lỗi HTTP 5xx tăng cao
– DB không kết nối được
Nếu có job định kỳ/backup:
– Backup thất bại
– Cron job không chạy đúng lịch
4.3 Chống “alert fatigue”
Áp dụng các nguyên tắc sau:
– Dùng ngưỡng + thời gian duy trì, không cảnh báo vì spike 1 phút
– Gộp cảnh báo giống nhau
– Có recovery notification để biết hệ thống đã hồi
– Tách mức độ:
– Critical → cần xử lý ngay
– Warning → theo dõi
– Info → chỉ ghi nhận
Ví dụ tốt:
– Disk > 90% trong 10 phút → alert
– HTTP 500 > 5% trong 5 phút → alert
Ví dụ xấu:
– CPU lên 95% trong 10 giây → ping liên tục
5. Một setup thực tế, dễ áp dụng cho đa số self-hosted app
Nếu bạn muốn một mô hình “đủ tốt, không quá nặng”, có thể bắt đầu như sau:
5.1 Stack đề xuất
– Uptime Kuma → uptime + SSL + notification
– Grafana + Loki + Promtail → tập trung log
– Node Exporter + Grafana hoặc công cụ tương đương → CPU, RAM, disk
– Telegram → nhận cảnh báo
5.2 Triển khai theo thứ tự
1. Bật uptime check trước
Theo dõi URL chính, health endpoint, SSL.
2. Gom log của app và reverse proxy
Ưu tiên app quan trọng nhất trước.
3. Thêm metric hệ thống cơ bản
CPU, RAM, disk, network, restart count.
4. Đặt alert cho 5 tình huống hay chết nhất
Downtime, SSL, disk đầy, DB lỗi, restart loop.
5. Chạy thử sự cố giả lập
Tắt container, sửa sai endpoint, làm đầy disk test → xem alert có tới không.
5.3 Checklist tối thiểu
– [ ] Có endpoint health riêng
– [ ] Có monitor từ bên ngoài
– [ ] Có lưu log tập trung ít nhất 7–14 ngày
– [ ] Có cảnh báo Telegram/email
– [ ] Có log rotation
– [ ] Có cảnh báo disk đầy
– [ ] Có test alert định kỳ
6. Những lưu ý quan trọng để hệ giám sát không tự thành gánh nặng
6.1 Giữ mọi thứ đơn giản
Self-hosted app nhỏ không cần Prometheus, ELK, tracing, SIEM, SLO đầy đủ ngay từ đầu. Cài quá nặng → tốn tài nguyên, khó bảo trì.
Nguyên tắc tốt:
– Bắt đầu nhỏ
– Chỉ thêm thứ gì khi có lý do rõ ràng
– Công cụ nào khó vận hành hơn chính app → cân nhắc lại
6.2 Quan tâm retention và dung lượng
Log tăng rất nhanh. Nếu không giới hạn:
– Disk đầy → app chết thật
– Hệ giám sát thành nguyên nhân outage
Nên đặt:
– Log retention 7–30 ngày tùy nhu cầu
– Log rotation rõ ràng
– Loại bỏ debug log không cần thiết ở production
6.3 Tài liệu hóa cách phản ứng
Mỗi alert quan trọng nên có “runbook” ngắn:
– Alert này nghĩa gì
– Kiểm tra gì trước
– Lệnh nào cần chạy
– Khi nào cần restart
– Khi nào cần rollback
Lúc 2 giờ sáng, runbook ngắn giá trị hơn dashboard đẹp.
Kết luận
Giám sát tốt cho self-hosted app không đòi hỏi phải phức tạp. Mục tiêu không phải xây một trung tâm điều khiển hoành tráng, mà là trả lời nhanh 3 điều:
– App còn sống không?
– Nếu lỗi, lỗi ở đâu?
– Khi nào tôi cần can thiệp?
Cách dễ áp dụng nhất cho đa số trường hợp là:
– Uptime Kuma để theo dõi uptime/SSL
– Loki + Grafana để xem log tập trung
– Telegram/email alert để biết ngay khi có sự cố
– Thêm CPU/RAM/disk monitoring làm lớp bảo vệ nền
Nếu hôm nay bạn chưa có gì, hãy bắt đầu rất thực tế: tạo 1 health check, monitor 1 URL quan trọng, bật 3 cảnh báo cơ bản. Chỉ vậy thôi cũng đã tốt hơn rất nhiều so với việc chờ người dùng báo “app của anh/chị đang chết rồi”.
Quan trọng nhất: giám sát chỉ có giá trị khi nó được kiểm tra định kỳ. Hãy thử làm “mất dịch vụ” có kiểm soát, xem cảnh báo có tới không, log có đủ không, và bạn có tìm ra nguyên nhân trong vài phút không. Nếu câu trả lời là có, hệ giám sát của bạn đã đi đúng hướng.