代理池可观测性：指标、日志、告警与快速诊断

想象一下值班工程师一个典型的早晨。聊天窗口弹出一条消息：“我们这边全都卡了”。到底是什么卡了？是整个池子还是某个切片？是某个国家的代理还是某个运营商的代理？是目标网站响应慢还是重试队列在增长？没有数据，这就不是故障，而是瞎猜。而当团队在瞎猜的时候，时间在流逝，钱也在流失。

这篇文章讲的是如何把“卡了”这种模糊的感觉，在一分钟内变成精确的诊断。我们会拆解：围绕代理池该收集哪些指标，每个请求的日志里该写什么、绝对不能写什么，为什么百分位数比平均值更重要，如何按维度对数据打标签，以及如何配置不会因为误报把你半夜吵醒的告警。文章最后有快速响应表和实用FAQ。

关于主题边界的重要说明。这里我们只讲测量与告警。为每个请求选择具体IP、节点健康检查以及池内隔离逻辑是另一个大话题，有专门的材料来讲。这里我们的任务更聚焦：发现退化、定位问题并适时发出警报。示例中使用的是Proxeon基础设施，但原理是通用的。

基础：什么是可观测性，为什么代理尤其需要它

从根本讲起。可观测性（observability）是系统的一种属性：通过其外部输出数据就能理解内部状态，无需用调试器深入内部。经典的可观测性三件套是：指标、日志和链路追踪。指标回答“总体上发生了什么”，日志回答“某个具体请求到底出了什么事”，链路追踪回答“请求是如何走完整个链路的”。

代理和普通Web服务有什么区别？区别在于你有一个无法完全掌控的第三方：代理节点本身、到它的通道以及它背后的目标资源。普通应用可以剖析到最后一层函数。而代理增加了一层网络不确定性，退化可能来自任何地方：来自运营商、来自路由、来自某个节点的过载、来自目标网站行为的变化。

正因如此，围绕代理池的可观测性不是奢侈品，而是卫生习惯。没有它，你就是在盲操作。有了它，你就能看清问题的结构：不是“全都不好”，而是“某个地区某个运营商的移动代理切片退化了，其余正常”。这就是恐慌与外科手术式精确之间的差别。

问题存在的三个层级

从一开始就把退化产生的三个层级记在心里很有用：

• 传输层：到代理的通道、丢包、连接建立时间。超时和慢TTFB就住在这里。
• 代理节点层：某个IP过载、额度耗尽、运营商那边出问题。某个切片错误率上升就住在这里。
• 目标资源层：网站响应变慢、返回非标准状态码、更改了限制。这里重要的是别把网站的问题和池子的问题搞混。

好的可观测性系统让你一眼就能看出问题出在这三个层级中的哪一个。这正是我们做这一切所追求的那“一分钟出诊断”。

代理的四个信号：为什么是它们

有一种诱惑是把所有东西都收集起来。几百个指标、几十个仪表盘、成公里的图表。这是个陷阱。指标多意味着噪音，而噪音意味着出故障时你找不到需要的东西。成熟的工程实践说的正相反：从覆盖大多数问题的最小信号集开始。对于代理池，这样的信号有四个。

信号一：请求成功率

请求成功率（success rate）是预期完成请求占总请求的百分比。这是健康度的主要指标。如果成功率下降，说明此刻有东西坏了，而且直接影响用户。

关键问题：什么算成功？天真的答案“状态码200”是不对的。更正确的做法是通过你的使用契约来定义成功。通常成功包括所有2xx和3xx，以及那些作为目标资源有效响应而非代理问题的有意义的4xx。而超时、连接中断、代理层错误以及大量5xx则是失败。

严格来说，成功率属于SLI（Service Level Indicator，服务水平指标）模型中的“可用性”指标族。正是这个指标，之后会围绕它构建SLO（服务水平目标）和错误预算。

信号二：按百分位数衡量的延迟

延迟（latency）是从发送请求到收到响应的时间。但单一的延迟数字毫无意义。需要的是百分位数：p50、p95、p99。为什么是百分位数而不是平均值，我们会在单独一节详细拆解，因为这是整个监控中最被低估的话题之一。

对代理而言，TTFB（Time To First Byte，首字节时间）尤其有价值。它把网络延迟和服务器响应时间与响应体的传输时间分开。如果TTFB上升，那是网络或节点的问题。如果总时间上升但TTFB稳定，可能是响应变大了，或者通道吞吐量下降了。

信号三：重试率

