Tôi có thể dùng những phương thức HTTP nào để giám sát API?

GET, POST, PUT, DELETE, PATCH và HEAD. Hãy cấu hình phương thức cho từng monitor — với các endpoint ghi (POST/PUT/PATCH) body của request cũng có thể cấu hình dạng chuỗi JSON hoặc form data.

Kiểm tra JSON hoạt động như thế nào?

Bạn nhập đường dẫn JSON (ví dụ data.status hoặc results[0].id) và giá trị mong đợi. Monitor nhận phản hồi, phân tích thành JSON, lấy ra giá trị tại đường dẫn và so sánh với kỳ vọng. Nếu không khớp, bài kiểm tra thất bại với lỗi "assertion failed" và hiển thị giá trị thực tế.

Tôi có thể gửi header xác thực?

Có. Header HTTP tùy chỉnh có thể cấu hình riêng cho từng monitor — Authorization, API key, content-type, v.v... Giá trị header được mã hóa nghỉ trong cơ sở dữ liệu. Với Basic Auth có trường username/password riêng, sẽ tự động ký vào request.

Nếu API trả về 200 nhưng bên trong là lỗi thì sao?

Một mẫu điển hình: API trả về HTTP 200 nhưng body lại là {"status":"error"}. Monitor uptime đơn giản cho rằng API đang hoạt động tốt. Sử dụng kiểm tra JSON status == "ok" để phát hiện trường hợp này — assertion không đạt và monitor báo DOWN dù HTTP nói 200.

Làm thế nào để xử lý API bị rate limit?

Thiết lập tần suất kiểm tra để tôn trọng giới hạn của API (ví dụ: mỗi 5 phút nếu API cho phép 12 lần gọi/giờ). Mỗi lần kiểm tra được tính là một lần gọi API/mỗi khu vực. Nếu kiểm tra đa vùng, số lượt gọi tổng tăng lên — dùng kiểm tra một vùng nếu API của bạn bị giới hạn nghiêm ngặt.

Giám sát API — HTTP, JSON, Bearer Auth

REST API xứng đáng được kiểm tra nhiều hơn trạng thái 200 OK. Xác thực phương thức, header, body, đường dẫn JSON và mã phản hồi chính xác.

Tại sao API cần giám sát riêng

API không chỉ đơn giản là một trang dưới /api/. Nó là một hợp đồng. Phương thức HTTP có ý nghĩa - GET và POST thay đổi ngữ nghĩa. Header mang xác thực, thương lượng nội dung, khóa idempotency. Body của yêu cầu là dữ liệu đầu vào. Mã phản hồi có ý nghĩa (401 so với 403 so với 422 - mỗi cái kể một câu chuyện khác nhau). Body phản hồi có cấu trúc - các đường dẫn JSON mà các bên tích hợp dựa vào. Một kiểm tra uptime bình thường, chỉ gửi GET tới URL sẽ bỏ lỡ phần lớn các cách một API có thể bị hỏng: JSON không hợp lệ vẫn trả về 200, endpoint xác thực chấp nhận dữ liệu sai, webhook có dạng payload hỏng, endpoint trả về 200 nhưng bên trong lại có "status": "error".

Giám sát API giải quyết điều này, cho bạn quyền kiểm soát từng phần của request và từng phần xác minh phản hồi. Bạn cấu hình chính xác một call như các bên tích hợp bạn thực hiện - cùng phương thức, cùng header, cùng body, cùng xác thực - và chính xác điều gì được coi là thành công - mã phản hồi cụ thể, giá trị theo đường dẫn JSON, ngưỡng thời gian phản hồi, giới hạn kích thước.

Cấu hình request

Với mỗi monitor API trong DiagnoSEO Uptime Monitoring, bạn có thể cấu hình:

