Tự host

Hướng dẫn sử dụng tài nguyên và thiết lập Uptime Kuma v2 cho người tự host

Một bài kiểm tra triển khai thực tế của Uptime Kuma v2 cho thấy mức tiêu thụ RAM thấp, lợi ích của SQLite với các cấu hình nhỏ và những sai lầm phổ biến khi giám sát.

Hình minh họa một máy chủ với biểu tượng giám sát sức khỏe
Ảnh minh họa tạo riêng cho bài viết

Bài được dịch tự động từ bản gốc tiếng Anh.

Một đánh giá kỹ thuật gần đây về phiên bản 2 của Uptime Kuma cung cấp các số liệu cụ thể về tài nguyên và lời khuyên cấu hình dành cho các nhà phát triển vận hành hạ tầng riêng. Được công bố vào ngày 7 tháng 10 năm 2026, hướng dẫn này chi tiết hóa quy trình cài đặt mới, nhấn mạnh rằng công cụ vẫn đủ nhẹ để chạy trên phần cứng tối thiểu trong khi giới thiệu các tùy chọn cơ sở dữ liệu mới ở bản phát hành lớn thứ hai.

Chuyện gì đã xảy ra

Tác giả đã triển khai Uptime Kuma v2 bằng Docker Compose để đo lường dấu chân tài nguyên thực tế trên một máy trạm hiện đại. Việc tải image ban đầu chiếm 574 MB dung lượng ổ đĩa, nhưng mức sử dụng bộ nhớ khi chạy thấp hơn đáng kể. Với không có monitor nào đang hoạt động, container tiêu tốn 143 MB RAM. Khi được cấu hình với ba monitor đang hoạt động kiểm tra mỗi 60 giây, mức sử dụng bộ nhớ dao động từ 133 MB đến 147 MB, trong khi tải CPU duy trì dưới 1% của một lõi đơn. Những con số này cho thấy ứng dụng có thể chạy thoải mái trên các thiết bị chỉ có 256 MB RAM trống, chẳng hạn như Raspberry Pi hoặc một máy chủ ảo riêng (VPS) cấp nhập môn.

Một thay đổi đáng chú ý trong phiên bản 2 là việc giới thiệu bước lựa chọn cơ sở dữ liệu trong quá trình thiết lập ban đầu. Người dùng có thể chọn giữa SQLite và một instance MariaDB nhúng. Đánh giá khuyến nghị sử dụng SQLite cho các cài đặt có ít hơn 50 monitor, nhờ quản lý đơn giản hơn và chi phí tài nguyên thấp hơn. Trong một bài kiểm tra kéo dài hai tháng với ba monitor, dung lượng dữ liệu SQLite tăng lên chưa tới 2 MB. Điều này trái ngược với MariaDB, vốn phù hợp hơn với các triển khai quy mô lớn liên quan đến hàng trăm monitor nhưng đòi hỏi bảo trì phức tạp hơn.

Hướng dẫn cũng ghi nhận các lỗi cấu hình phổ biến gặp phải trong quá trình thử nghiệm. Việc cố gắng giám sát một repository GitHub riêng tư qua các kiểm tra HTTP tiêu chuẩn dẫn đến lỗi 404 vì monitor thiếu token xác thực. Tương tự, việc kiểm tra endpoint REST của Supabase mà không có API key trả về phản hồi 401 unauthorized, báo cáo sai lệch về thời gian ngừng hoạt động. Tác giả khuyên nên sử dụng TCP port monitors cho các cơ sở dữ liệu và dịch vụ yêu cầu xác thực, thay vì dựa vào các kiểm tra trạng thái HTTP cơ bản.

Chi tiết chính

  • Kích thước Image: Docker image nặng 574 MB, mất vài phút để tải trên các kết nối băng thông rộng tiêu chuẩn.
  • Mức sử dụng bộ nhớ: Mức sử dụng khi nhàn rỗi là 143 MB; với ba monitor đang hoạt động, nó duy trì trong khoảng từ 133 MB đến 147 MB.
  • Lựa chọn cơ sở dữ liệu: SQLite được khuyến nghị cho dưới 50 monitor do tính đơn giản và kích thước sao lưu nhỏ (dưới 2 MB trong thử nghiệm).
  • Tốc độ khởi động lại: Container khởi động lại trong 1,6 giây và phục vụ traffic trở lại trong vòng chưa đầy 10 giây.
  • Những cạm bẫy thường gặp: Monitor HTTP thất bại trên các endpoint yêu cầu xác thực; hãy sử dụng TCP monitors cho cơ sở dữ liệu hoặc keyword/API monitors kèm token cho các repo riêng tư.
  • Phương pháp sao lưu: Dữ liệu nằm trong một named volume duy nhất, cho phép sao lưu dễ dàng bằng các lệnh tar.

Bối cảnh