重试率（retry rate）是需要再次尝试的请求的百分比。这是灾难的早期预兆。通常成功率还在正常范围，因为重试把局面撑住了，但重试率已经悄悄爬升。这就像体温37.2度：形式上还能工作，但身体已经在抗争了。

重试对终端用户掩盖了退化，但吞噬资源：时间、流量、池子容量。忽视这个信号危险加倍，因为重试增长可能雪崩式地压垮系统——重复请求会给本就过载的节点再添负担。

信号四：流量消耗

流量消耗（bandwidth）是传输的数据量。为什么它属于四大信号？首先，这是真金白银，因为流量是计费的。其次，异常消耗是个信号：突然增长可能意味着有人在拉多余的东西、响应变大了，或者重试在反复传输同样的数据。在通常有活动的切片上流量突然降到零，意味着该切片彻底停止工作了。

这四个信号并非偶然。它们与可靠性工程师推广的可观测性“黄金信号”方法论相呼应：延迟、流量、错误、饱和度。我们把它适配到代理的特殊性上，其中重试作为一个该领域独有的预兆值得单独占一席之地。

深入探讨：每个请求的日志里该写什么

指标展示趋势。但当需要理解某个具体请求发生了什么时，日志能救命。设计良好的请求日志是你的黑匣子，排查故障时会去翻它。我们来拆解哪些必写、哪些绝对不能写。

必写的内容

• 代理标识符：不是明文IP，而是节点或池的稳定标识符。这能把请求关联到具体资源，看出哪些节点在出问题。
• 响应码：HTTP状态码或传输错误码（超时、连接拒绝、中断）。这是计算成功率的基础。
• 首字节时间（TTFB）：以毫秒计。定位网络问题时最信息丰富的指标之一。
• 请求总时间：从开始到结束，也以毫秒计。
• 响应大小：以字节计。为流量指标提供数据，帮助发现异常大或空的响应。
• 尝试次数：这是首次尝试还是重试，是第几次。没有这个字段就无法计算重试率。
• 用于打标签的维度：国家、运营商、代理类型。它们有单独一节，但日志里必须有。
• 时间戳和链路追踪ID：用来把记录彼此关联，并和外部系统关联起来。

下面是一条JSON格式结构化日志的样子。注意：它是机器可读的，这对后续分析至关重要。

{"ts":"2026-02-14T08:12:33Z","trace_id":"a1b2c3","proxy_id":"pool7-node042","country":"RU","carrier":"op-a","proxy_type":"mobile","status":200,"ttfb_ms":187,"total_ms":342,"bytes":20481,"attempt":1,"outcome":"success"}

绝对不能写的内容

这一点和该写什么同样重要。日志会泄漏、会被复制到分析系统、会进入备份。你放进去的任何东西都会长期存在于意想不到的地方。

• 凭据：代理的用户名、密码、授权令牌、API密钥。永远不要。即使部分也不行。即使“临时调试”也不行。
• 完整的响应体：首先数据量巨大，其次里面可能有个人和敏感数据。只写大小，必要时写哈希或短签名。
• 含机密的请求头：Authorization、Cookie、Set-Cookie等。写入前必须清理干净。
• 含敏感参数的完整URL：如果查询字符串里有令牌或个人标识符，必须做脱敏。
• 用户个人数据：所有受个人数据法规约束的内容，要么不进日志，要么做匿名化处理。

在日志生成阶段脱敏的实用方法：

def sanitize(entry):  secret_keys = {"authorization", "cookie", "set-cookie", "proxy-authorization"}  headers = {k: ("***" if k.lower() in secret_keys else v) for k, v in entry.get("headers", {}).items()}  entry["headers"] = headers  entry.pop("body", None)  entry.pop("proxy_credentials", None)  return entry

黄金法则：日志要能诊断问题，但不能变成泄漏机密的数据库。如果犹豫某个字段要不要写，就别写。诊断价值几乎总可以通过安全的替代物获得：哈希、大小、标志、类别。

用百分位数代替平均值：为什么平均值会掩盖问题

这一节值得读两遍。因为这里藏着性能监控中最常见也最阴险的错误。

为什么平均值会骗人

想象一下：你有100个请求。其中99个在100毫秒内完成，1个用了10秒。平均时间大约是199毫秒。看起来很棒，几乎没变化。可与此同时，你有一位用户等了10秒，而且很可能已经骂骂咧咧地离开了。

