Giám sát proxy HTTP bằng Prometheus Blackbox Exporter và Alertmanager

Vì sao proxy còn hoạt động nhưng ứng dụng vẫn mất kết nối?

Tiến trình proxy đang chạy không đồng nghĩa với việc ứng dụng có thể sử dụng proxy. Dịch vụ có thể vẫn lắng nghe trên cổng mạng nhưng không truy cập được Internet, gặp lỗi xác thực hoặc không thiết lập được đường hầm tới đích HTTPS.

Vì vậy, giám sát proxy HTTP cần kiểm tra cả hành trình yêu cầu: từ máy giám sát tới proxy, từ proxy tới máy chủ đích và nhận phản hồi hợp lệ. Kiểm tra cổng đơn thuần không phản ánh đầy đủ trải nghiệm này.

Prometheus Blackbox Exporter thực hiện phép thử từ bên ngoài, Prometheus thu thập kết quả, còn Alertmanager định tuyến thông báo khi điều kiện cảnh báo được đáp ứng. Kết hợp đúng cách, các thành phần này giúp phát hiện mất khả dụng và theo dõi xu hướng độ trễ.

Kiến trúc giám sát và ý nghĩa của kết quả

Exporter kiểm tra đường đi qua proxy, Prometheus đánh giá kết quả và Alertmanager định tuyến thông báo.

Luồng kiểm tra bắt đầu khi Prometheus gọi endpoint /probe của Blackbox Exporter. Exporter sử dụng module HTTP đã cấu hình để gửi yêu cầu tới URL kiểm tra thông qua proxy, sau đó trả về metric.

• Blackbox Exporter: thực hiện yêu cầu HTTP và đánh giá phản hồi.
• Prometheus: lưu chuỗi thời gian, chạy biểu thức truy vấn và đánh giá quy tắc cảnh báo.
• Alertmanager: nhóm cảnh báo, định tuyến thông báo và xử lý khoảng im lặng bảo trì.
• Endpoint kiểm tra: cung cấp phản hồi ổn định để xác nhận đường truyền qua proxy hoạt động.

Cần phân biệt kiểm tra uptime proxy với kiểm tra một tiến trình. Phép thử này phản ánh tính khả dụng của toàn bộ đường đi được chọn. Khi thất bại, nguyên nhân có thể nằm ở proxy, DNS, mạng hoặc máy chủ đích.

Chuẩn bị endpoint và vị trí đặt exporter

Chọn đích kiểm tra có thể kiểm soát

Nên sử dụng endpoint do tổ chức quản lý, phản hồi đơn giản và không phụ thuộc vào đăng nhập tương tác. Tránh dùng trang chủ có chuyển hướng thường xuyên, nội dung thay đổi hoặc phụ thuộc nhiều dịch vụ phía sau.

Nếu ứng dụng chủ yếu truy cập HTTPS thông qua proxy HTTP, hãy dùng đích HTTPS. Phép thử khi đó bao gồm việc thiết lập đường hầm CONNECT và kết nối TLS tới máy chủ đích, sát với hành vi ứng dụng hơn.

Có thể bổ sung đích kiểm tra độc lập để đối chiếu. Nếu chỉ một đích thất bại trong khi các đích khác vẫn hoạt động, cần xem xét sự cố tại đích trước khi kết luận proxy mất kết nối.

Đặt exporter trong vùng mạng phù hợp

Exporter nên có đường truy cập tới proxy tương tự ứng dụng cần giám sát. Một phép thử thành công từ mạng quản trị không bảo đảm ứng dụng trong mạng sản xuất cũng kết nối được.

Gắn nhãn vùng mạng hoặc vị trí kiểm tra để phân biệt kết quả. Đồng thời, giới hạn quyền truy cập exporter và kiểm soát lưu lượng đi ra, vì endpoint probe có khả năng phát sinh yêu cầu tới địa chỉ được chỉ định.

Cấu hình Prometheus Blackbox Exporter cho proxy HTTP

Tạo module HTTP sử dụng proxy

Trong cấu hình Blackbox Exporter, khai báo module với prober: http. Bên trong phần http, đặt proxy_url thành địa chỉ proxy, chẳng hạn http://proxy.internal:3128. Đây là địa chỉ minh họa, cần thay bằng thông tin thực tế.

Module được Prometheus chọn qua tham số module. Ngược lại, tham số target phải là URL đích cần truy cập qua proxy, không phải địa chỉ proxy. Nhầm lẫn hai địa chỉ này có thể tạo ra phép thử không đúng mục tiêu.

