Đánh giá Prometheus: Tự vận hành có còn đáng không?

Thứ bạn tự xây đang chạy trên môi trường thật. Hệ thống giám sát của bạn hoặc là không có gì, hoặc chỉ là một cú ping kiểm tra sống chết, và tuần trước bạn biết tin sự cố là nhờ một người dùng báo. Mọi câu trả lời bạn tìm đều dẫn về cùng một cái tên.

Bài đánh giá Prometheus này nói về khoảng cách giữa hai điều đều đúng cùng lúc. Nó miễn phí và mã nguồn mở, không giấy phép và không hóa đơn tính theo từng chỉ số, ở bất kỳ quy mô nào. Nó cũng lấy của bạn một buổi tối cộng thêm một ngôn ngữ truy vấn mà bạn chưa biết. Đây là một bộ thu thập chỉ số theo cơ chế pull có kèm cảnh báo, và là một phần mềm xuất sắc. Còn nó có phải phần mềm phù hợp với hệ thống bạn đang chạy lúc này hay không lại là câu hỏi khác, và đó mới là câu hỏi đáng trả lời.

Phiên bản ngắn gọn

• Kết luận: 3,5 / 5 cho việc tự vận hành một mình hoặc theo nhóm nhỏ. Prometheus đáng để chạy nếu tập hợp host và dịch vụ của bạn tương đối ổn định, bạn chịu bỏ thời gian học PromQL, và bạn muốn những chỉ số hoàn toàn thuộc về mình, không thuê bao và không hóa đơn cho việc lưu trữ.
• Hãy bỏ qua nó nếu câu hỏi bạn cần trả lời chỉ là “nó còn sống không”. Một công cụ kiểm tra tình trạng hoạt động đưa bạn đến câu trả lời đó nhanh hơn nhiều, và lôi Prometheus ra làm việc ấy nghĩa là trả giá bằng một ngôn ngữ truy vấn cho thứ mà bạn có thể giải quyết trong mười phút.
• PromQL là khoản chi phí cứ quay lại mãi. Cài đặt là chi phí một lần. Nhưng ngay khi câu hỏi của bạn vượt quá các bảng điều khiển dựng sẵn và trình dựng truy vấn trực quan của Grafana, bạn lại quay về PromQL.
• Chi phí bảo trì đi theo phần hệ thống mà bạn quản lý thủ công. Một đội máy giữ nguyên hình dạng thì giám sát rất rẻ. Còn đội máy liên tục thêm, bớt và đổi tên host mới chính là nơi chi phí âm thầm dồn lại.
• Kết luận này chỉ giới hạn ở việc tự vận hành quy mô nhỏ. Ở quy mô Kubernetes và SRE trong môi trường sản xuất, Prometheus là một đề xuất hoàn toàn khác, và bài đánh giá này không cố trả lời câu hỏi đó.

Bài đánh giá này được thực hiện thế nào: Prometheus miễn phí và mã nguồn mở, nên ở đây không có quan hệ nào với nhà cung cấp và không ai gửi cho tôi thứ gì. Các thông tin về phiên bản và cách hoạt động của bộ lưu trữ lấy từ tài liệu chính thức của Prometheus. Các con số về tài nguyên và thời gian cài đặt lấy từ hai bài kiểm thử thực tế được công bố độc lập, và mỗi bài đều được dẫn nguồn ngay tại chỗ nó được dùng. Ở những chỗ hai bài đó lệch nhau, bạn sẽ thấy cả hai con số thay vì một giá trị trung bình.

Bài đánh giá này bàn về những gì

Kết luận phía trên có giới hạn, và ở đây những giới hạn ấy quan trọng hơn bình thường, bởi Prometheus hành xử như một công cụ khác hẳn ở mỗi quy mô.

• Prometheus được đánh giá cho việc tự vận hành trên một VPS duy nhất và cho các dự án nhỏ: một nhúm host và dịch vụ, một người trông coi.
• Không phải Kubernetes. Prometheus Operator, ServiceMonitors và kube-prometheus-stack là một thế giới vận hành riêng, và kết luận ở đây không nói gì về thế giới đó.
• Không phải hướng dẫn định tuyến Alertmanager. Cảnh báo có tồn tại và hoạt động tốt; còn việc cấu hình route, silence và receiver là một chủ đề riêng.
• Không phải hướng dẫn cài đặt. Câu hỏi ở đây là có nên chạy nó hay không. Nếu bạn đã trả lời xong câu đó, hướng dẫn Grafana và Prometheus bằng Docker Compose của chúng tôi trình bày đầy đủ các bước.
• Không phải bản khảo sát exporter. Exporter chỉ xuất hiện ở những chỗ chúng làm thay đổi câu trả lời.