Uptime Kuma là một giải pháp mã nguồn mở thay thế cho các dịch vụ giám sát uptime thương mại như UptimeRobot hay Pingdom. Nó cho phép người dùng tự host trang trạng thái và dashboard giám sát của riêng mình, loại bỏ phí theo từng monitor và các hạn chế về khoảng thời gian kiểm tra. Công cụ hỗ trợ nhiều loại monitor khác nhau, bao gồm kiểm tra HTTP, TCP và ping, đồng thời có thể gửi cảnh báo qua nhiều kênh khi dịch vụ trở nên không khả dụng.

Việc tự host các công cụ giám sát chuyển trách nhiệm về tính sẵn sàng từ nhà cung cấp bên thứ ba sang hạ tầng của chính người dùng. Cách tiếp cận này mang lại quyền kiểm soát lớn hơn đối với quyền riêng tư dữ liệu và khả năng tùy chỉnh, nhưng cũng tạo ra một điểm lỗi duy nhất: nếu máy chủ hosting monitor ngoại tuyến, nó không thể phát hiện sự cố ngừng hoạt động ở các dịch vụ khác. Do đó, độ tin cậy của máy chủ host là yếu tố then chốt đối với hiệu quả của hệ thống giám sát.

Tại sao điều này quan trọng

Đối với các đội ngũ quản lý hạ tầng từ nhỏ đến trung bình, việc hiểu rõ chi phí tài nguyên thực tế của các công cụ giám sát là rất cần thiết cho việc hoạch định năng lực. Xác nhận rằng Uptime Kuma v2 chạy hiệu quả trên phần cứng tối thiểu có nghĩa là nó có thể được triển khai trên các thiết bị tiết kiệm điện hiện có hoặc các instance cloud giá rẻ mà không ảnh hưởng đến các workload khác. Điều này hạ thấp rào cản gia nhập cho việc giám sát toàn diện, cho phép ngay cả các dự án nhỏ theo dõi sức khỏe dịch vụ mà không cần phân bổ ngân sách đáng kể.

Sự khác biệt giữa giám sát HTTP và TCP là một bài học thực tiễn cho các kỹ sư DevOps. Cấu hình sai monitor cho các dịch vụ yêu cầu xác thực dẫn đến các cảnh báo dương tính giả, làm giảm độ nhạy cảm của đội ngũ đối với cảnh báo hoặc lãng phí thời gian điều tra các vấn đề không tồn tại. Bằng cách chọn đúng loại monitor, các đội ngũ đảm bảo rằng cảnh báo phản ánh tính sẵn sàng thực sự của dịch vụ chứ không phải lỗi quyền hạn. Độ chính xác này rất quan trọng để duy trì niềm tin vào các hệ thống giám sát nội bộ.

Ngoài ra, việc chuyển sang SQLite cho các cài đặt nhỏ giúp đơn giản hóa vận hành. Quản lý một máy chủ cơ sở dữ liệu riêng biệt làm tăng độ phức tạp cho việc sao lưu, cập nhật và vá bảo mật. Sử dụng cơ sở dữ liệu nhúng giảm bớt gánh nặng vận hành này, giúp các đội ngũ nhỏ dễ dàng duy trì stack giám sát của họ mà không cần kỹ năng quản trị cơ sở dữ liệu chuyên biệt. Sự đơn giản này phù hợp với mục tiêu của nhiều người tự host, những người ưu tiên tính dễ bảo trì song song với chức năng.

Bạn có thể làm gì

  • Triển khai với Docker Compose: Sử dụng file compose được cung cấp cùng với một named volume để đảm bảo tính bền vững của dữ liệu qua các lần tái tạo container.
  • Chọn SQLite cho các cấu hình nhỏ: Nếu bạn có ít hơn 50 monitor, hãy chọn SQLite trong quá trình thiết lập để giảm thiểu mức sử dụng RAM và đơn giản hóa việc sao lưu.
  • Sử dụng TCP monitors cho cơ sở dữ liệu: Tránh kiểm tra HTTP cho các dịch vụ yêu cầu xác thực; thay vào đó, hãy giám sát cổng cụ thể (ví dụ: 5432 cho Postgres) để xác minh kết nối.
  • Bảo vệ tài khoản admin của bạn: Sử dụng mật khẩu mạnh, độc đáo được tạo bởi trình quản lý mật khẩu, vì dashboard chứa thông tin nhạy cảm về hạ tầng của bạn.
  • Lên lịch sao lưu định kỳ: Tự động hóa các snapshot hàng tuần của volume dữ liệu và lưu trữ chúng trên một đĩa hoặc vị trí riêng biệt để ngăn ngừa mất dữ liệu.
  • Đảm bảo tính sẵn sàng của host: Chạy Uptime Kuma trên một máy luôn bật, chẳng hạn như một VPS chuyên dụng hoặc một máy chủ gia đình đáng tin cậy, để đảm bảo giám sát liên tục.

Tin khác

Tất cả tin