Phương thức HTTP: GET, POST, PUT, PATCH, DELETE, HEAD. Chọn phương thức mà các bên tích hợp sử dụng.
Header tuỳ chỉnh: dưới dạng đối tượng JSON, ví dụ {"Authorization": "Bearer eyJ...", "X-API-Version": "2024-01-15"}. Chuẩn để kiểm tra OAuth, JWT, khóa API, thương lượng nội dung.
Body yêu cầu: bất kỳ chuỗi nào - JSON, XML, form-encoded, plain text. Được gửi trong POST/PUT/PATCH/DELETE.
Basic auth: tên người dùng và mật khẩu, nếu endpoint được bảo vệ kiểu này.
Mã trạng thái mong đợi: danh sách hoặc phạm vi. Mặc định 200-399, nhưng bạn có thể chỉ định nghiêm ngặt một mã cụ thể (ví dụ đúng 201 cho endpoint tạo mới) hoặc chỉ cho phép những mã cụ thể (ví dụ 200,202,204).

Kiểm tra sẽ theo dõi tối đa 5 chuyển hướng, giải mã gzip, phân tích Content-Type để phát hiện JSON. Mỗi lần kiểm tra sẽ ghi lại mã thực tế, thời gian đáp ứng, kích thước và bất cứ lỗi nào. Nhiều lần lỗi liên tiếp (cấu hình được, mặc định là 2) sẽ kích hoạt sự cố.

Kiểm tra JSON theo đường dẫn (JSON path assertion)

Chỉ mã trạng thái thường không đủ cho nhiều API. Endpoint health có thể trả về 200 với body {"status": "degraded", "db": "down"} - vẫn là 200, nhưng bạn chắc chắn muốn biết điều đó. API giá có thể trả về 200 với body, nơi data.price tụt xuống null. API tìm kiếm có thể trả về 200 với results: [] vì chỉ mục bị lỗi.

Trong các trường hợp như vậy, hãy cấu hình kiểm tra JSON path. Đặt đường dẫn (ví dụ data.status hoặc health.checks.db) và giá trị mong đợi (ví dụ healthy, true hoặc một số cụ thể). Mỗi lần kiểm tra phản hồi sẽ được giải mã từ JSON và giá trị tại đường dẫn sẽ được so sánh. Không khớp sẽ làm bài kiểm tra thất bại, bất kể trạng thái HTTP là gì.

Cú pháp đường dẫn dùng ký hiệu dấu chấm và ngoặc: data.items[0].id hoạt động, tương tự users.john.email. Giá trị mong đợi được so sánh dạng chuỗi, vậy nên "true" sẽ khớp với giá trị bool true, và số thì khớp cả dạng chuỗi lẫn số.

Các mẫu xác thực

Hai kiểu xác thực phổ biến nhất hoạt động ngay. Đối với token Bearer (OAuth, JWT, API keys) sử dụng trường header: {"Authorization": "Bearer eyJhbGciOi..."}. Token được lưu cấu hình trong monitor và gửi đi trong mỗi lần kiểm tra. Với basic auth, dùng trường người dùng/mật khẩu riêng biệt - được lưu và kết hợp thành header chuẩn.

Nếu xác thực đòi hỏi ký trên từng request hoặc làm mới token, sẽ phức tạp hơn. Hai mẫu hợp lý: (1) cấu hình token sống lâu cho tài khoản dịch vụ chỉ dùng cho monitoring, hoặc (2) tạo một endpoint health không yêu cầu xác thực song phản ánh trạng thái endpoint thật, và monitor endpoint này. Hầu hết các API hiện đại đều đã có sẵn mẫu này.

Những mẫu thực hành mà chúng tôi khuyến nghị