• method: chọn phương thức phù hợp với endpoint kiểm tra.
• valid_status_codes: khai báo mã phản hồi được chấp nhận nếu cần khác mặc định.
• follow_redirects: quyết định có đi theo chuyển hướng hay không.
• timeout: giới hạn thời gian hoàn thành phép thử.
• fail_if_body_not_matches_regexp: có thể dùng để xác nhận nội dung mong đợi.

Nếu endpoint trả về một chuỗi xác nhận riêng, kiểm tra nội dung giúp tránh coi trang lỗi trung gian là thành công. Tuy nhiên, không nên ràng buộc vào nội dung thường xuyên thay đổi.

Xử lý thông tin xác thực và TLS

Phân biệt xác thực tới proxy với xác thực tại máy chủ đích. Các trường xác thực HTTP dành cho đích không tự động thay thế thông tin xác thực proxy. Hãy kiểm tra cơ chế được phiên bản exporter đang sử dụng hỗ trợ.

Không đưa mật khẩu vào nhãn Prometheus, URL target hay nội dung thông báo. Nếu thông tin xác thực xuất hiện trong cấu hình, cần giới hạn quyền đọc, quản lý bí mật và tránh lưu vào kho mã nguồn.

Với đích HTTPS, duy trì xác minh chứng chỉ và cấu hình CA phù hợp khi dùng chứng chỉ nội bộ. Tắt xác minh TLS sẽ làm giảm giá trị của phép thử và có thể che khuất lỗi mà ứng dụng thực sự gặp phải.

Cấu hình Prometheus thu thập kết quả probe

Tạo scrape job riêng, đặt metrics_path là /probe và truyền tên module trong params. Các target của job là URL kiểm tra; địa chỉ exporter được đưa vào bằng relabeling.

Trình tự relabeling thông dụng như sau:

1. Chuyển __address__ ban đầu sang __param_target để exporter nhận URL đích.
2. Sao chép __param_target sang instance để nhận diện đích trong kết quả.
3. Ghi đè __address__ bằng địa chỉ Blackbox Exporter để Prometheus gọi đúng dịch vụ.

Bổ sung các nhãn ổn định như proxy_id, environment và region. Khi có nhiều proxy, có thể tạo module tương ứng rồi chọn module qua cấu hình job hoặc relabeling. Nhãn mô tả proxy không tự thay đổi proxy_url của module.

Timeout của module phải phù hợp với scrape_timeout, đồng thời chừa thời gian cho exporter trả kết quả. Khoảng scrape và thời gian duy trì điều kiện cảnh báo cần được chọn theo yêu cầu vận hành, thay vì sao chép một ngưỡng chung.

Đọc metric uptime và độ trễ đúng cách

Phân biệt probe_success và up

Scrape thành công không bảo đảm probe thành công, còn mất dữ liệu exporter chưa chứng minh proxy bị hỏng.

probe_success cho biết phép thử có đáp ứng điều kiện thành công hay không. Biểu thức probe_success{job="blackbox-http-proxy"} == 0 chọn các phép thử thất bại.

Trong khi đó, up phản ánh Prometheus có scrape thành công endpoint của exporter hay không. Exporter vẫn có thể trả metric bình thường dù yêu cầu qua proxy thất bại. Vì thế, chỉ theo dõi up sẽ bỏ sót sự cố trên đường truyền qua proxy.

Hiểu giới hạn của phép đo độ trễ

probe_duration_seconds thể hiện tổng thời gian thực hiện probe. Đây là chỉ báo hữu ích về thời gian hoàn thành yêu cầu qua proxy, nhưng không phải độ trễ riêng của proxy.

probe_http_duration_seconds cung cấp thời gian theo các pha HTTP được exporter ghi nhận. Khi sử dụng proxy, đặc biệt với CONNECT, không nên mặc định từng pha tương ứng hoàn toàn với một thành phần mạng độc lập. Cần đối chiếu cách triển khai và log chẩn đoán của phiên bản đang chạy.

Nên xem độ trễ của các probe thành công tách biệt với probe thất bại. Một yêu cầu bị từ chối nhanh có thời gian thấp nhưng không phải tín hiệu chất lượng tốt. Khi phân tích xu hướng, luôn đặt biểu đồ độ trễ cạnh trạng thái thành công.

Thiết lập cảnh báo proxy mất kết nối

Xây dựng điều kiện cảnh báo có thời gian xác nhận

