Nếu proxy được sử dụng trong sản xuất — để phân tích, tự động hóa tài khoản SMM hoặc đa tài khoản quy mô lớn — sớm hay muộn sẽ có thời điểm mà "có vẻ hoạt động" không còn là câu trả lời đủ. Cần có số liệu: bao nhiêu yêu cầu bị lỗi, độ trễ đã tăng bao nhiêu sau khi thay đổi nhóm IP, giới hạn lưu lượng của nhà cung cấp có bị cạn kiệt không. Chúng ta sẽ phân tích 7 chỉ số cần thu thập trong Prometheus và trực quan hóa trong Grafana, để thấy vấn đề trước khi người dùng hoặc tài khoản bị chặn nhận ra.
Tại sao cần theo dõi proxy trong sản xuất
Proxy không phải là một hạ tầng tĩnh như máy chủ với IP cố định. Đây là một nhóm địa chỉ liên tục thay đổi, hành vi của nó phụ thuộc vào nhà cung cấp, tải, khu vực và thậm chí là thời gian trong ngày. Nếu không có giám sát, bạn chỉ biết về vấn đề khi trình phân tích Wildberries hoặc Ozon ngừng trả dữ liệu, tài khoản Facebook Ads bị chặn, hoặc kịch bản tự động hóa Instagram bắt đầu gặp captcha.
Nhiệm vụ của việc giám sát là biến "có gì đó không đúng" thành những con số cụ thể: tỷ lệ lỗi đã tăng từ 2% lên 15% trong giờ qua, độ trễ trung bình đã tăng gấp ba lần, lưu lượng qua một proxy đã vượt quá giới hạn. Điều này cho phép phản ứng trước khi vấn đề trở nên nghiêm trọng — tự động chuyển đổi nhóm, thay đổi nhà cung cấp hoặc giảm tần suất yêu cầu.
Để thu thập các chỉ số, chúng ta sử dụng bộ đôi Prometheus (lưu trữ chuỗi thời gian) + Grafana (trực quan hóa và cảnh báo). Đây là bộ công cụ tiêu chuẩn trong DevOps, dễ dàng tích hợp với bất kỳ ngôn ngữ nào — Python, Node.js, Go. Dưới đây là các ví dụ bằng Python với thư viện prometheus_client, nhưng nguyên tắc là phổ quát.
Chỉ số 1: Tỷ lệ thành công — tỷ lệ yêu cầu thành công
Đây là chỉ số cơ bản, báo hiệu đầu tiên về các vấn đề với nhóm proxy. Nó được tính là tỷ lệ giữa các yêu cầu có mã phản hồi 200-299 so với tổng số yêu cầu trong một khoảng thời gian. Sự giảm tỷ lệ thành công xuống dưới 90% thường có nghĩa là một phần IP trong nhóm đã bị chặn bởi trang web mục tiêu hoặc nhà cung cấp đang cung cấp các địa chỉ không ổn định.
Ví dụ về việc công cụ hóa bằng Python:
from prometheus_client import Counter, start_http_server
import requests
REQUESTS_TOTAL = Counter(
'proxy_requests_total', 'Tổng số yêu cầu qua proxy',
['proxy_pool', 'status']
)
def fetch_with_proxy(url, proxy, pool_name="residential"):
try:
resp = requests.get(url, proxies={"http": proxy, "https": proxy}, timeout=10)
status = "success" if resp.status_code < 300 else "failure"
except requests.exceptions.RequestException:
status = "failure"
REQUESTS_TOTAL.labels(proxy_pool=pool_name, status=status).inc()
start_http_server(9100) # điểm cuối cho Prometheus scrape
Truy vấn PromQL để tính toán tỷ lệ thành công trong 5 phút qua:
sum(rate(proxy_requests_total{status="success"}[5m]))
/
sum(rate(proxy_requests_total[5m])) * 100
Nếu bạn làm việc với nhiều loại proxy cùng lúc — chẳng hạn như proxy cư trú cho mạng xã hội và proxy trung tâm dữ liệu cho phân tích — thì nên phân tách tỷ lệ thành công theo nhãn proxy_pool, để thấy nhóm nào đang suy giảm.
Chỉ số 2: Độ trễ — thời gian phản hồi
Độ trễ cho thấy tốc độ mà proxy trả lời. Sự gia tăng đột ngột của độ trễ thường xảy ra trước khi tỷ lệ thành công giảm — nhà cung cấp bị quá tải, hoặc IP đã gần bị chặn và máy chủ mục tiêu bắt đầu cố ý làm chậm phản hồi. Đối với độ trễ, quan trọng là thu thập không chỉ giá trị trung bình mà còn cả các phần trăm — p50, p95, p99, vì giá trị trung bình có thể che giấu các độ trễ đuôi, thực sự cản trở công việc.
from prometheus_client import Histogram
import time
REQUEST_DURATION = Histogram(
'proxy_request_duration_seconds',
'Thời gian yêu cầu qua proxy',
['proxy_pool'],
buckets=[0.1, 0.25, 0.5, 1, 2, 5, 10]
)
def fetch_timed(url, proxy, pool_name="mobile"):
start = time.time()
try:
requests.get(url, proxies={"http": proxy, "https": proxy}, timeout=10)
finally:
REQUEST_DURATION.labels(proxy_pool=pool_name).observe(time.time() - start)
PromQL cho p95 độ trễ:
histogram_quantile(0.95,
sum(rate(proxy_request_duration_seconds_bucket[5m])) by (le, proxy_pool)
)
Đối với các nhiệm vụ mà tốc độ là rất quan trọng — chẳng hạn như tự động hóa TikTok Ads, nơi mỗi giây tải trang tăng nguy cơ timeout trong trình duyệt chống phát hiện — nên thiết lập cảnh báo cho p95 cao hơn 3-4 giây.
Chỉ số 3: Tỷ lệ lỗi theo loại lỗi
Chỉ có thành công/thất bại là không đủ để chẩn đoán. Cần phân loại lỗi theo loại: 407 (Proxy Authentication Required) có nghĩa là có vấn đề với xác thực, 429 (Too Many Requests) — vượt quá giới hạn yêu cầu, timeout — vấn đề mạng, 403 — bị chặn bởi bảo vệ chống bot của trang web mục tiêu. Mỗi loại lỗi yêu cầu phản ứng khác nhau.
ERROR_BY_TYPE = Counter(
'proxy_errors_total', 'Lỗi proxy theo loại',
['proxy_pool', 'error_type']
)
def classify_error(resp=None, exc=None):
if exc:
if isinstance(exc, requests.exceptions.Timeout):
return "timeout"
return "connection_error"
if resp.status_code == 407:
return "auth_error"
if resp.status_code == 429:
return "rate_limited"
if resp.status_code == 403:
return "blocked_by_target"
return "other"
Bảng các lỗi điển hình và nguyên nhân của chúng:
| Mã/loại | Nguyên nhân có thể | Cần kiểm tra |
|---|---|---|
| 407 | Thông tin xác thực không đúng hoặc phiên đã hết hạn | Đăng nhập/mật khẩu proxy, định dạng chuỗi kết nối |
| 429 | Vượt quá giới hạn yêu cầu trên IP | Tần suất yêu cầu, kích thước nhóm |
| 403 | Bảo vệ chống bot của trang web mục tiêu | User-Agent, fingerprint, loại proxy |
| timeout | Quá tải nhà cung cấp hoặc mạng | Tải trên nhóm, cài đặt timeout của client |
Chỉ số 4: Tốc độ vòng quay và độ bền của IP
Nếu bạn sử dụng proxy quay vòng, điều quan trọng là biết tần suất thay đổi IP và bao nhiêu yêu cầu có thể thực hiện trước khi địa chỉ "bị cháy" (bị chặn bởi trang web mục tiêu). Chỉ số này đặc biệt quan trọng cho đa tài khoản — chẳng hạn như khi nuôi tài khoản Facebook Ads qua Dolphin Anty hoặc AdsPower, nơi việc thay đổi IP sớm có thể làm gián đoạn phiên và kích hoạt kiểm tra bảo mật.
from prometheus_client import Gauge
IP_LIFETIME = Gauge(
'proxy_ip_lifetime_seconds', 'Thời gian sống của IP trước khi vòng quay',
['proxy_pool']
)
IP_REQUESTS_BEFORE_BAN = Histogram(
'proxy_requests_before_ban',
'Số yêu cầu đã thực hiện trước khi IP bị chặn',
['proxy_pool'],
buckets=[10, 50, 100, 500, 1000, 5000]
)
Đối với proxy di động, chỉ số này hoạt động khác so với proxy cư trú — vòng quay qua việc thay đổi trạm gốc của nhà mạng mang lại các IP "sạch" hơn với xác suất bị chặn thấp hơn. Nếu nhiệm vụ của bạn là tự động hóa SMM với độ nhạy cao đối với việc bị chặn, nên so sánh các chỉ số độ bền của IP giữa proxy di động và proxy cư trú trên dữ liệu thực từ bảng điều khiển của bạn, thay vì dựa vào các khuyến nghị chung.
Chỉ số 5: Băng thông — tiêu thụ lưu lượng
Hầu hết các gói proxy được tính theo khối lượng lưu lượng, không phải theo số lượng yêu cầu. Nếu không có giám sát, dễ dàng bỏ lỡ thời điểm giới hạn gần cạn kiệt — đặc biệt nếu nhiệm vụ bao gồm tải hình ảnh hoặc video, chẳng hạn như khi phân tích thẻ sản phẩm Wildberries với nhiều hình ảnh.
BANDWIDTH_USED = Counter(
'proxy_bandwidth_bytes_total', 'Lưu lượng tiêu thụ qua proxy',
['proxy_pool', 'direction'] # direction: upload/download
)
def track_bandwidth(resp, pool_name):
size = len(resp.content)
BANDWIDTH_USED.labels(proxy_pool=pool_name, direction="download").inc(size)
Trên bảng điều khiển Grafana, nên xây dựng không phải giá trị tuyệt đối của lưu lượng, mà là tốc độ tiêu thụ của nó (rate) — điều này giúp dự đoán khi nào giới hạn sẽ hết và lên kế hoạch trước cho việc mua thêm hoặc chuyển sang nhóm khác.
Chỉ số 6: Phân phối địa lý và sự phù hợp với khu vực
Đối với các nhà tiếp thị thử nghiệm quảng cáo từ các quốc gia khác nhau và các nhà phân tích làm việc với nhắm mục tiêu địa lý trong Google Ads hoặc TikTok Ads, điều quan trọng là IP thực sự phù hợp với khu vực đã công bố. Lỗi địa lý có thể dẫn đến việc quảng cáo không đến đúng đối tượng hoặc tài khoản bị chặn vì không phù hợp với cài đặt địa lý.
GEO_MISMATCH = Counter(
'proxy_geo_mismatch_total',
'Số trường hợp không khớp giữa địa lý đã công bố và thực tế',
['expected_country', 'actual_country']
)
def verify_geo(proxy, expected_country):
resp = requests.get("https://ipapi.co/json/", proxies={"https": proxy}, timeout=5)
actual = resp.json().get("country_code")
if actual != expected_country:
GEO_MISMATCH.labels(expected_country=expected_country, actual_country=actual).inc()
Nên kiểm tra địa lý không phải trên mỗi yêu cầu (điều này tốn kém về lưu lượng và thời gian), mà định kỳ — mỗi giờ trên mẫu IP từ nhóm, đủ để đảm bảo độ tin cậy thống kê.
Chỉ số 7: Kết nối đồng thời — phiên làm việc song song
Số lượng kết nối đồng thời qua proxy cho thấy tải thực tế trên nhóm. Nếu số phiên làm việc song song nhiều hơn số IP trong nhóm có thể xử lý mà không bị suy giảm, điều này sẽ dẫn đến sự gia tăng độ trễ và tỷ lệ lỗi từ các điểm trước đó. Chỉ số này đặc biệt quan trọng trong việc mở rộng — khi một công ty SMM tăng số lượng tài khoản khách hàng đang hoạt động từ 10 lên 50.
from prometheus_client import Gauge
ACTIVE_CONNECTIONS = Gauge(
'proxy_active_connections', 'Kết nối hoạt động hiện tại qua proxy',
['proxy_pool']
)
def on_request_start(pool_name):
ACTIVE_CONNECTIONS.labels(proxy_pool=pool_name).inc()
def on_request_end(pool_name):
ACTIVE_CONNECTIONS.labels(proxy_pool=pool_name).dec()
Việc so sánh chỉ số này với tỷ lệ lỗi trên cùng một biểu đồ trong Grafana sẽ nhanh chóng cho thấy mối tương quan: ngay khi số phiên làm việc song song vượt qua một ngưỡng nhất định, lỗi bắt đầu tăng theo cách phi tuyến tính.
Thiết lập bảng điều khiển trong Grafana: từng bước
Sau khi các chỉ số được công cụ hóa và Prometheus thu thập chúng, cần trực quan hóa dữ liệu trong Grafana. Các bước thực hiện:
- Thêm Prometheus làm nguồn dữ liệu: Cấu hình → Nguồn dữ liệu → Thêm nguồn dữ liệu → Prometheus, chỉ định URL của máy chủ Prometheus của bạn (thường là
http://localhost:9090). - Tạo một bảng điều khiển mới: Tạo → Bảng điều khiển → Thêm panel mới.
- Đối với panel Tỷ lệ thành công, sử dụng truy vấn PromQL từ phần chỉ số 1, loại trực quan hóa — Gauge hoặc Chuỗi thời gian.
- Đối với Độ trễ, tạo một panel với loại Heatmap, để thấy phân phối p50/p95/p99 theo thời gian.
- Đối với Tỷ lệ lỗi, xây dựng Biểu đồ cột chồng với phân tách theo nhãn
error_type— điều này sẽ cho thấy rõ loại lỗi nào đang chiếm ưu thế. - Thêm biến bảng điều khiển (Cài đặt Bảng điều khiển → Biến) cho
proxy_pool, để chuyển đổi giữa các nhóm mà không cần tạo bảng điều khiển riêng biệt. - Lưu bảng điều khiển và thiết lập tự động cập nhật mỗi 30 giây cho việc giám sát gần thời gian thực.
JSON bảng điều khiển hoàn chỉnh có thể được xuất qua Chia sẻ → Xuất → Lưu vào tệp và tái sử dụng cho các nhóm proxy khác nhau — cư trú, di động và trung tâm dữ liệu, chỉ cần thay đổi giá trị của biến.
Cảnh báo: khi nào cần hành động
Bảng điều khiển sẽ vô dụng nếu không ai nhìn vào nó vào thời điểm xảy ra sự cố. Do đó, rất quan trọng để thiết lập cảnh báo trong Grafana (Cảnh báo → Quy tắc cảnh báo) với các ngưỡng sau, được điều chỉnh cho hầu hết các kịch bản sản xuất:
| Chỉ số | Ngưỡng cảnh báo | Hành động |
|---|---|---|
| Tỷ lệ thành công | dưới 85% trong 5 phút | Kiểm tra nhóm, chuyển sang dự phòng |
| p95 Độ trễ | trên 5 giây | Giảm mức độ song song, kiểm tra nhà cung cấp |
| Tỷ lệ 429 | trên 10% yêu cầu | Giảm tần suất yêu cầu, tăng nhóm IP |
| Tỷ lệ băng thông | dự đoán cạn kiệt giới hạn trong 24 giờ | Mua thêm lưu lượng hoặc tối ưu hóa yêu cầu |
Tốt nhất là gửi cảnh báo qua Telegram hoặc Slack qua webhook — điều này đảm bảo phản ứng ngay lập tức, thay vì kiểm tra bảng điều khiển một lần mỗi ngày.
Kết luận
Bảy chỉ số — tỷ lệ thành công, độ trễ, tỷ lệ lỗi theo loại, độ bền của IP, lưu lượng, sự phù hợp địa lý và tính đồng thời của các kết nối — cung cấp bức tranh đầy đủ về sức khỏe của hạ tầng proxy trong sản xuất. Bộ đôi Prometheus + Grafana không chỉ cho phép ghi nhận vấn đề sau khi nó xảy ra, mà còn thấy được xu hướng và phản ứng trước khi sự suy giảm của nhóm dẫn đến việc chặn tài khoản hoặc ngừng phân tích.
Việc lựa chọn loại proxy ảnh hưởng trực tiếp đến các chỉ số nào sẽ được ưu tiên: đối với các nhiệm vụ có độ nhạy cao đối với việc bị chặn, chẳng hạn như đa tài khoản trên Instagram hoặc TikTok, nên ưu tiên theo dõi độ bền của IP và tỷ lệ thành công, sử dụng proxy cư trú để tối đa hóa sự tương đồng với lưu lượng thực của người dùng. Đối với các nhiệm vụ mà tốc độ và khối lượng là quan trọng — phân tích hàng loạt Ozon, Avito hoặc Yandex.Market — độ trễ và băng thông trở thành ưu tiên hàng đầu, và ở đây thường hiệu quả hơn khi sử dụng proxy trung tâm dữ liệu nhờ vào khả năng truyền tải cao hơn.