Mở đầu — vì sao bài này quan trọng
Hãy tưởng tượng bạn là QA của một sàn thương mại điện tử. Đêm hôm qua, đội backend deploy một bản vá nhỏ lên production lúc 2 giờ sáng. Không ai chạy test. Đến 8 giờ sáng, khi khách hàng bắt đầu vào giỏ hàng, API GET /cart trả về lỗi 500 hàng loạt. Từ 2 giờ đến 8 giờ là sáu tiếng "chảy máu" doanh thu mà không ai biết. Nếu có một cỗ máy tự động gọi API mỗi 15 phút và nhắn tin cho bạn ngay khi nó thấy 500, bạn đã phát hiện sự cố lúc 2 giờ 15 phút thay vì để khách hàng phát hiện hộ mình.
Đó chính xác là công việc của Postman Monitors. Cho tới giờ, bạn đã biết chạy collection thủ công (bấm Run), chạy tự động trong CI/CD qua Newman, và chạy theo lịch trên máy chủ riêng. Monitors lấp một khoảng trống rất cụ thể: chạy collection theo lịch, ngay trên hạ tầng cloud của Postman, mà bạn không cần dựng CI server, không cần cron, không cần một máy nào bật 24/7. Bạn cấu hình vài phút trên giao diện, và Postman sẽ tự chạy, tự lưu lịch sử, tự cảnh báo khi hỏng.
Bài này tập trung hoàn toàn vào Monitors — cái nhìn theo lịch, chạy trên cloud của Postman. Nó khác với Newman trong CI/CD (chạy khi có commit, do bạn tự host), và khác với Postman Flows (dựng workflow trực quan). Ở đây, câu chuyện là "chạy đều đặn theo đồng hồ để giám sát sức khỏe API".
Khái niệm cốt lõi
Monitor là gì
Một Monitor là một cấu hình gắn với một collection và (thường là) một environment, kèm theo một lịch chạy. Postman lưu monitor này trên cloud của họ; đến giờ hẹn, hệ thống của Postman tự lấy collection đó, chạy toàn bộ request và test scripts giống hệt như khi bạn bấm Run, rồi lưu lại kết quả: request nào đậu, request nào rớt, thời gian phản hồi bao nhiêu, response trả về gì.
Điểm mấu chốt để hiểu đúng: monitor chạy trên máy chủ của Postman, không phải trên máy bạn. Máy tính của bạn có tắt, có mất mạng thì monitor vẫn chạy. Đây là ưu và cũng là nhược điểm: ưu vì bạn không cần hạ tầng riêng; nhược vì máy chủ Postman nằm ngoài mạng nội bộ công ty bạn, nên nó không thể gọi tới các API chỉ truy cập được trong VPN hay localhost (ta sẽ nói kỹ ở phần lỗi thường gặp).
Ba trụ cột của một monitor
Một monitor có ba thành phần bạn cần nắm:
- Collection: tập request + test mà monitor sẽ chạy. Toàn bộ giá trị của monitor phụ thuộc vào chất lượng test scripts trong collection. Nếu collection chỉ gửi request mà không có
pm.test(...)kiểm tra, monitor sẽ luôn báo "pass" kể cả khi API trả rác — vì với monitor, "pass" nghĩa là "không có assertion nào fail và không có lỗi mạng", chứ không phải "API hoạt động đúng". - Environment: bộ biến để monitor biết gọi vào đâu (
base_url), với token nào. Monitor thường gắn với một environment cụ thể như Production hay Staging. - Schedule: lịch chạy. Có thể theo tần suất định sẵn (mỗi 5 phút, 15 phút, 30 phút, 1 giờ, mỗi ngày, mỗi tuần) hoặc theo biểu thức cron tùy chỉnh. Kèm theo là múi giờ — rất quan trọng với ta ở Việt Nam, sẽ nói rõ bên dưới.
Kết quả và cảnh báo
Mỗi lần chạy (gọi là một run), monitor sinh ra một bản ghi trong dashboard: tổng số request, số test đậu/rớt, độ trễ trung bình, và log chi tiết. Postman giữ lịch sử này nên bạn có thể nhìn biểu đồ thời gian phản hồi theo tuần, phát hiện xu hướng API chậm dần.
Khi một run có test fail (hoặc có request lỗi), monitor có thể gửi email cảnh báo tới người bạn chỉ định. Ngoài ra Postman cho phép cấu hình để ngừng spam: ví dụ chỉ báo khi fail và im lặng khi lại pass, hoặc chỉ báo lại sau một số lần fail liên tiếp.
Giới hạn tài nguyên (quan trọng về chi phí)
Postman tính monitor bằng đơn vị monitoring hours hoặc số lần chạy theo gói tài khoản. Gói miễn phí có một hạn mức nhất định mỗi tháng (ví dụ khoảng 1.000 lượt gọi request qua monitor, con số này Postman thay đổi theo thời gian — hãy kiểm tra bảng giá hiện hành). Điều này dẫn tới một phép tính rất thực tế: nếu collection của bạn có 20 request và bạn hẹn chạy mỗi 5 phút, thì mỗi ngày là 20 × 12 × 24 = 5.760 lượt request. Chạy như vậy, hạn mức miễn phí sẽ cạn trong chưa tới một ngày. Vậy nên tần suất và số request phải được cân nhắc như một khoản ngân sách.
Tình huống thực tế
Ví dụ 1 — Sàn TMĐT giám sát "hô hấp" của production
Công ty Chợ Tốt (giả định bối cảnh) có một API critical: POST /search và GET /listing/{id}. Nếu hai endpoint này chết, người dùng không tìm được sản phẩm, coi như sập cửa hàng. Đội QA tạo một collection gọn tên là Health Check — Prod, chỉ gồm 4 request thiết yếu: login lấy token, search một từ khóa phổ biến, mở một listing, và gọi GET /health. Mỗi request có test kiểm pm.response.to.have.status(200) và kiểm response time dưới 800ms.
Họ tạo monitor Chợ Tốt Prod Heartbeat, gắn environment Production, hẹn chạy mỗi 5 phút, múi giờ Asia/Ho_Chi_Minh. Cảnh báo gửi vào email đội trực và (qua tích hợp) vào một kênh Slack #alerts-prod.
Một sáng thứ Bảy, monitor phát hiện POST /search trả 503 do một node Elasticsearch quá tải. Cảnh báo bắn vào Slack lúc 6 giờ 05, kỹ sư trực restart node lúc 6 giờ 20, người dùng gần như không cảm nhận được sự cố. Bài học: monitor giá trị nhất khi nó nhỏ gọn, chỉ gồm các endpoint sống-còn, chạy dày, và nối thẳng vào kênh mà con người thực sự đang nhìn.
Ví dụ 2 — Startup fintech giám sát tính đúng đắn, không chỉ tình trạng "sống"
Một startup ví điện tử ở TP.HCM (gọi là PayZen) không chỉ muốn biết API còn sống, mà muốn biết nó trả đúng dữ liệu. Họ có endpoint GET /wallet/balance phải luôn trả về số dư dạng số nguyên (đơn vị đồng, không có phần thập phân), và tỉ giá quy đổi điểm thưởng phải nằm trong khoảng hợp lệ.
Collection monitor của họ vì thế có test sâu hơn: kiểm schema JSON của response, kiểm pm.expect(balance).to.be.a('number'), kiểm balance % 1 === 0, kiểm rewardRate nằm trong [0.9, 1.1]. Họ hẹn monitor chạy mỗi 30 phút — không cần dày như sàn TMĐT vì đây là kiểm tính đúng đắn dữ liệu, ít biến động hơn.
Một lần, sau khi backend nâng cấp thư viện, balance bỗng trả về dạng chuỗi "150000" thay vì số 150000. HTTP status vẫn 200, một monitor "chỉ check status" sẽ mù tịt. Nhưng test schema của PayZen fail ngay, cảnh báo bắn ra, đội sửa trước khi app mobile (vốn parse số) gặp crash hàng loạt. Bài học: monitor chỉ mạnh bằng test scripts của nó. "Pass" của monitor = "assertion không fail", nên hãy viết assertion phản ánh đúng kỳ vọng nghiệp vụ.
Ví dụ 3 — Đội API cổng thanh toán và bài toán ngân sách monitor
Một team tích hợp cổng thanh toán muốn monitor cả một collection 60 request bao trùm mọi luồng: tạo đơn, thanh toán, hoàn tiền, tra cứu. Ban đầu họ hẹn chạy mỗi 5 phút cho "chắc ăn". Kết quả: hạn mức monitor tháng cạn kiệt trong hai ngày, và họ nhận cả trăm email cảnh báo do vài endpoint sandbox thi thoảng timeout ngẫu nhiên — dẫn tới cảnh báo mệt mỏi (alert fatigue), ai cũng bỏ qua email.
Họ tái cấu trúc: tách làm hai. Một monitor Payment Critical chỉ 5 request cốt lõi, chạy mỗi 5 phút. Một monitor Payment Full Regression đủ 60 request nhưng chỉ chạy 1 lần/ngày lúc 3 giờ sáng. Đồng thời họ bật tùy chọn chỉ cảnh báo sau 2 lần fail liên tiếp, để lọc nhiễu timeout ngẫu nhiên. Ngân sách monitor trở lại trong tầm kiểm soát, và email cảnh báo lại có người đọc. Bài học: phân tầng monitor theo mức độ quan trọng và tần suất; đừng bắt mọi thứ chạy dày như nhau.
Hướng dẫn từng bước
Ta sẽ dựng một monitor giám sát production cho một collection giả định "Shopee Prod Health".
- Chuẩn bị collection dành riêng cho monitor. Đừng dùng lại collection dev khổng lồ. Tạo một collection nhỏ, ví dụ Shopee Prod Health, gồm 3–5 request thiết yếu. Đảm bảo mỗi request có test scripts thực chất (kiểm status, kiểm field quan trọng, kiểm response time). Nhớ rằng nếu request A phụ thuộc token từ request B, hãy đặt request lấy token lên đầu và lưu token vào biến environment trong tab Tests.
- Chuẩn bị environment. Tạo environment Production với
base_url, và các biến cần cho auth. Lưu ý: monitor chạy trên cloud nên các giá trị bí mật phải nằm ở đây (hoặc dùng Vault/biến khởi tạo), không hard-code linh tinh.
- Tạo monitor. Mở collection → bấm menu ba chấm (hoặc tab Monitors) → Create Monitor. Đặt tên rõ ràng, quy ước gợi ý:
<Hệ thống> <Môi trường> <Mục đích>, ví dụShopee Prod Heartbeat.
- Chọn collection và environment. Gắn collection Shopee Prod Health và environment Production.
- Đặt lịch chạy. Chọn tần suất (ví dụ mỗi 15 phút) hoặc nhập cron tùy chỉnh. Quan trọng với người Việt: chọn đúng múi giờ. Nếu bạn muốn chạy "3 giờ sáng giờ Việt Nam", phải chọn timezone Asia/Ho_Chi_Minh (hoặc quy đổi sang UTC: 3 giờ sáng VN = 20:00 UTC hôm trước). Chọn nhầm UTC mà tưởng là giờ VN là lỗi kinh điển.
- Cấu hình cảnh báo. Nhập email nhận cảnh báo. Bật tùy chọn "chỉ báo khi fail" và cân nhắc "báo sau N lần fail liên tiếp" để tránh nhiễu. Nếu muốn vào Slack, cấu hình tích hợp Slack cho monitor.
- Tùy chọn nâng cao. Bạn có thể bật retry (thử lại nếu request lỗi, giảm báo động giả do mạng chập chờn), đặt request timeout, chọn region chạy gần người dùng (ví dụ chọn region châu Á để đo độ trễ sát thực tế người dùng Việt Nam), và tùy chọn dừng chạy request còn lại nếu một request lỗi.
- Lưu và chạy thử ngay. Sau khi tạo, bấm Run một lần thủ công để chắc chắn nó chạy được trên cloud (không phụ thuộc gì cục bộ). Xem log của run đầu tiên.
- Theo dõi dashboard. Vào trang monitor để xem biểu đồ thời gian phản hồi, tỉ lệ đậu/rớt theo thời gian. Đây là nơi bạn phát hiện xu hướng suy giảm trước khi nó thành sự cố.
Lỗi thường gặp & mẹo
Monitor không gọi được API nội bộ / localhost. Vì monitor chạy trên cloud Postman, nó không thấy localhost, không thấy IP nội bộ trong công ty, không vào được API sau VPN. Nếu API của bạn chỉ truy cập nội bộ, monitor cloud sẽ luôn báo lỗi kết nối. Giải pháp: dùng static IP add-on của Postman để whitelist qua firewall, hoặc expose một endpoint health check công khai an toàn, hoặc dùng Newman tự host thay vì monitor cloud cho các API nội bộ.
Nhầm múi giờ. Như đã nói, kiểm tra kỹ timezone. "Chạy 8 giờ sáng" mà chọn UTC thì thực tế là 15 giờ chiều giờ VN.
Test scripts yếu khiến monitor vô dụng. Monitor không tự biết API đúng hay sai; nó chỉ chạy test bạn viết. Một collection không có pm.test sẽ luôn xanh dù API trả rác. Mẹo: mỗi request tối thiểu phải có test status code và một test kiểm field cốt lõi.
Cảnh báo mệt mỏi. Chạy quá dày + cảnh báo mọi lần fail nhỏ = mọi người tắt thông báo. Mẹo: bật "báo sau N lần fail liên tiếp", bật retry, và tách monitor critical (chạy dày) khỏi monitor regression (chạy thưa).
Đốt ngân sách monitor. Nhớ công thức số request × số lần/ngày. Giảm số request trong collection monitor và giãn tần suất là hai đòn bẩy chính. Đừng để một collection 60 request chạy mỗi 5 phút.
Bí mật bị lộ hoặc thiếu. Monitor không có bạn ngồi cạnh nhập tay, nên token phải có sẵn trong environment/vault. Đừng để lộ secret trong biến dùng chung nhóm nếu không cần; ưu tiên biến ở mức environment gắn riêng monitor.
Dữ liệu rác tích lũy. Nếu monitor chạy request POST tạo dữ liệu (ví dụ tạo đơn hàng), mỗi lần chạy sẽ đẻ ra một bản ghi trên production. Mẹo: monitor production nên nghiêng về các thao tác đọc (GET), hoặc nếu phải ghi thì kèm bước dọn dẹp (xóa dữ liệu test vừa tạo).
Mẹo đặt tên nhất quán. Khi có 10–20 monitor, quy ước <Hệ thống> <Môi trường> <Mục đích> giúp bạn nhìn dashboard là hiểu ngay, và biết monitor nào bắn cảnh báo.
Bài tập thực hành
- Dựng monitor heartbeat đầu tiên. Tạo collection My App Health với đúng 3 request tới một API công khai bất kỳ (ví dụ một API demo như JSONPlaceholder hoặc API dự án của bạn). Mỗi request thêm test kiểm status 200 và một test kiểm response time dưới 1000ms. Tạo monitor hẹn chạy mỗi 30 phút, đặt timezone Asia/Ho_Chi_Minh, và điền email của bạn. Chạy thử thủ công một lần và đọc log.
- Tính ngân sách. Giả sử collection có 8 request và bạn muốn chạy mỗi 10 phút. Tính số lượt request mỗi ngày và mỗi tháng (30 ngày). So sánh với hạn mức gói miễn phí hiện hành của Postman. Đề xuất một tần suất bền vững hơn nếu vượt hạn mức.
- Cố tình làm fail. Sửa một test trong collection để nó kỳ vọng sai (ví dụ mong status 201 trong khi API trả 200). Chạy lại monitor và xác nhận bạn nhận được email cảnh báo. Sau đó sửa lại đúng và quan sát trạng thái trở về xanh trong dashboard.
- Phân tầng monitor. Cho một hệ thống thanh toán giả định 40 request, hãy thiết kế (trên giấy) hai monitor: một Critical và một Full Regression. Ghi rõ mỗi monitor gồm bao nhiêu request, tần suất bao nhiêu, cấu hình cảnh báo thế nào, và lý giải lựa chọn.
Tóm tắt
Postman Monitors cho bạn khả năng chạy collection theo lịch trên cloud của Postman để giám sát sức khỏe và tính đúng đắn của API mà không cần dựng CI hay cron riêng. Ba trụ cột là collection (chứa test scripts thực chất), environment (chỗ đặt base_url và secret), và schedule (lịch + múi giờ). Monitor chỉ mạnh bằng test bên trong: "pass" nghĩa là không assertion nào fail, nên hãy viết assertion phản ánh kỳ vọng nghiệp vụ, không chỉ check status.
Khi triển khai thực tế: giữ collection monitor nhỏ gọn, phân tầng theo mức độ quan trọng (critical chạy dày, regression chạy thưa), canh chừng ngân sách theo công thức số request × số lần/ngày, đặt đúng timezone Asia/Ho_Chi_Minh, dùng retry và "báo sau N lần fail" để tránh cảnh báo mệt mỏi, và nhớ rằng monitor cloud không với tới được API nội bộ trừ khi bạn dùng static IP. Nắm vững những nguyên tắc này, bạn biến Postman thành một "người trực đêm" âm thầm canh API cho mình 24/7.