Prometheus trong phòng thí nghiệm kiểm định: đo, cảnh báo và truy vết số liệu môi trường
Đăng ngày 12/10/2026
Mục lục bài nghiên cứu
Prometheus là gì, và khi nào một phòng thí nghiệm nên dùng nó
Prometheus là hệ thống giám sát dịch vụ và hạ tầng, thuộc Cloud Native Computing Foundation. Theo README, nó thu thập số đo (metrics) từ các đích cấu hình sẵn theo chu kỳ, đánh giá các biểu thức luật, hiển thị kết quả và có thể phát cảnh báo khi điều kiện xảy ra [1]. Với một phòng thí nghiệm kiểm định chất lượng, giá trị thực tế nằm ở chỗ biến những đại lượng như nhiệt độ buồng thử, độ ẩm, trạng thái máy chủ phần mềm quản lý mẫu thành chuỗi thời gian có nhãn, rồi báo cho người trực khi chúng đi lệch.
Bài này là nghiên cứu bàn giấy cho một tình huống giả định. Khuyến nghị gọn: nên cân nhắc Prometheus nếu phòng thí nghiệm có người đủ kỹ năng vận hành một dịch vụ Linux, có các thiết bị hoặc phần mềm phơi được số đo qua HTTP, và chấp nhận dùng nó như công cụ cảnh báo vận hành cùng phân tích xu hướng. Chưa nên coi nó là hệ thống hồ sơ chất lượng chính thức, vì tài liệu lưu trữ của dự án nói rõ bộ nhớ cục bộ không có cụm hay bản sao, và định dạng đĩa chính xác không nằm trong cam kết ổn định [5][9].
Không nên chọn Prometheus nếu nhu cầu thật chỉ là một bảng ghi nhiệt độ thủ công được ký duyệt hằng ngày, hoặc nếu không ai nhận trách nhiệm trực cảnh báo.
Khi nhiệt độ buồng thử lệch lúc không ai đứng gần
Phòng thí nghiệm kiểm định thường có những điều kiện phải giữ ổn định trong một khoảng: buồng ổn nhiệt, tủ bảo quản mẫu, phòng cân, máy điều hòa chính xác. Sự cố hiếm khi xảy ra giữa giờ làm việc khi có người nhìn đồng hồ. Nó xảy ra ban đêm, cuối tuần, hoặc ngay sau một lần mất điện ngắn, và thường chỉ được phát hiện khi kỹ thuật viên mở cửa buồng vào sáng hôm sau.
Cách làm phổ biến là đọc số trên màn hình thiết bị hoặc ghi tay theo ca. Nhu cầu thực sự gồm ba việc: có một chuỗi đo dày hơn mắt người, có cảnh báo khi vượt ngưỡng kéo dài, và có cách truy lại sau sự cố xem điều kiện thay đổi thế nào.
Prometheus nhắm đúng lớp bài toán này nhưng ở góc nhìn hệ thống. Tài liệu mô tả mô hình dữ liệu nhiều chiều, trong đó chuỗi thời gian được xác định bằng tên số đo và tập cặp khóa-giá trị, cộng với ngôn ngữ truy vấn PromQL để khai thác các chiều đó [1].
Máy chủ Prometheus nhìn từ bên trong: các quản lý viên chạy song song
Tài liệu kiến trúc nội bộ mô tả máy chủ là tập hợp nhiều thành phần phối hợp. Hàm main đọc cờ dòng lệnh, khởi tạo các thành phần chính rồi chạy chúng theo mô hình giống actor, có cơ chế điều phối khởi động và tắt có thứ tự [3].
Các thành phần chính gồm bộ quản lý khám phá dịch vụ, bộ quản lý thu thập (scrape manager) với mỗi mục scrape_config tương ứng một nhóm thu thập, kho lưu trữ, bộ máy PromQL, bộ quản lý luật và bộ thông báo gửi cảnh báo tới Alertmanager [3]. Cần nhớ tài liệu ghi rõ phần giải thích dựa trên phiên bản 2.3.1, nên chi tiết triển khai có thể đã khác; ở đây chỉ dùng nó cho hình dung khái niệm [3].
Với phòng thí nghiệm nhỏ, kiến trúc đề xuất là một máy chủ Prometheus duy nhất đặt trong mạng nội bộ, cùng Alertmanager và một công cụ vẽ biểu đồ. README nêu rằng các nút đơn là tự chủ và không phụ thuộc lưu trữ phân tán [1].
Từ cảm biến tới tin nhắn trực ca: đường đi của một con số
Luồng bắt đầu bằng khám phá đích. Theo tài liệu, các đích được tìm qua service discovery hoặc cấu hình tĩnh, rồi chuyển cho bộ thu thập qua kênh đồng bộ [1][3]. Mỗi đích được đặt nhãn mặc định như job và instance, rồi qua bước relabeling để ra danh sách cuối cùng [3].
Sau đó vòng thu thập kéo dữ liệu qua HTTP theo chu kỳ, giải mã định dạng văn bản của Prometheus, áp dụng relabeling cho từng mẫu và đẩy vào kho lưu trữ [3]. Cảm biến của phòng thí nghiệm thường không nói sẵn định dạng này, nên cần một lớp trung gian phơi số đo qua HTTP. Các tài liệu đã đọc không liệt kê bộ chuyển đổi cụ thể nào cho thiết bị đo, vì vậy đó là phần việc phải tự khảo sát hoặc tự viết.
Mẫu được ghi vào cơ sở dữ liệu chuỗi thời gian cục bộ. Bộ quản lý luật định kỳ chạy các luật ghi và luật cảnh báo, lưu chuỗi ALERTS cho cảnh báo đang chờ hoặc đang kích hoạt, theo dõi chuyển trạng thái giữa pending và firing theo mệnh đề for, rồi chuyển cảnh báo cho bộ thông báo; cảnh báo đã giải quyết vẫn được gửi tiếp 15 phút [3].
Những gì tài liệu xác nhận Prometheus làm được
README liệt kê các đặc điểm phân biệt: mô hình dữ liệu nhiều chiều, ngôn ngữ truy vấn PromQL, nút đơn tự chủ, mô hình kéo qua HTTP, hỗ trợ đẩy qua cổng trung gian cho tác vụ theo lô, khám phá đích bằng service discovery hoặc cấu hình tĩnh, nhiều chế độ vẽ biểu đồ và hỗ trợ federation phân cấp lẫn ngang [1].
Về cảnh báo, tài liệu luật mô tả cấu trúc cụ thể: biểu thức expr, mệnh đề for để chờ trước khi chuyển sang firing, keep_firing_for để giữ cảnh báo thêm một khoảng sau lần cuối điều kiện đúng nhằm tránh cảnh báo chập chờn, cùng nhãn và chú thích có thể dùng mẫu template [6]. Với buồng thử, một luật như nhiệt độ ngoài khoảng cho phép liên tục năm phút là kiểu điều kiện hợp lý, còn con số năm phút cần được phòng thí nghiệm tự xác định từ quy trình của mình.
Về lưu trữ, dữ liệu được gom thành khối hai giờ, có tệp chỉ mục và tệp metadata, mẫu hiện tại nằm trong bộ nhớ và được bảo vệ bằng write-ahead log để phát lại khi khởi động lại [5]. Thời gian giữ mặc định là 15 ngày nếu không đặt cờ khác, và xóa series qua API chỉ ghi tombstone thay vì gỡ ngay khỏi tệp [5].
Phòng nào trong tổ chức nên tự nhận việc này
Đối tượng sát nhất là nhóm có người kiêm nhiệm hạ tầng và hiểu bản chất dữ liệu đo. Trong một phòng thí nghiệm kiểm định, đó có thể là trưởng bộ phận thiết bị phối hợp với một kỹ sư hệ thống. Người đầu hiểu khoảng điều kiện nào là chấp nhận được; người sau biết cách đặt dịch vụ, cấp quyền mạng và sao lưu.
Prometheus phù hợp với số đo dạng số có nhãn, lấy mẫu theo chu kỳ: nhiệt độ, độ ẩm, điện áp UPS, mức đầy ổ đĩa, thời gian phản hồi của phần mềm quản lý mẫu. Nó kém phù hợp với dữ liệu sự kiện rời rạc có nội dung dài như biên bản thử nghiệm hay hình ảnh mẫu.
Bài không dẫn tên đơn vị nào đã áp dụng vì các nguồn đã đọc không có thông tin đó.
Giả định: phòng kiểm định vật liệu xây dựng ở Đà Nẵng giám sát buồng dưỡng hộ và máy chủ LIMS
Tình huống giả định, chưa từng được triển khai thật: một phòng thí nghiệm kiểm định vật liệu xây dựng quy mô vừa tại Đà Nẵng có hai buồng dưỡng hộ mẫu bê tông, một tủ bảo quản mẫu nhạy nhiệt, phòng cân, và một máy chủ chạy phần mềm quản lý thông tin phòng thí nghiệm. Hiện kỹ thuật viên ghi nhiệt độ và độ ẩm vào sổ ba lần mỗi ngày. Sự cố giả định là máy điều hòa tắt đêm thứ Sáu do nhảy aptomat, đến sáng thứ Hai mới phát hiện.
Đề xuất: đặt một máy Prometheus trong mạng nội bộ, kèm bộ chuyển đổi đọc cảm biến và phơi số đo qua HTTP. Nhãn theo thiết bị và khu vực, ví dụ buồng một, buồng hai, phòng cân. Luật cảnh báo dùng mệnh đề for để lọc dao động ngắn khi mở cửa buồng, và keep_firing_for để cảnh báo không tắt rồi bật liên tục quanh ngưỡng [6]. Cảnh báo tới người trực qua Alertmanager, kênh cụ thể do phòng chọn.
Điểm mấu chốt là ranh giới trách nhiệm. Số liệu Prometheus dùng để phát hiện sớm và xem xu hướng, còn hồ sơ chất lượng chính thức vẫn theo quy trình riêng của phòng và yêu cầu của tổ chức công nhận mà họ đăng ký. Bài không khẳng định Prometheus đáp ứng bất kỳ tiêu chuẩn công nhận nào. Nếu phòng muốn dùng số liệu làm bằng chứng, phải đánh giá thêm về hiệu chuẩn cảm biến, đồng bộ giờ, toàn vẹn và thời hạn lưu giữ, nằm ngoài phạm vi các tệp đã đọc.
Vận hành một máy Prometheus: đĩa, nạp lại cấu hình và bản sao lưu
Tài liệu lưu trữ nêu các cờ chính: đường dẫn dữ liệu, thời gian giữ, giới hạn dung lượng, và nén WAL. Nếu không đặt cờ thời gian lẫn dung lượng thì mặc định giữ 15 ngày; nếu đặt cả hai, điều kiện nào đến trước sẽ áp dụng [5]. Một phòng cần xem lại xu hướng theo quý sẽ phải đổi giá trị mặc định này một cách có chủ ý, rồi tính lại ổ đĩa.
Tài liệu cung cấp công thức ước tính: dung lượng cần bằng thời gian giữ tính bằng giây nhân số mẫu nạp mỗi giây nhân số byte mỗi mẫu, với mức trung bình dự án nêu là 1 đến 2 byte mỗi mẫu [5]. Khuyến nghị đặt giới hạn dung lượng ở mức tối đa 80 đến 85 phần trăm ổ cấp phát, vì quá trình nén khối cần chỗ cho cả khối nguồn lẫn khối mới [5]. Tài liệu cũng cảnh báo hệ thống tệp không tuân thủ POSIX, kể cả NFS, không được hỗ trợ cho lưu trữ cục bộ [5].
Về sao lưu, tài liệu khuyến nghị dùng snapshot qua API; sao lưu thô có nguy cơ mất dữ liệu ghi sau khối gần nhất, và bỏ qua các thư mục WAL sẽ cho bản sao nhất quán nhưng mất khoảng thời gian chúng bao phủ [5]. Việc nạp lại cấu hình qua tín hiệu HUP cho phép chỉnh ngưỡng mà không dừng thu thập [3].
Chế độ Agent: một tệp nhị phân, hai vai trò
Prometheus có một chế độ vận hành trong cùng tệp nhị phân, gọi là Agent. Theo tài liệu, chế độ này giữ nguyên cách thu thập, khám phá đích và cấu hình, nhưng tắt TSDB cục bộ, truy vấn, cảnh báo và đánh giá luật, đồng thời tối ưu cho việc thu rồi ghi từ xa (remote write) về nơi khác [7]. Dữ liệu tạm nằm trong WAL riêng và bị xóa sau khi gửi thành công; nếu không tới được đích, nó được giữ tạm trên đĩa với giới hạn khoảng hai giờ [7].
Với phòng thí nghiệm một cơ sở, chế độ này chưa cần. Nó đáng nhắc vì mô hình mở rộng: nếu về sau tổ chức có thêm chi nhánh, mỗi nơi có thể đặt một Agent nhỏ và gửi về điểm trung tâm có truy vấn và cảnh báo. Tài liệu liệt kê rõ cái giá: không truy vấn cục bộ, không luật ghi, không cảnh báo tại chỗ, mọi việc đó phải làm ở hệ thống nhận [7].
Cần nghĩ tới hệ quả an toàn: nếu cảnh báo nhiệt độ chỉ chạy ở điểm trung tâm, mất kết nối mạng giữa chi nhánh và trung tâm có thể làm mất luôn khả năng cảnh báo. Với đại lượng có hậu quả như tủ bảo quản mẫu, nên giữ máy Prometheus đầy đủ ngay tại cơ sở.
Bảo mật: đặt lớp bảo vệ quanh cổng 9090
Giao diện web và API mặc định phục vụ ở cổng 9090 [3], và ví dụ Docker trong README gắn cổng này vào địa chỉ 127.0.0.1 [1]. Khi mở cho nhiều người trong phòng, cần đặt sau mạng nội bộ có kiểm soát hoặc proxy có xác thực.
Prometheus hỗ trợ TLS và xác thực cơ bản qua tệp cấu hình web, nhưng tài liệu ghi rõ tính năng này là thử nghiệm và có thể thay đổi; nó cũng nằm trong danh sách không ổn định của dòng 3.x [8][9]. Vì vậy đừng xem việc bật tính năng này là đủ; cân nhắc lớp bảo vệ ở mạng hoặc reverse proxy.
Chính sách báo lỗ hổng của dự án được dẫn sang trang riêng trên prometheus.io, trang này không nằm trong các tệp đã đọc [4]. Dữ liệu đo môi trường thường không phải dữ liệu cá nhân, nhưng nhãn có thể vô tình chứa tên người vận hành hoặc mã mẫu của khách hàng; nên quy ước nhãn chỉ gồm thiết bị và khu vực.
Giấy phép Apache 2.0 và những gì nó không phủ
LICENSE tại commit đã khóa là văn bản Apache License 2.0, và README cũng ghi dự án dùng giấy phép này [1][2]. Giấy phép cho phép sử dụng, sao chép, sửa đổi và phân phối với các điều kiện như giữ thông báo bản quyền và nêu thay đổi. Nó có điều khoản cấp quyền sáng chế và nói rõ không cấp quyền dùng tên thương mại, nhưng người triển khai nên đọc trực tiếp văn bản thay vì dựa vào tóm tắt này [2].
Cây tài liệu đã liệt kê tại commit này chỉ chứa một tệp LICENSE ở thư mục gốc, nên bài không tìm thấy thư mục mang giấy phép khác trong danh sách đó. Điều đó chưa chứng minh toàn bộ mã nguồn, tệp đi kèm và thư viện phụ thuộc đều theo Apache 2.0.
Giấy phép chỉ áp dụng cho mã tại commit này. Nó không bao trùm bộ chuyển đổi của bên thứ ba, Alertmanager hay công cụ vẽ biểu đồ dùng kèm, dịch vụ lưu trữ từ xa, dữ liệu của phòng thí nghiệm hay dịch vụ thương mại của nhà cung cấp khác. Các tệp đã đọc không nói gì về CLA hay chính sách thương hiệu, nên bài không kết luận về hai điểm này.
Chi phí: chủ yếu là thời gian của người biết hệ thống
Không có phí bản quyền trong phạm vi giấy phép đã đọc, nhưng chi phí thật nằm ở nguồn lực. Loại nguồn lực thứ nhất là con người: một người thiết kế nhãn và luật cảnh báo cùng chuyên môn đo lường, một người dựng và duy trì dịch vụ, cộng thời gian trực cảnh báo. Với đội nhỏ, chi phí vận hành thường lớn hơn chi phí máy chủ.
Loại thứ hai là phần cứng: một máy chủ hoặc máy ảo cỡ nhỏ có đĩa cục bộ, nguồn điện dự phòng cho máy giám sát, và thiết bị đọc cảm biến. Dung lượng đĩa ước theo công thức trong tài liệu, từ số chuỗi, chu kỳ thu thập và thời gian giữ [5]. Bài không đưa giá tiền vì giá thay đổi theo thời điểm và nhà cung cấp.
Loại thứ ba là chi phí gián tiếp: thời gian viết bộ chuyển đổi cho thiết bị đo không nói được định dạng Prometheus, đào tạo người trực, và việc rà soát định kỳ ngưỡng cảnh báo. Giả định của bài là một cơ sở, vài chục đích, một người kiêm nhiệm.
So với các cách giám sát khác ở mức tiếp cận
Cách thứ nhất là bộ ghi dữ liệu kèm phần mềm của chính hãng thiết bị. Mỗi hãng thường có một giao diện riêng, nên khó gộp chung và khó viết luật cảnh báo xuyên thiết bị. Prometheus cho cái nhìn thống nhất nhưng đòi hỏi tự lo tích hợp và chịu trách nhiệm vận hành.
Cách thứ hai là dịch vụ giám sát dạng thuê (SaaS). Nó giảm gánh nặng vận hành nhưng đưa dữ liệu ra ngoài và gắn với một nhà cung cấp. Có thể kết hợp: chế độ ghi từ xa của Prometheus cho phép gửi một phần số liệu sang hệ thống tương thích, nhưng khi đó cần xem xét kỹ độ bền và hiệu năng của hệ thống nhận, như tài liệu lưu trữ đã cảnh báo [5][7].
Cách thứ ba là công cụ kiểm tra dịch vụ đơn giản chỉ trả lời còn sống hay không, phù hợp nếu bạn chỉ cần biết máy chủ có lên hay không. Với cảnh báo dựa trên giá trị đo và xu hướng thì nó thiếu chiều sâu.
Những điều kiện không nên dùng Prometheus
Giới hạn lớn nhất do chính tài liệu nêu: bộ nhớ cục bộ không phân cụm hay nhân bản, nên không có khả năng mở rộng tùy ý hay chịu được hỏng ổ đĩa và nút; cần quản lý như một cơ sở dữ liệu một nút [5]. Phòng thí nghiệm không thể chấp nhận mất chuỗi đo trong thời gian dài cần kế hoạch sao lưu và, nếu cần, lưu trữ từ xa đã được đánh giá.
Thứ hai, không phải mọi tính năng đều ổn định. Tài liệu ổn định liệt kê HTTPS cùng xác thực cơ bản phía máy chủ, remote read, nhiều tích hợp khám phá dịch vụ, và định dạng đĩa chính xác là thuộc nhóm không đảm bảo [9]. Tài liệu cho rằng nâng cấp trong cùng dòng chính thường ít rủi ro nếu không dùng tính năng thử nghiệm, và thay đổi phá vỡ được đánh dấu CHANGE trong ghi chú phát hành [9].
Thứ ba, README nói kho mã này dựng một chương trình độc lập và không được thiết kế làm thư viện Go, dù nhiều người vẫn dùng một phần theo cách đó [1]. Nếu nhóm định nhúng mã Prometheus vào sản phẩm riêng, họ sẽ phải theo dõi thay đổi API nội bộ.
Kế hoạch thử nghiệm sáu tuần, có tiêu chí thoát
Giai đoạn một, tuần một đến hai: chọn đúng hai buồng và một máy chủ làm phạm vi. Xác định danh sách nhãn, khoảng điều kiện chấp nhận do trưởng phòng ký xác nhận, và phương án đọc cảm biến. Tiêu chí thoát giai đoạn: mỗi đích đều trả về số đo kiểm tra được bằng thiết bị đối chứng trong sai số phòng đặt ra, và mọi chuỗi có nhãn theo quy ước.
Giai đoạn hai, tuần ba đến bốn: bật luật cảnh báo ở chế độ chỉ báo cho một người, song song với sổ ghi tay. Đo ba chỉ số: số cảnh báo giả, số sự kiện thật bị bỏ sót khi so với sổ tay hay quan sát, và thời gian từ lúc lệch tới lúc có người xác nhận. Ngưỡng chấp nhận do phòng đặt trước khi chạy, ví dụ không bỏ sót sự kiện nào trong phạm vi hai buồng. Điều chỉnh mệnh đề for và keep_firing_for theo kết quả [6].
Giai đoạn ba, tuần năm đến sáu: kiểm tra phục hồi và vận hành. Thực hiện snapshot theo hướng dẫn, khôi phục lên máy khác, tắt giả lập một thiết bị để xem cảnh báo, kiểm tra cảnh báo khi mạng gián đoạn [5]. Tiêu chí dừng: nếu bộ chuyển đổi cần bảo trì quá sức đội, hoặc cảnh báo giả vẫn làm người trực bỏ qua thông báo, thì dừng và quay lại phương án cũ. Mọi con số tiêu chí ở đây là đề xuất của bài, không phải kết quả đã đo.
Kết luận: dùng như đèn cảnh báo có trí nhớ, chưa phải hồ sơ pháp lý
Nghiên cứu bàn giấy cho thấy Prometheus có kiến trúc rõ ràng cho việc thu số đo theo chu kỳ, lưu cục bộ, đánh giá luật và phát cảnh báo [1][3]. Nó phù hợp với phòng thí nghiệm có khả năng vận hành dịch vụ và có người chịu trách nhiệm với ngưỡng điều kiện.
Điều kiện đi kèm là giữ vai trò của nó đúng chỗ. Nó giúp phát hiện sớm và xem xu hướng, còn việc xác nhận tính hợp lệ của dữ liệu như bằng chứng chất lượng phải tuân theo quy trình và yêu cầu riêng của phòng.
Nếu một tổ chức muốn xây hệ thống tri thức nội bộ hay trang nghiên cứu kiểu phamvanthu.com, số liệu vận hành từ Prometheus cũng có thể là một nguồn để rút bài học, miễn là phân biệt rõ dữ liệu đo và nhận định.
Nguồn và phương pháp
Bài thuộc nhóm Hạ tầng và vận hành, được chọn từ kho lưu trữ GitHub Trending do cộng đồng bonfy lưu. Theo tệp ứng viên, Prometheus xuất hiện 26 lần từ 2026-01-07 đến 2026-09-27; bằng chứng đầu tiên là trang lưu ngày 2026-01-07 [10]. Kho lưu này chỉ phủ các danh sách Python, Go, JavaScript và Swift, thiếu ngày 2026-09-03 và 2026-10-12, và không phải bảng xếp hạng top 100 chính thức.
Mã nguồn được khóa tại commit fffc15f5b5a6c3ed50282d307e96db0e5f25bcb2, ngày 2026-10-11, kiểm tra ngày 2026-10-12. Bản phát hành mới nhất trong dữ liệu thu thập là v3.15.0, đăng 2026-09-25; số phiên bản này không có trong tài liệu được trích dẫn. Các tệp đã đọc gồm README, LICENSE, tài liệu kiến trúc nội bộ, SECURITY, và bốn tài liệu bổ sung về lưu trữ, luật cảnh báo, chế độ Agent, HTTPS cùng ổn định API [1][2][3][4][5][6][7][8][9].
Đây là nghiên cứu bàn giấy, không phải công trình khoa học đã bình duyệt. Bài không cài đặt, chạy hay đo hiệu năng phần mềm; tình huống Việt Nam là đề xuất giả định. Các nhận định về điều kiện áp dụng, chi phí và kế hoạch thử nghiệm là phân tích của người viết.
Xem mã nguồn Prometheus trên GitHub