如果代理在生产环境中使用——用于解析、自动化 SMM 账户或大规模多账户操作——迟早会出现“看起来正常”不再是足够的回答。需要数字:有多少请求出现错误,切换 IP 池后延迟增加了多少,供应商的流量限制是否已用尽。我们讨论 7 个应该在 Prometheus 中收集并在 Grafana 中可视化的指标,以便在用户或被封禁账户发现问题之前就能看到问题。
为什么要监控生产环境中的代理
代理并不是像固定 IP 服务器那样的静态基础设施。这是一个不断变化的地址池,其行为取决于供应商、负载、地区甚至是一天中的时间。没有监控,您只会在 Wildberries 或 Ozon 的解析器停止返回数据、Facebook Ads 广告账户被封禁,或 Instagram 自动化脚本开始出现验证码时才会得知问题。
监控的任务是将主观的“有什么不对劲”转变为具体的数字:在过去一小时内,错误比例从 2% 上升到 15%,平均延迟增加了三倍,某个代理的流量超过了限制。这使得在问题变得严重之前就能作出反应——自动切换池、替换供应商或降低请求频率。
为了收集指标,我们使用 Prometheus(时间序列存储)和 Grafana(可视化和警报)的组合。这是 DevOps 中的标准堆栈,可以轻松与任何语言集成——Python、Node.js、Go。下面是使用 prometheus_client 库的 Python 示例,但原理是通用的。
指标 1:成功率 — 成功请求的比例
这是一个基本指标,首先会对代理池的问题发出信号。计算方式是将响应代码为 200-299 的请求与一段时间内的总请求数进行比较。成功率下降到 90% 以下通常意味着池中的部分 IP 被目标网站封禁,或者供应商提供的不稳定地址。
Python 中的工具示例:
from prometheus_client import Counter, start_http_server
import requests
REQUESTS_TOTAL = Counter(
'proxy_requests_total', '通过代理的总请求数',
['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) # Prometheus 抓取的端点
计算过去 5 分钟成功率的 PromQL 查询:
sum(rate(proxy_requests_total{status="success"}[5m]))
/
sum(rate(proxy_requests_total[5m])) * 100
如果您同时使用多种类型的代理——例如,住宅代理 用于社交媒体和 数据中心代理 用于解析——将成功率按标签 proxy_pool 进行拆分是有意义的,以便查看哪个池正在退化。
指标 2:延迟 — 响应延迟
延迟显示代理返回响应的速度。延迟的急剧上升通常会在成功率下降之前发生——供应商过载,或者 IP 已接近被封禁,目标服务器开始故意减慢响应。对于延迟,重要的是收集不仅是平均值,还有百分位数——p50、p95、p99,因为平均值掩盖了真正影响工作的尾部延迟。
from prometheus_client import Histogram
import time
REQUEST_DURATION = Histogram(
'proxy_request_duration_seconds',
'通过代理的请求持续时间',
['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)
p95 延迟的 PromQL 查询:
histogram_quantile(0.95,
sum(rate(proxy_request_duration_seconds_bucket[5m])) by (le, proxy_pool)
)
对于速度至关重要的任务——例如,在自动化 TikTok Ads 时,每秒的页面加载时间都会增加在反检测浏览器中超时的风险——建议在 p95 超过 3-4 秒时设置警报。
指标 3:按错误类型划分的错误率
单纯的成功/失败不足以进行诊断。需要按类型划分错误:407(需要代理身份验证)表示授权问题,429(请求过多)表示请求限制超出,超时表示网络问题,403 表示目标网站因反机器人保护而被封禁。每种类型的错误需要不同的反应。
ERROR_BY_TYPE = Counter(
'proxy_errors_total', '按类型划分的代理错误',
['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"
常见错误及其原因的表格:
| 代码/类型 | 可能原因 | 检查内容 |
|---|---|---|
| 407 | 凭据错误或会话过期 | 代理的登录/密码,连接字符串格式 |
| 429 | IP 请求限制超出 | 请求频率,池的大小 |
| 403 | 目标网站的反机器人保护 | 用户代理、指纹、代理类型 |
| timeout | 供应商或网络过载 | 池的负载、客户端的超时设置 |
指标 4:IP 的轮换速度和存活时间
如果您使用轮换代理,了解 IP 更换的频率以及在地址“消失”(被目标网站封禁)之前能够通过多少请求是很重要的。这个指标对于多账户操作尤其关键——例如,通过 Dolphin Anty 或 AdsPower 进行 Facebook Ads 账户的批量创建,过早更换 IP 可能会中断会话并触发安全检查。
from prometheus_client import Gauge
IP_LIFETIME = Gauge(
'proxy_ip_lifetime_seconds', 'IP 的生命周期直到轮换',
['proxy_pool']
)
IP_REQUESTS_BEFORE_BAN = Histogram(
'proxy_requests_before_ban',
'在 IP 被封禁之前通过的请求数',
['proxy_pool'],
buckets=[10, 50, 100, 500, 1000, 5000]
)
对于移动代理,这个指标的表现与住宅代理不同——通过更换运营商的基站进行轮换可以提供更“干净”的 IP,封禁的可能性较小。如果您的任务是 SMM 自动化,并且对封禁高度敏感,建议在您的仪表板中比较 移动代理 和住宅代理之间的 IP 存活率,而不是依赖一般建议。
指标 5:带宽 — 流量消耗
大多数代理的定价是根据流量而不是请求数量来计算的。没有监控,很容易错过流量限制即将用尽的时刻——尤其是在任务涉及加载图像或视频时,例如在解析 Wildberries 的产品卡片时,图像数量较多。
BANDWIDTH_USED = Counter(
'proxy_bandwidth_bytes_total', '通过代理消耗的流量',
['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)
在 Grafana 的仪表板上,构建流量的消耗速率(rate)而不是绝对流量值是有用的——这有助于预测何时流量限制将用尽,并提前计划购买或切换到其他池。
指标 6:地理分布和区域匹配
对于测试来自不同国家的广告的营销人员,以及在 Google Ads 或 TikTok Ads 中进行地理定位的套利者,确保 IP 实际上与声明的区域相匹配是至关重要的。地理定位错误可能导致广告展示给错误的受众或因地理设置不匹配而封禁账户。
GEO_MISMATCH = Counter(
'proxy_geo_mismatch_total',
'声明的地理位置与实际地理位置不匹配的情况',
['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()
建议不要在每个请求中检查地理位置(这在流量和时间上都很昂贵),而是定期检查——每小时对池中的 IP 进行一次抽样,以确保统计上的可靠性。
指标 7:并发连接 — 并行会话
通过代理的并发连接数显示了池的实际负载。如果并行会话的数量超过池中 IP 能够处理而不降低性能的数量,这将直接导致前面提到的延迟和错误率的上升。这个指标在扩展时尤其重要——当 SMM 代理机构将客户的同时工作账户数量从 10 增加到 50 时。
from prometheus_client import Gauge
ACTIVE_CONNECTIONS = Gauge(
'proxy_active_connections', '当前通过代理的活跃连接',
['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()
在 Grafana 中将此指标与错误率在同一图表中进行比较,可以迅速显示出相关性:一旦并行会话的数量超过某个阈值,错误就会开始非线性增长。
在 Grafana 中设置仪表板:逐步指南
在指标被工具化并且 Prometheus 收集它们之后,需要在 Grafana 中可视化数据。操作步骤:
- 将 Prometheus 添加为数据源:配置 → 数据源 → 添加数据源 → Prometheus,指定您的 Prometheus 服务器的 URL(通常是
http://localhost:9090)。 - 创建新的仪表板:创建 → 仪表板 → 添加新面板。
- 对于成功率面板,使用指标 1 部分中的 PromQL 查询,视觉化类型为 Gauge 或时间序列。
- 对于延迟,创建一个类型为热图的面板,以查看 p50/p95/p99 的时间分布。
- 对于错误率,构建堆叠条形图,并按标签
error_type进行拆分——这将清晰地显示出哪种类型的错误占主导地位。 - 为
proxy_pool添加仪表板变量(仪表板设置 → 变量),以便在不创建单独仪表板的情况下在池之间切换。 - 保存仪表板并设置每 30 秒自动刷新一次,以实现近实时监控。
可以通过分享 → 导出 → 保存到文件导出已完成的仪表板 JSON,并在不同的代理池(住宅、移动和数据中心)中重复使用,只需更改变量的值即可。
警报:何时采取行动
如果没有人查看仪表板,仪表板是无用的。因此,在 Grafana 中设置警报(警报 → 警报规则)是至关重要的,使用以下阈值,这些阈值适用于大多数生产场景:
| 指标 | 警报阈值 | 行动 |
|---|---|---|
| 成功率 | 低于 85% 在 5 分钟内 | 检查池,切换到备用池 |
| p95 延迟 | 超过 5 秒 | 降低并发,检查供应商 |
| 429 错误率 | 超过 10% 的请求 | 降低请求频率,增加 IP 池 |
| 带宽速率 | 预测在 24 小时内耗尽限制 | 购买流量或优化请求 |
最好通过 webhook 将警报发送到 Telegram 或 Slack——这确保了即时反应,而不是每天检查一次仪表板。
结论
七个指标——成功率、延迟、按类型划分的错误率、IP 存活时间、流量、地理匹配和连接竞争——提供了生产环境中代理基础设施健康的完整图景。Prometheus + Grafana 的组合不仅可以在事后记录问题,还可以看到趋势并在池的退化导致账户被封禁或解析停止之前作出反应。
代理类型的选择直接影响优先考虑哪些指标:对于对封禁高度敏感的任务,如 Instagram 或 TikTok 的多账户操作,首先应监控 IP 存活时间和成功率,使用 住宅代理 以最大程度地与用户的真实流量相似。对于速度和流量重要的任务——大规模解析 Ozon、Avito 或 Yandex.Market——延迟和带宽则成为首要考虑,这里通常数据中心代理 的表现更有效,因为它们具有更高的带宽。