平均值是一台把离群值抹平到整个样本里的机器。它对极值敏感，但对分布结构不敏感。而网络系统的性能几乎总是长尾分布：大多数请求很快，但有少数非常慢。正是这个长尾决定了真实的用户体验和问题的存在与否。

什么是百分位数，怎么读

百分位数是低于该值的观测值占给定百分比的那个数。我们来拆解三个主要的：

• p50（中位数）：一半请求比这个值快，一半比它慢。这是“典型”体验。
• p95：95%的请求在这个时间内完成。这是“接近最坏情况”的体验，影响到相当比例的用户。
• p99：99%的请求比它快。这就是那个长尾，超时、重试和愤怒用户都住在这里。

在我们100个请求的例子里，p50和p95会保持在100毫秒左右，而p99会跳到10秒。百分位数诚实地展示了平均值藏起来的问题。这就是为什么有经验的工程师首先看p95和p99，而几乎不用平均值来评估延迟。

如何正确计算百分位数

天真的做法是收集所有值、排序、取对应位置。它精确，但不可扩展：在数百万请求面前，存下整个数组是不可能的。实践中使用近似计算的結構：固定分桶的直方图，或t-digest、HDR直方图之类的专门算法。

直方图的思想很简单：提前定义好时间区间（桶），只统计有多少请求落入每个桶。根据累积计数就能以可接受的精度还原任意百分位数，而内存开销是固定的。

import bisectclass PercentileTracker:  def __init__(self):    self.buckets = [10, 25, 50, 100, 200, 500, 1000, 2000, 5000]    self.counts = [0] * (len(self.buckets) + 1)  def add(self, ms):    i = bisect.bisect_left(self.buckets, ms)    self.counts[i] += 1  def percentile(self, p):    total = sum(self.counts)    if total == 0:      return None    target = total * p / 100    acc = 0    for i, c in enumerate(self.counts):      acc += c      if acc >= target:        return self.buckets[min(i, len(self.buckets) - 1)]    return self.buckets[-1]

关于聚合的一个重要警告。百分位数不能求平均。如果你有十个节点各自的p95，你不能把这十个p95取平均然后称之为总p95。这在数学上是错误的。正确聚合需要把直方图相加，再从总直方图中计算百分位数。正因如此，现代监控系统存储的是直方图，而不是现成的百分位数。

按维度打标签：看切片，而不是整个池子

这里是可观测性从图表变成诊断工具的时刻。一个全池的成功率数字告诉你的很少。它可能是97%看起来还正常，却掩盖了某个切片跌到40%，而其他切片在拉高平均值。

代理的三个关键维度

• 国家（country）：代理的地理位置。退化常常在地理上被局部化：某个地区的路由问题、目标资源对某些国家的行为变化。
• 运营商（carrier）：对Proxeon的移动代理来说，这是关键维度。特定运营商的问题会恰好在这里显现出来，你能立刻明白它的规模。
• 代理类型（proxy_type）：移动、服务器、住宅。不同类型行为不同，一种类型的退化不应淹没在大堆数据里。

基数：在哪里停下

有一种冲动是给所有东西打标签：每个IP、每个目标域名、每个用户。这会导致基数爆炸——标签唯一组合的数量。高基数会杀死监控系统：存储量增长、查询变慢、基础设施变贵。

实用规则：只按取值有限且稳定的维度打标签。国家几十个，运营商几个到几十个，代理类型几个。这是安全的。而单独的IP或完整URL不能用作指标标签——它们数量巨大且唯一。这类细节属于日志，那里它们是按行存储的，而不是在指标里成倍增加数据序列。

from prometheus_client import Counter, Histogramrequests_total = Counter(  "proxy_requests_total",  "Total proxy requests",  ["country", "carrier", "proxy_type", "outcome"])latency_ms = Histogram(  "proxy_latency_ms",  "Request latency",  ["country", "carrier", "proxy_type"],  buckets=[10, 25, 50, 100, 200, 500, 1000, 2000, 5000])def record(country, carrier, ptype, outcome, ms):  requests_total.labels(country, carrier, ptype, outcome).inc()  latency_ms.labels(country, carrier, ptype).observe(ms)

有了这样的标签，你可以在几秒内构建查询：显示过去一小时按运营商分组的成功率。然后立刻看到退化的不是整个池子，而是某个切片。这就是定位。这个方法的美妙之处在于，它把“全都坏了”的恐慌变成了平静的“运营商Y的切片X需要关注”。

不吵闹的告警