Tạo quy tắc cảnh báo dựa trên biểu thức probe_success{job="blackbox-http-proxy"} == 0. Thêm trường for để yêu cầu tình trạng lỗi tồn tại liên tục trước khi chuyển sang trạng thái firing.

Thời gian xác nhận cần cân bằng giữa tốc độ phát hiện và khả năng chịu lỗi ngắn hạn. Hãy lựa chọn dựa trên chu kỳ scrape, mức độ quan trọng của proxy và dữ liệu vận hành thực tế.

Trong annotations, mô tả chính xác rằng phép thử qua proxy thất bại, thay vì khẳng định tiến trình proxy đã dừng. Thông báo nên chứa proxy, môi trường, đích kiểm tra và hướng dẫn xử lý ban đầu.

Cảnh báo khi mất khả năng quan sát

Tạo cảnh báo riêng cho up{job="blackbox-http-proxy"} == 0. Trường hợp này cho thấy Prometheus không lấy được kết quả probe, không trực tiếp chứng minh proxy hỏng.

Nếu target bị xóa khỏi cấu hình hoặc service discovery, chuỗi thời gian có thể biến mất thay vì chuyển sang giá trị lỗi. Có thể dùng absent hoặc absent_over_time cho tập nhãn đã biết; với nhiều proxy, cần đối chiếu danh sách proxy kỳ vọng để phát hiện thiếu từng đối tượng.

Định tuyến thông báo qua Alertmanager

Alertmanager nhóm và định tuyến cảnh báo theo ngữ cảnh, đồng thời hỗ trợ im lặng trong thời gian bảo trì.

Prometheus đánh giá quy tắc và gửi cảnh báo sang Alertmanager. Alertmanager không tự thực hiện probe; nhiệm vụ của nó là nhóm, định tuyến và gửi thông báo tới receiver được cấu hình.

Có thể nhóm theo tên cảnh báo, proxy và môi trường để giữ đủ ngữ cảnh. Định tuyến môi trường sản xuất tới nhóm trực vận hành, còn môi trường thử nghiệm tới kênh ít khẩn cấp hơn.

• group_wait: chờ trước khi gửi thông báo đầu tiên của nhóm.
• group_interval: điều tiết thông báo cập nhật trong nhóm.
• repeat_interval: quyết định thời điểm nhắc lại cảnh báo còn tồn tại.

Sử dụng silence cho bảo trì có kế hoạch và bật thông báo phục hồi nếu receiver hỗ trợ. Chỉ áp dụng inhibition khi quan hệ phụ thuộc rõ ràng; không nên tự động coi mọi lỗi probe là hệ quả của lỗi exporter.

Kiểm thử trước khi đưa vào vận hành

Kiểm tra cú pháp cấu hình và quy tắc bằng công cụ phù hợp trước khi nạp lại. Sau đó, thử từng tình huống trong môi trường được phép để xác nhận toàn bộ chuỗi phát hiện và thông báo.

1. Chặn kết nối từ exporter tới proxy để xác nhận probe thất bại.
2. Thử thông tin xác thực không hợp lệ và kiểm tra thông báo có bảo vệ bí mật.
3. Làm endpoint kiểm tra không khả dụng để phân biệt lỗi đích với lỗi proxy.
4. Dừng exporter nhằm kiểm tra cảnh báo mất dữ liệu giám sát.
5. Khôi phục dịch vụ và xác nhận trạng thái resolved được gửi đúng nơi.

Trong quá trình chẩn đoán, có thể gọi probe với tham số debug=true để xem chi tiết xử lý. Chỉ sử dụng trong phạm vi được kiểm soát và rà soát dữ liệu nhạy cảm trước khi chia sẻ log.

Kết luận

Giám sát proxy HTTP hiệu quả cần kết hợp phép thử đầu cuối, cách diễn giải metric chính xác và quy trình cảnh báo có kiểm chứng. Prometheus Blackbox Exporter cung cấp dữ liệu về khả dụng và thời gian thực hiện yêu cầu; Prometheus cùng Alertmanager chuyển dữ liệu đó thành tín hiệu vận hành.

Điểm quan trọng nhất là phân biệt lỗi đường truyền qua proxy, lỗi endpoint và lỗi hệ thống giám sát. Khi cấu hình phản ánh đúng hành trình ứng dụng, cảnh báo proxy mất kết nối sẽ có ngữ cảnh rõ ràng và hỗ trợ xử lý sự cố hiệu quả hơn.