Mỗi endpoint quan trọng hãy có một monitor riêng. Đừng kiểm tra tất cả - chọn 5-10 endpoint mà khi xuống sẽ gây ảnh hưởng thật sự.
Sử dụng mã trạng thái cụ thể. Mặc định 200-399 là quá dễ dãi cho API. Endpoint tạo mới nên trả về đúng 201; endpoint idempotent đúng 200; endpoint đăng nhập đúng 200 (thành công) hoặc 401 (thất bại hợp lệ - không phải 500).
Kết hợp trạng thái với kiểm tra JSON. Kết hợp sẽ bắt cả lỗi lớp truyền tải lẫn nội dung. Chỉ kiểm tra trạng thái sẽ không nhận ra lỗi nội dung; chỉ kiểm tra JSON sẽ dễ hỏng với redirect.
Đặt ngưỡng thời gian phản hồi. Suy giảm hiệu năng API là dấu hiệu sớm của các vấn đề phụ thuộc. Monitor với rt_threshold_ms = 800 sẽ cho bạn biết API chậm lại trước khi hỏng hẳn.
Giữ body nhỏ gọn. Kiểm tra diễn ra mỗi phút - body lớn gây lãng phí băng thông ở cả hai phía. Payload đại diện nhưng tối giản là đủ.

Kết hợp với các loại monitor khác

Với mỗi endpoint API, monitor API sẽ xác minh rằng call hoạt động. Một monitor ping hoặc port riêng xác minh rằng máy chủ còn sống. Kiểm tra SSL/domain trên cùng host name sẽ bắt các vấn đề về chứng chỉ và đăng ký. Sub-monitor DNS giám sát thay đổi bản ghi, có thể chỉ ra việc tài nguyên bị trỏ nhầm. Tổng cộng bốn loại monitor trên API giúp bạn có cái nhìn đầy đủ mà mức trùng lặp tối thiểu.

Cấu hình

Mở công cụ, nhấn "Thêm monitor", chọn loại "API". Dán URL. Mở phần Nâng cao. Chọn phương thức, dán header (dưới dạng JSON), dán body nếu cần, cấu hình basic auth nếu dùng, nhập mã trạng thái mong muốn (ví dụ 200 hoặc 200,201). Thêm kiểm tra JSON path nếu cần. Thiết lập tần suất và ngưỡng xác nhận. Lưu lại. Từ chu kỳ tiếp theo, monitor sẽ gọi API của bạn đúng như một bên tích hợp thực hiện, xác thực phản hồi và cảnh báo ngay khi phát hiện sự cố.

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

Tôi có thể dùng những phương thức HTTP nào để giám sát API?
GET, POST, PUT, DELETE, PATCH và HEAD. Hãy cấu hình phương thức cho từng monitor — với các endpoint ghi (POST/PUT/PATCH) body của request cũng có thể cấu hình dạng chuỗi JSON hoặc form data.
Kiểm tra JSON hoạt động như thế nào?
Bạn nhập đường dẫn JSON (ví dụ data.status hoặc results[0].id) và giá trị mong đợi. Monitor nhận phản hồi, phân tích thành JSON, lấy ra giá trị tại đường dẫn và so sánh với kỳ vọng. Nếu không khớp, bài kiểm tra thất bại với lỗi "assertion failed" và hiển thị giá trị thực tế.
Tôi có thể gửi header xác thực?
Có. Header HTTP tùy chỉnh có thể cấu hình riêng cho từng monitor — Authorization, API key, content-type, v.v... Giá trị header được mã hóa nghỉ trong cơ sở dữ liệu. Với Basic Auth có trường username/password riêng, sẽ tự động ký vào request.
Nếu API trả về 200 nhưng bên trong là lỗi thì sao?
Một mẫu điển hình: API trả về HTTP 200 nhưng body lại là {"status":"error"}. Monitor uptime đơn giản cho rằng API đang hoạt động tốt. Sử dụng kiểm tra JSON status == "ok" để phát hiện trường hợp này — assertion không đạt và monitor báo DOWN dù HTTP nói 200.
Làm thế nào để xử lý API bị rate limit?
Thiết lập tần suất kiểm tra để tôn trọng giới hạn của API (ví dụ: mỗi 5 phút nếu API cho phép 12 lần gọi/giờ). Mỗi lần kiểm tra được tính là một lần gọi API/mỗi khu vực. Nếu kiểm tra đa vùng, số lượt gọi tổng tăng lên — dùng kiểm tra một vùng nếu API của bạn bị giới hạn nghiêm ngặt.

Giám sát API