团队不再信任监控最常见的原因就是告警太吵。当系统一晚上因为误报把你叫醒五次，你很快就会开始忽略它。然后你就会错过真正的故障。这叫做告警疲劳，它比完全没有监控更有效地杀死可观测性。

安静告警的三个原则

原则一：对症状而非原因设阈值。告警应该针对用户能感受到的东西：成功率下降、p99延迟上升。而不是针对那些本身不意味着问题的中间技术波动。

原则二：观察窗口。不要对单一尖峰做出反应。一个慢请求是噪音。在一段时间窗口内持续偏离才是信号。配置告警在条件持续比如五分钟时才触发，而不是某一瞬间。

原则三：滞回。这是一个借自工程学的术语，意思是触发和解除用不同的阈值。当成功率低于90%时告警点亮，但只有当它升到95%以上时才熄灭。阈值之间的间隔防止了“抖动”——指标在某个值附近摇摆时告警闪烁开关。

告警配置示例

下面是一个大多数监控系统都能理解的风格写的规则示例。如果任一运营商切片的成功率在观察窗口内持续低于阈值，它就会触发。

groups:- name: proxy-health  rules:  - alert: LowSuccessRateByCarrier    expr: |      sum by (carrier) (rate(proxy_requests_total{outcome="success"}[5m]))      /      sum by (carrier) (rate(proxy_requests_total[5m]))      < 0.90    for: 5m    labels:      severity: warning    annotations:      summary: "Success rate below 90 percent for carrier"

严重级别与路由

不是所有告警都平等。按严重程度分开：

• Warning：有东西偏离了，值得在工作时间看一下。不夜间叫醒。
• Critical：用户此刻正在受影响，需要立即响应。叫醒值班人员。

起步的合理集合只包括几个告警：整体成功率临界下降、按切片的成功率退化、p99延迟急剧上升、重试率异常飙升。不要更多。每个新告警都是一个承诺——会有人对它做出反应。不要许下你无法兑现的承诺。

作为框架的错误预算

一种进阶做法是：不用针对瞬时值的硬阈值，而使用错误预算。如果你的目标是每月99%的成功请求，那么错误预算就是那你可以“花掉”的1%。针对预算消耗速度（burn rate）的告警，反应的不是单次失败的事实，而是你在过快地消耗允许的错误限额。这类告警平静得多，也更准确地反映对SLO的真实威胁。

通过仪表盘快速诊断：三种典型画面

现在是最有意思的部分。如何在一分钟内弄清楚退化在哪里？答案是把眼睛训练出对几种典型模式的识别能力。好的仪表盘不是图表垃圾场，而是模式识别工具。我们来拆解三种经典画面。

画面一：一个切片崩了，其余正常

你看按运营商分组的成功率。总体略降，但看细分就很清楚：一个运营商跌到50%，其余保持在98%。问题切片的延迟上升，其余稳定。

这意味着什么：节点或运营商层面的局部问题。原因不在你的系统，也不在目标资源整体，而在池子的特定切片。是传输或节点本身的问题。

第一动作：把问题切片移出活跃轮换（这是隔离的领域，另一个话题），继续观察。检查退化是否与运营商内部某个具体地区有关。

画面二：延迟到处都在涨，但没有错误

成功率稳定，接近100%。但p95和p99延迟在所有切片上同时均匀上升。重试率略有增长。

这意味着什么：当所有东西同时均匀退化时，去找共同因素。通常要么是你自己的基础设施（过载、资源不足、代码瓶颈），要么是目标资源对所有人响应变慢了。代理节点在这里不是原因，否则退化会是不均匀的。

第一动作：单独看TTFB。如果TTFB上升，是网络或服务器。如果TTFB稳定但总时间增长，问题在传输或响应体处理。检查你这边的负载和目标资源的指标。

画面三：成功率稳定但重试率在涨

成功率看起来正常，约97%。但重试率在爬升：从3%变成15%。延迟也涨了，因为重试增加了时间。

这意味着什么：这是最阴险的模式，因为最终结果还在正常范围。但系统在极限运行：它花越来越多的重试来维持成功率。这是崩溃的前兆。如果趋势继续，重试将不再能挽救，成功率会暴跌。

第一动作：不要等成功率崩溃。找出哪个切片的重试在增长（还是按维度细分），在来得及之前弄清楚根因。检查是不是重试本身在制造额外负载，把螺旋越拧越紧。

一分钟诊断的仪表盘布局

为了让这些模式能在一分钟内读懂，主屏上只放四块面板，对应四个信号，每块都能快速按维度细分：