Những gì Prometheus làm tốt

Prometheus không tốn gì cả. Không phải “gói miễn phí kèm nâng cấp trả tiền”, cũng không phải “miễn phí cho đến khi bạn vượt hạn mức chỉ số”. Kho mã nguồn dùng giấy phép Apache 2.0 từ đầu đến cuối, không có bản trả phí cho dự án lõi, và không có chỗ nào tính tiền theo host, theo chỉ số hay theo nhãn. Hóa đơn duy nhất mà Prometheus tạo ra là cái máy chủ nó đang chạy trên đó.

Với thứ bạn định dựa vào lâu dài, câu hỏi “ba năm nữa nó còn ở đây không” là hoàn toàn chính đáng, và ở đây cơ hội tốt gần như mức tốt nhất mà mã nguồn mở có thể cho. Prometheus tốt nghiệp CNCF vào tháng 8 năm 2018, là dự án thứ hai trong lịch sử làm được điều đó, sau Kubernetes. Các bản phát hành ra đều đặn, với v3.13.2 ra mắt cuối tháng 7 năm 2026, và vì nhánh phát hành đó là nhánh hỗ trợ dài hạn, nó nhận được các bản vá lỗi, bảo mật và tài liệu trong vòng một năm, nên việc giữ bản vá cập nhật không đồng nghĩa với chạy theo từng phiên bản phụ.

Mô hình dữ liệu là lý do hệ sinh thái quanh nó sâu đến vậy. Prometheus thu thập chỉ số qua HTTP và định danh mỗi chuỗi bằng tên chỉ số cộng với các nhãn khóa/giá trị, khiến việc viết một exporter trở thành công việc nhỏ. Vì thế exporter tồn tại cho gần như mọi thứ bạn có thể chạy: chỉ số của máy, Postgres, Nginx, Redis, và các blackbox probe cho những thứ chỉ có thể chọc từ bên ngoài.

Và bạn sở hữu những gì nó thu thập, đây là phần thường quan trọng về sau chứ không phải ngày đầu tiên. Lịch sử của một hệ thống nhỏ chiếm một lượng đĩa chẳng đáng kể (số liệu ở dưới), không ai có thể định giá lại nó vào quý sau, và không có dòng nào trên hóa đơn phình lên mỗi lần ai đó thêm đo đạc vào một ứng dụng. Nếu bạn từng nhìn hóa đơn dịch vụ giám sát có quản lý leo lên chỉ vì một lập trình viên thêm một nhãn, cả lập luận nằm gọn trong câu đó.

Chỗ Prometheus đắt hơn vẻ ngoài của nó

Một bài kiểm thử trên dev.to với bảy công cụ giám sát trên cùng một VPS nhỏ đo được riêng Prometheus mất 15 phút để cài đặt. Hãy ghép nó với Grafana như người thử nghiệm đó đã làm, vì trình duyệt biểu thức tích hợp chỉ là nơi để chạy truy vấn. Cũng bài kiểm thử ấy đặt cặp Grafana + Prometheus ở mức 35 phút cho tới biểu đồ đầu tiên, với phần cấu hình scrape bằng YAML nằm ở giữa.

Số phút là phần rẻ. Phần đắt là PromQL. Prometheus lưu mọi thứ dưới dạng chuỗi thời gian được định danh bằng tên và nhãn, và PromQL vẫn là ngôn ngữ nằm bên dưới mọi câu hỏi bạn đặt ra cho nó. Grafana giờ đã có trình dựng trực quan, nên bạn không phải viết tay từng truy vấn. Kết luận của chính người thử nghiệm rất thẳng: PromQL tuyệt vời với ai sống trong nó, còn anh ta thì không. Nếu bạn chưa bao giờ dùng một ngôn ngữ truy vấn, hãy dành ra hơn một buổi tối cho việc đó, và chuẩn bị tinh thần quay lại mỗi khi trình dựng trực quan không còn đủ. Một bảng điều khiển bạn chép của người khác trả lời câu hỏi của người đó. Câu hỏi của bạn là một truy vấn bạn chưa viết.

