4. 检测时间（TTD）口径定义：从故障发生到告警触发
检测时间（Time to Detect, TTD）是衡量可观测性系统“感知速度”的核心指标。在 Prometheus 存储瓶颈场景中，TTD 过长往往意味着告警延迟、数据丢失或查询超时未被及时捕获。本节将严格定义 TTD 的检测起点与终点，并给出排除噪声的标准化口径。
4.1 TTD 核心定义与边界
| 维度 | 定义 | 示例（Prometheus 存储瓶颈） |
|---|---|---|
| 检测起点 | 故障实际发生的首个时间点（T₀） | WAL 写入延迟突增 > 1s 的瞬间 |
| 检测终点 | 告警规则首次触发并发送通知的时间点（T₁） | Alertmanager 收到 Watchdog 告警的时间 |
| TTD 值 | T₁ - T₀（单位：秒） | 120s（表示故障发生 2 分钟后才被感知） |
| 噪声排除 | 排除人为误报、测试流量、计划内维护窗口 | 过滤 maintenance_mode=1 标签 |
关键原则：TTD 只衡量“从真实故障到系统自动告警”的纯检测延迟，不包含人工响应、告警升级或工单创建时间。
4.2 检测起点（T₀）的精确锚定
在 Prometheus 存储瓶颈场景中，T₀ 通常由以下三类指标突变定义：
- 写入路径异常：
prometheus_tsdb_wal_write_duration_seconds的 p99 超过基线 3σ。 - 查询路径异常：
prometheus_tsdb_head_series突降 > 20%（可能因内存压力导致 series 被驱逐）。 - 存储层异常：
prometheus_tsdb_compactions_failed_total在 1 分钟内增量 > 0。
为避免因短时毛刺导致误判，T₀ 采用 “持续异常确认” 规则：
# 示例：PromQL 定义 T₀ 触发条件
# 当 WAL 写入延迟连续 3 个 scrape_interval 超过 1s 时，标记 T₀
rate(prometheus_tsdb_wal_write_duration_seconds_sum[1m])
/
rate(prometheus_tsdb_wal_write_duration_seconds_count[1m])
> 1.0
# 且持续 3 个样本点（约 45s）4.3 检测终点（T₁）的标准化
T₁ 必须是告警规则 状态从 Pending 转为 Firing 的时间戳，而非告警在 Alertmanager 中被抑制或静默的时间。标准定义如下：
| 告警阶段 | 是否计入 T₁ | 说明 |
|---|---|---|
| 规则评估（Evaluation） | 否 | 仅计算指标值，未触发阈值 |
| Pending（等待 for 时长） | 否 | 处于抖动消除窗口，尚未确认 |
| Firing（触发） | 是 | 告警已确认并发送至 Alertmanager |
| Alertmanager 通知 | 否 | 通知延迟属于 MTTA 范畴 |
实践建议：在 Prometheus 告警规则中增加
ALERTS_FOR_STATE 记录，通过 ALERTS{alertstate="firing"} 的 __timestamp__ 精确获取 T₁。
4.4 噪声排除策略
为保证 TTD 口径的纯净度，必须过滤以下三类噪声：
- 计划内维护：通过标签
maintenance_window=true或时间窗口（如每周二 02:00-04:00）排除。 - 测试/演练流量：过滤
test_alert=1或source="chaos-engineering"的告警。 - 重复告警风暴：同一故障源在 5 分钟内产生的重复告警仅计首次 TTD。
# 噪声排除 PromQL 示例（在记录规则中预过滤）
# 排除维护窗口和测试标签后的有效告警
ALERTS{alertstate="firing", maintenance_window!="true", test_alert!="1"}
# 使用 group_left 关联故障源去重4.5 TTD 检测流程与时间线
下图展示了从故障发生到告警触发的完整时间线，以及 TTD 在其中的精确位置：
4.6 TTD 口径在复盘中的实际应用
在 Prometheus 存储瓶颈 MTTR 复盘中，TTD 口径直接决定“感知延迟”的归因方向：
- TTD > 5 分钟：优先检查告警规则评估间隔（
evaluation_interval）是否过长，或for窗口设置过大。 - TTD > 15 分钟：大概率存在 Prometheus 自身资源瓶颈（如 WAL 写入阻塞导致指标采集延迟）。
- TTD 为 0 或负值：说明时间戳同步异常，需检查节点时钟偏移或 Prometheus 时间戳回拨问题。
常见陷阱：不要将 Alertmanager 的“分组等待时间”（
group_wait）计入 TTD。该延迟属于告警路由策略，应归入 MTTA 而非检测阶段。
4.7 标准化口径检查清单
| 检查项 | 标准 | 验证方法 |
|---|---|---|
| T₀ 定义 | 连续 3 个样本点超过阈值 | PromQL count_over_time(...)[3m] |
| T₁ 定义 | 告警状态转为 Firing | ALERTS{alertstate="firing"} |
| 噪声过滤 | 排除维护/测试/重复告警 | 标签过滤 + 5min 去重窗口 |
| 时间戳精度 | 毫秒级，统一使用 Prometheus 时间戳 | timestamp() 函数校验 |
| 口径文档化 | 在告警规则注释中标注 TTD 口径 | 查看 ALERTS.annotations |
通过以上标准化定义，团队可以在每次存储瓶颈复盘时，基于统一的 TTD 口径快速定位“感知延迟”的根因，避免因口径不一致导致的归因偏差。