1. 成功率：整体以及按运营商和国家细分。
2. 延迟：p50、p95、p99在一张图上，能看到尾部发散。
3. 重试率：最近几小时的趋势。
4. 流量消耗：按切片，捕捉异常。

其余都是次要的，放在单独屏幕上。主屏应该回答一个问题：一切正常吗，如果不正常，具体在哪里。不要多余的东西。

快速响应表：指标、它的上升与第一动作

这张表值得打印出来贴在值班人员工位旁边。它把观察变成行动，无需多余思考。

指标：成功率下降（整个池子）

意味着什么：影响大多数请求的大规模故障。系统级问题。
第一动作：检查你自己的基础设施和目标资源，因为均匀下降很少来自单个节点。

指标：成功率下降（某个切片）

意味着什么：运营商、国家或代理类型的局部退化。
第一动作：按细分定位切片，把它移出轮换，观察动态。

指标：p99延迟上升而p50稳定

意味着什么：尾部变长，部分请求变得非常慢，而典型请求正常。
第一动作：找到尾部增长所在的切片，检查超时和产生尖峰的节点。

指标：p50和p95同时均匀上升

意味着什么：整体性能退化，可能是基础设施或目标资源。
第一动作：把TTFB和传输体时间分开，检查你这边的负载。

指标：成功率稳定而重试率上升

意味着什么：系统用重试掩盖退化，是崩溃的前兆。
第一动作：找到重试增长所在的切片，在成功率崩溃前消除根因。

指标：流量消耗异常增长

意味着什么：响应膨胀、多余重试或计划外活动。
第一动作：把流量增长与请求数和响应大小对照，找到来源。

指标：活跃切片流量消耗降为零

意味着什么：切片完全停止服务请求。
第一动作：检查切片节点的可用性和连通性，确认后升级。

代理可观测性的典型错误

拆解几十个故障的经验让我们收集到一份最常踩的坑。了解这些错误能省下几个月的痛苦。

错误1：看平均值而不是百分位数

我们已经拆解过，但要重复，因为错误太普遍了。平均响应时间不显示长尾问题。团队看到稳定的平均值便确信一切正常，直到用户抱怨卡顿。永远看p95和p99。

错误2：“临时调试”时记录机密

临时的东西有变成永久的习惯。“检查五分钟”记录下的令牌会在日志存储系统里沉淀几个月，还进入备份。机密脱敏应该是日志库层面的硬规则，而不是每个开发者当下的决定。

错误3：标签基数爆炸

给指标按每个IP或URL打标签看起来很舒服，直到监控系统开始喘不过气、要求越来越多资源。标签只用于取值有限的一组维度。细节进日志。

错误4：告警太多

团队为自己的监控自豪，配置了四十个告警。一个月后一半在吵，值班人员在通知里把它们关了，然后有一天错过了真正的故障，因为它淹没在信息流里。告警少一些，但要更准。

错误5：告警没有窗口和滞回

告警对瞬时值触发又立刻熄灭，然后又触发。通知抖动令人烦躁，也让系统贬值。观察窗口和滞回是必须的。

错误6：只把状态码200算作成功

这样要么低估成功率，把有效响应算作失败，要么反过来，漏掉问题。通过使用契约有意义地定义成功，而不是机械地按一个状态码。

错误7：没有按维度细分

一张总体成功率图掩盖了局部问题。没有细分，你看到的是“总体还行”，就错过了崩掉的切片。打标签不是选项，而是必需。

错误8：忽视重试

很多人根本不统计重试率，只依赖最终成功率。于是失去了最早的预兆。等到成功率下降时，重试早已在喊问题了。

错误9：存百分位数而不是直方图

如果你保存的是各切片现成的p95，你就无法正确计算总体p95，因为百分位数不能相加。存直方图，查询时计算百分位数。

错误10：仪表盘当成垃圾场

一屏五十块面板不是可观测性，而是信息噪音。故障时刻眼睛会迷失。主屏极简，细节点击展开。

工具与资源

好消息是：围绕代理池做好可观测性不需要昂贵复杂的栈。我们来拆解最小充分的集合和选择逻辑。

指标采集与存储

指标方面，基于时间序列模型、支持标签和直方图的系统非常合适。关键要求是支持直方图以正确计算百分位数，以及按维度打标签而不炸掉基数。这类系统能实时做“按运营商看一小时成功率”这样的查询。

可视化

仪表盘工具需要能画时间序列图、把多个百分位数叠加在一张图上、快速切换维度细分。能做变量过滤器很重要：选了某个运营商，所有面板都跟着重建。这能把诊断速度加快好几倍。

