Tự xây hệ thống giám sát bằng Uptime Kuma

Uptime Kuma là công cụ giám sát tự lưu trữ, phù hợp để xây một bảng theo dõi tình trạng dịch vụ do chính bạn quản lý. Tài liệu dự án hướng dẫn triển khai bằng Docker với image louislam/uptime-kuma:2, cổng ứng dụng 3001 và dữ liệu tại /app/data. Tuy nhiên, một hệ thống giám sát hữu ích cần thêm phép kiểm tra phù hợp, đường nhận cảnh báo và phương án khôi phục dữ liệu.

Chuẩn bị nơi chạy và dữ liệu bền vững

Hướng dẫn này giả định bạn đã có máy Linux chạy Docker và quyền quản trị Docker. Các lệnh dưới đây là cấu hình mẫu để người đọc tự áp dụng, chưa được kiểm thử trên hạ tầng của bạn. Trước khi bắt đầu, hãy xác định máy nào sẽ chạy Kuma, dịch vụ nào cần theo dõi và ai nhận cảnh báo. Về thiết kế, nên cân nhắc đặt bộ giám sát ngoài máy chứa dịch vụ quan trọng: nếu cả hai cùng ngừng hoạt động, bạn khó trông đợi chính bộ giám sát đó phát hiện và gửi tin.

Chọn image có chủ đích. Docker Hub của tác giả và trang Docker Tags đều khuyến nghị tag 2 cho nhánh v2; tag latest đã bị đánh dấu không còn được khuyến nghị. Tag 2 đi theo các bản phát hành của nhánh này, còn dạng 2.x.x dùng để cố định một phiên bản cụ thể. Vì vậy, hãy ghi lại phiên bản hoặc định danh image đang chạy trước mỗi lần cập nhật, thay vì chỉ lưu một câu lệnh cài đặt.

Với lưu trữ, README và hướng dẫn cài đặt đều yêu cầu ánh xạ /app/data ra thư mục hoặc volume cục bộ. Dự án cảnh báo về NFS và yêu cầu hỗ trợ khóa tệp POSIX để tránh rủi ro hỏng cơ sở dữ liệu SQLite. Ví dụ dưới đây dùng named volume uptime-kuma. Theo Docker Docs, volume tồn tại độc lập với vòng đời container; thay container không đồng nghĩa phải tạo lại dữ liệu, nhưng volume vẫn cần được sao lưu.

Bước 1 — tạo container mới bằng lệnh mẫu:

docker run -d --restart=unless-stopped -p 127.0.0.1:3001:3001 -v uptime-kuma:/app/data --name uptime-kuma louislam/uptime-kuma:2

Chỉ dùng nguyên mẫu khi tên container và cổng này chưa được sử dụng. Ánh xạ 127.0.0.1 giới hạn cổng công bố về loopback trong cấu hình mạng Docker thông thường; hãy kiểm tra thêm cấu hình mạng thực tế. Docker cũng lưu ý các bản trước 28.0.0 có ngoại lệ truy cập từ cùng phân đoạn mạng lớp 2.

Bước 2 — kiểm tra từng lệnh:

docker ps -a --filter name=uptime-kuma

docker logs --tail 100 uptime-kuma

Lệnh đầu giúp xem trạng thái container; lệnh sau đọc phần cuối nhật ký. Nếu container thoát hoặc khởi động lặp, hãy xử lý lỗi trong log trước khi cấu hình monitor. Khi thao tác ngay trên máy chạy Docker, mở địa chỉ loopback cổng 3001. Nếu dùng VPS từ xa, đừng hiểu localhost trên máy cá nhân là VPS.

Chọn phép kiểm tra và thử đường cảnh báo

Nếu cần truy cập qua tên miền, tài liệu Uptime Kuma khuyến nghị đặt ứng dụng sau reverse proxy như Nginx hoặc Apache. Ứng dụng sử dụng WebSocket nên proxy cần chuyển tiếp đúng các header Upgrade và Connection. Hãy kiểm tra giao diện qua HTTPS sau khi cấu hình. Nên hoàn thiện đường truy cập này trước khi nhập thông tin nhạy cảm; bài viết không giả định bạn đã có chứng chỉ hay một cấu hình proxy phù hợp.

Bước 3 — tạo một monitor đầu tiên, bắt đầu bằng dịch vụ bạn hiểu rõ. README và mã giao diện của dự án thể hiện các lựa chọn HTTP(S), TCP, Ping, DNS, kiểm tra từ khóa HTTP(S) và truy vấn JSON. Với website, có thể bắt đầu bằng HTTP(S); nếu cần xác nhận một dấu hiệu nội dung, hãy cân nhắc kiểu từ khóa. Đây là gợi ý thiết kế: trước khi chọn, hãy viết rõ điều kiện nào mới thực sự có nghĩa là dịch vụ hoạt động.

Ví dụ giả định, một trang bán hàng vẫn trả về trang bảo trì thì việc chỉ quan tâm khả năng nhận phản hồi chưa chắc trả lời đúng câu hỏi của người vận hành. Hãy chọn nội dung kiểm tra gắn với chức năng cần bảo vệ, rồi quan sát kết quả trên chính ứng dụng của mình. Với chu kỳ kiểm tra và số lần thử lại, nên bắt đầu thận trọng, ghi nhận cảnh báo phát sinh rồi điều chỉnh; không có con số mẫu nào trong bài này được coi là bảo đảm phát hiện sự cố.

Bước 4 — cấu hình đường nhận tin. README liệt kê những kênh như Telegram, Discord và email SMTP; wiki Notification Methods xác nhận dự án hỗ trợ nhiều dịch vụ thông báo. Chọn một kênh có người chịu trách nhiệm theo dõi, nhập thông tin theo yêu cầu của kênh và kiểm tra việc nhận tin. Sau đó, đề xuất thử một tình huống lỗi có kiểm soát trên dịch vụ thử nghiệm: xác nhận monitor nhận biết lỗi, thông báo tới đúng nơi và trạng thái trở lại bình thường khi phục hồi. Không dùng dịch vụ sản xuất làm đối tượng thử dừng tùy tiện.

Sao lưu và chuẩn bị đường quay lại

Bước 5 — trước khi cập nhật, dừng Kuma và sao lưu đầy đủ vùng dữ liệu. Hướng dẫn chuyển v1 sang v2 yêu cầu việc này, đồng thời cho biết tính năng sao lưu/khôi phục JSON cũ đã bị loại bỏ. Docker Docs mô tả cách gắn volume vào container phụ để đóng gói và khôi phục dữ liệu. Hãy lưu bản sao ở vị trí khác, ghi lại image tương ứng và thử phục hồi trong môi trường tách biệt. Chỉ thấy một tệp sao lưu chưa đủ để kết luận bạn có thể khôi phục.

Quy trình cập nhật Docker của dự án là kéo image mới, dừng và thay container nhưng dùng lại volume. Nếu nâng cấp từ v1 sang v2, phải đọc hướng dẫn migration riêng và theo dõi log; dự án cảnh báo không ngắt quá trình chuyển đổi. Phương án rollback nên chuẩn bị từ trước: giữ image cũ cùng bản dữ liệu trước nâng cấp, dừng bản lỗi và phục hồi bản sao đó trong môi trường phù hợp. Không coi việc đổi ngược tag trên dữ liệu đã chuyển đổi là đủ, và không xóa volume để thử sửa lỗi vì có thể mất dữ liệu cần cứu.

Nguồn tham khảo