Khoản chi phí thứ ba là khoản mãi về sau mới lộ ra. Một bản ghi chép ba tuần của một người vận hành mô tả chính xác việc thêm một máy chủ vào hệ thống bảy node đòi hỏi những gì: gán lại nhãn, kiểm tra lại các cấu hình scrape, sửa biến của bảng điều khiển và làm lại các truy vấn mẫu để host mới hiện ra trong danh sách thả xuống. Người vận hành đó bỏ cuộc sau ba tuần, với kết luận rằng anh ta dành nhiều thời gian tinh chỉnh bảng điều khiển hơn là thực sự theo dõi hạ tầng.

Hãy để ý khoản chi phí ấy gắn với điều gì trong kiểu hệ thống này: với các target và bảng điều khiển được quản lý thủ công. Chạy Prometheus suốt hai năm yên ả gần như không tốn thêm gì.

Prometheus thực sự cần bao nhiêu RAM và đĩa?

Không có yêu cầu cố định nào. Số chuỗi đang hoạt động, tần suất thu thập, tải truy vấn và thời gian lưu trữ quan trọng hơn con số máy chủ mà bạn trỏ nó vào. Hai bài kiểm thử thực tế đã công bố trên các hệ thống nhỏ đặt nó vào khoảng 180 MB đến 800 MB, trong đó con số cao hơn ứng với bảy node cùng vài tuần lịch sử.

Hai bài kiểm thử không khớp nhau, và chính chỗ không khớp ấy mới hữu ích. Cũng bài so sánh bảy công cụ trên VPS đó chạy mọi công cụ trên phần cứng giống hệt nhau (1 vCPU, 2 GB RAM, 25 GB đĩa, Ubuntu 24.04) trong lúc theo dõi bốn trang web bên ngoài cộng với chính máy chủ, và đo Prometheus ở mức khoảng 180 MB khi rảnh. Cũng người vận hành đó báo rằng riêng Prometheus nằm quanh mức 300 MB khi rảnh trên máy chủ trung tâm, rồi leo về phía 600 đến 800 MB khi đã tích được vài tuần lịch sử.

Đó không phải cùng một phép đo, và vì thế lấy trung bình hai con số là vứt bỏ thông tin. Một bên là số đọc gần như rảnh rỗi trên một máy gần như chẳng có gì để lưu. Bên kia là một hệ thống đang chạy thật, phía sau là cả một đội máy và lịch sử nằm trên đĩa. Tôi đọc thế này: hãy coi kết quả 180 MB là mức sàn, không phải mục tiêu để chọn cấu hình. Ngay khi bạn thu thập từ nhiều host và giữ lịch sử, hãy chừa dư địa thay vì lên kế hoạch theo con số lúc rảnh đó.

Đĩa là nửa dễ. Tài liệu về lưu trữ của Prometheus đặt mức trung bình 1 đến 2 byte cho mỗi mẫu, nên giữ lịch sử dài cho một hệ thống nhỏ rất rẻ. Cái bẫy nằm ở giá trị mặc định: thời gian lưu trữ mặc định là 15 ngày trừ khi bạn đặt thời gian lưu trữ hoặc dung lượng lưu trữ. Chỉ một cờ khởi động là biến nó thành một năm, và đây đúng là loại giá trị mặc định mà bạn nên biết ngay bây giờ, thay vì biết vào lần đầu tiên đi tìm số liệu tháng trước rồi phát hiện chúng đã hết hạn từ ba tuần trước.

Thứ đẩy con số bộ nhớ lên cao là số lượng chuỗi khác nhau, tức là mỗi tổ hợp nhãn duy nhất trên một chỉ số lại trở thành một chuỗi riêng. Một nhãn chọn sai trên một chỉ số có lưu lượng lớn có thể tạo ra nhiều chuỗi hơn cả năm máy chủ cộng lại, và nó làm điều đó một cách lặng lẽ, đúng theo nhịp lưu lượng của bạn. (Một ID người dùng hay một đường dẫn request trông như một nhãn tuyệt vời, cho đến khi bạn đếm xem có bao nhiêu giá trị.)

Bất kỳ con số RAM nào bạn thấy người ta dẫn ra cho Prometheus cũng chỉ dùng được nếu bạn biết luôn có bao nhiêu chuỗi đứng sau nó.