日志采集与存储

请求日志应该是结构化的（JSON），并进入能按字段过滤的系统：按代理标识符、按响应码、按切片。强制要求是带自动到期删除的保留策略，避免敏感数据永久累积。

告警

告警系统必须支持观察窗口（条件持续N分钟）、严重级别和按渠道路由。对错误预算消耗速度的告警支持尤其有价值，能带来平静而精确的触发。

代码插桩库

在代理客户端代码里使用支持带标签计数器和直方图的指标库。把每个请求包裹进测量：记录开始时间，完成时记录结果、延迟和流量。插桩应该集中在一处，让新开发者不会偶然漏掉。

import timedef instrumented_request(client, url, meta):  start = time.monotonic()  attempt = meta["attempt"]  try:    resp = client.get(url)    elapsed = (time.monotonic() - start) * 1000    outcome = "success" if resp.status_code < 500 else "server_error"    record(meta["country"], meta["carrier"], meta["type"], outcome, elapsed)    log_request(meta, resp.status_code, elapsed, len(resp.content), attempt, outcome)    return resp  except TimeoutError:    elapsed = (time.monotonic() - start) * 1000    record(meta["country"], meta["carrier"], meta["type"], "timeout", elapsed)    log_request(meta, None, elapsed, 0, attempt, "timeout")    raise

2026年趋势

2026年可观测性行业正朝几个显著方向发展。第一，基于开放协议的遥测标准化，简化指标、日志和链路追踪整合为统一视图。第二，对指数直方图的兴趣增长，以最少内存提供精确百分位数。第三，基于统计模型的自动异常检测的应用，补充阈值告警，发现无法预先设定阈值的异常模式。第四，焦点从收集数据数量转向其意义：更少的指标，但更正确。这正是我们在本文中所讲的。

案例与结果

为了让原则有血有肉，我们来拆解几个基于代理池典型运维实践构建的概括场景。数字是说明性的，但模式是真实的。

案例1：一个运营商的隐形退化

团队使用Proxeon的移动代理池，依赖总体成功率。指标保持在96%左右，没有警报。同时某个方向的用户抱怨故障。引入按运营商细分后画面瞬间清晰：一个运营商成功率62%，其余约99%。总体数字掩盖了整个切片的崩溃。

结果：加入按运营商的标签和针对切片退化的告警后，这类问题的发现时间从几小时（靠投诉）缩短到几分钟（靠告警）。问题切片得以及时移出轮换，该方向总体成功率升到98%。

案例2：被平均值藏起来的长尾

另一个团队监控平均延迟，一直保持在舒适的240毫秒。周期性的“卡顿”投诉被归结为挑剔。切换到百分位数后大开眼界：p50确实约190毫秒，但p99达到8秒。每第100个请求都慢得让人难受。

结果：团队开始关注p99并配置了它上升的告警后，发现尾部是由峰值时段对某组节点的请求产生的。按细分定位了问题。p99成功降到1.2秒，卡顿投诉几乎降为零。

案例3：重试螺旋

第三个场景因其危险性而典型。采用激进重试策略的系统把成功率维持在97%左右，一切看似稳定。但没人关注重试率。有一天在轻微负载尖峰下，重试率半小时内从5%涨到40%。重复请求增加了负载，节点过载更严重，重试更多——经典螺旋。一小时后成功率暴跌到60%。

结果：故障复盘导致引入了单独的重试率指标和针对其增长的早期告警。现在当重试率达到阈值时，团队会在成功率崩溃前很久收到预警。类似情况开始能在预兆阶段被捕获，不会演变成事故。这直观地说明了为什么重试值得在四大信号中占有一席之地。

案例的共同结论

三个故事，三个不同的问题，但一个共同规律。在所有情况下，用于发现问题的数据其实都物理存在于系统中，只是没有以让问题可见的方式呈现。按维度细分、用百分位数代替平均值、关注重试，这些不是抽象建议。它们是具体的透镜，每一个都让某一类问题变得可见。

FAQ：关于代理可观测性的常见问题

如果现在什么都没有，从哪里开始？

从以结构化形式记录每个请求开始，必填字段：代理标识符、响应码、TTFB、大小、尝试次数、维度。即使没有指标和仪表盘，这已经让你能排查故障。下一步添加四个指标和一两个关键告警。不要试图一次建成所有东西——最小可工作集合比完美但未完成的更有价值。

指标应该多久采集一次？