Chuyện gì xảy ra khi máy chủ Prometheus của bạn sập?

Chính tài liệu về lưu trữ của Prometheus nói thẳng chuyện này: bộ lưu trữ cục bộ không được phân cụm và không được nhân bản, nên nó không trụ nổi trước sự cố ổ đĩa hay sự cố node. Mỗi máy chủ độc lập theo thiết kế và không phụ thuộc vào bộ lưu trữ mạng hay dịch vụ từ xa, và đó chính xác là thứ khiến nó dễ vận hành, đồng thời cũng chính xác là thứ khiến nó phơi ra trước rủi ro.

At solo scale that turns into two problems. If the box holding Prometheus dies, new alert evaluations stop, and your history goes with it unless you were taking TSDB snapshots and managing it like the single-node database it is, taking TSDB snapshots and copying them somewhere else. And if that box is also one of the machines being monitored, which on a one-server setup it inevitably is, then the thing that tells you something broke is the same thing that broke. (Yes, that's about as useful as it sounds.)

Còn một ranh giới thứ hai mà chính dự án tự nói về mình, và họ xứng đáng được ghi nhận vì đã nói ra: nếu bạn cần độ chính xác 100%, chẳng hạn để tính tiền theo từng request, tài liệu nói rằng Prometheus là lựa chọn sai, bởi dữ liệu nó thu thập nhiều khả năng sẽ không đủ chi tiết và đủ đầy đủ. Hãy dùng thứ khác cho những con số bạn xuất hóa đơn, và để Prometheus cho việc giám sát. Các nhà cung cấp thường không tự nguyện nói kiểu đó về chính mình.

Ở quy mô lớn hơn đã có những lời giải quen thuộc cho chuyện này, và chúng nằm ngoài phạm vi bài viết vì cùng một lý do với bộ công cụ Kubernetes: đó là một mức cam kết vận hành khác với mức mà bài đánh giá này bàn tới. Với một VPS duy nhất, tôi đọc rằng rủi ro này chấp nhận được nếu bạn giữ snapshot TSDB ở nơi khác hoặc chấp nhận trước rằng sẽ mất lịch sử, và nó là vấn đề thật sự nếu Prometheus là thứ duy nhất đứng giữa bạn và một sự cố âm thầm.

Ai nên tự vận hành Prometheus?

Dấu hiệu rõ nhất cho thấy Prometheus sẽ trả lại đủ những gì nó lấy đi chẳng liên quan gì đến chuyện bạn có bao nhiêu máy chủ. Nó nằm ở chỗ sáu tháng nữa có còn đúng những máy chủ ấy không. Một tập host cấu hình thủ công và ổn định nghĩa là bạn viết cấu hình một lần rồi thu lịch sử miễn phí; một tập cứ thay đổi liên tục nghĩa là bạn cứ phải động vào cấu hình đó liên tục.

Trong một hệ thống tĩnh, cấu hình Prometheus và Grafana của bạn chính là bản mô tả tường minh về hạ tầng: các target thu thập, các nhãn gắn vào chúng, và những bảng điều khiển dựng trên các nhãn ấy. Đó là lý do toàn bộ phần thưởng nằm ở lịch sử. Một năm dữ liệu trên một tập host ổn định cho bạn biết bình thường trông ra sao, và đó là cách đáng tin cậy nhất để nhận ra bất thường trước khi nó thành sự cố.

Vậy nên nhóm đầu tiên là người đang chạy một tập máy chủ nhỏ, thay đổi chậm, và muốn nhiều hơn chuyện sống hay chết: độ trễ request theo thời gian, xu hướng bộ nhớ, một ổ đĩa đầy dần đủ chậm để bạn thấy trước hàng tuần. Nếu hôm nay bạn mô tả được hạ tầng của mình và tin rằng một năm nữa bản mô tả đó vẫn đúng đại thể, thì buổi tối bạn bỏ ra để cài đặt là hóa đơn lớn cuối cùng.

Nhóm thứ hai là bất kỳ ai học bộ công cụ này một cách có chủ đích. Nếu bạn nghĩ vài năm nữa mình vẫn đang vận hành hạ tầng, của mình hay của người khác, thì buổi tối với PromQL chính là thứ bạn đến vì nó, còn giám sát chỉ là hệ quả phụ. Nhóm này đảo ngược một phần nhóm đầu: phép thử về sự ổn định ở đây ít quan trọng hơn, bởi thời gian bỏ ra để gán lại nhãn cũng chính là thời gian học xem gán lại nhãn là gì. Với người đọc này tôi sẽ nâng điểm lên.

Nhóm thứ ba là chuyện quyền sở hữu, và đây là điều người ta đánh giá thấp cho tới khi từng đứng ở phía sai. Prometheus không tính tiền theo host, theo chỉ số hay theo nhãn, và không có trang bảng giá nào có thể đổi dưới chân bạn vào quý sau. Cái được và mất so với một dịch vụ có quản lý như Datadog là thế này: bạn từ bỏ sự mượt mà, hợp đồng hỗ trợ và ca trực của người khác, đổi lại bạn có những chỉ số thuộc về mình trên một hóa đơn không nhúc nhích khi một lập trình viên thêm đo đạc. Đó có phải cuộc đổi chác tốt hay không thì tùy vào giờ công của chính bạn đáng giá bao nhiêu, và chỉ bạn mới điền được con số ấy (và nó hiếm khi bằng không, kể cả khi cảm giác là vậy).

Một điều nên biết trước khi bạn quyết: vượt quá sức chứa của bộ lưu trữ cục bộ trong Prometheus không phải ngõ cụt. VictoriaMetrics chấp nhận remote write từ Prometheus, và MetricsQL tương thích ngược với PromQL, nên phần lớn truy vấn và bảng điều khiển Grafana bạn dựng bây giờ sẽ sống sót qua lần chuyển đổi. Đây là một cuộc di trú, không phải viết lại.

Đáng để xem lại mỗi năm một lần thay vì quyết một lần cho xong: hệ thống hôm nay giám sát rẻ sẽ trở nên đắt vào đúng cái quý bạn bắt đầu xây lại nó.

Xây dựng trên VPS Linux với quyền root, NVMe và sức mạnh AMD EPYC.

Xem các gói Linux

Ai nên bỏ qua Prometheus?

Nếu câu bạn dùng để mô tả nhu cầu của mình là “báo tôi biết khi trang web sập”, thì thứ bạn đang mô tả là một công cụ kiểm tra tình trạng hoạt động, và Prometheus là quá nhiều bộ máy để đi tới câu trả lời đó. Uptime Kuma làm đúng công việc ấy bằng một giao diện web và không bắt bạn phải học một ngôn ngữ truy vấn giám sát. Khoảng cách năng lực giữa hai công cụ là rất lớn, nhưng hoàn toàn không liên quan gì đến công việc bạn đang thuê chúng làm.

Người đọc thứ hai là người muốn có biểu đồ dùng được ngay mà không phải học một ngôn ngữ truy vấn trước. Netdata được xây đúng quanh chuyện đó: chỉ số theo từng host mà bạn xem được ngay lập tức, với ít cấu hình hơn hẳn và không có gì chắn giữa bạn với các biểu đồ. Nếu câu hỏi bạn cứ lặp đi lặp lại là “sao cái máy này giờ chậm thế”, thì đó là con đường ngắn hơn nhiều để tới câu trả lời.

Nhóm thứ ba là bất kỳ ai có hạ tầng thay hình đổi dạng thường xuyên mà lại quản lý target và biến của bảng điều khiển bằng tay. Host dựng lên dùng một tuần rồi hủy, target bị đổi tên, dự án đổi tên giữa chừng. Đó chính là trường hợp bạn trả cái giá cấu hình hết lần này đến lần khác trong khi thu về ít nhất từ chính thứ bạn bỏ tiền ra mua, tức là lịch sử liên tục của một hệ thống vẫn còn nhận ra được.

Không điều nào ở trên là lời chê bai công cụ này. “Bỏ qua” ở đây nghĩa là bỏ qua cho công việc này, ở quy mô này. Ở quy mô Kubernetes, nơi service discovery lo hầu hết những thứ mà nếu không thì bạn phải đấu nối bằng tay, vài khoản chi phí kể trên teo lại hoặc biến mất hẳn, và tôi đọc quy mô đó là chỗ rất khó đánh bại Prometheus. Nhưng đó là một bài đánh giá khác.

Đọc

Thiết lập bộ giám sát Grafana + Prometheus trên VPS của bạn (hướng dẫn Docker Compose)

Câu hỏi thường gặp