可观测性EdgeSRE

过去我们在边缘节点的排障习惯是“先看日志，再猜原因”。这个方式在请求量较小的时候还勉强可行，但一旦进入多区域、多版本并行发布的状态，排障会迅速退化成体力活。

这次改造的目标是把系统从“可以观察”提升到“可以决策”：

1. 在 30 秒内判断故障是区域性、版本性还是上游依赖问题；
2. 在 5 分钟内给出可执行的回滚或降级动作；
3. 告警噪音降低到可值班的强度。

指标层：先建立统一语义

我们优先做的不是加更多图表，而是统一指标命名和维度。
例如把历史上混杂的 latency、response_ms、duration 统一为 request_duration_ms，并强制附带：

• region
• route
• build_id
• cache_status

这一步看起来枯燥，但它决定了后续所有联动查询是否可用。

日志层：从“文本堆”到“结构化事件”

日志不再直接拼字符串，而是统一 JSON 结构。
每条日志必须包含：

• trace_id
• span_id
• request_id
• user_agent_bucket
• degrade_mode

这样在告警触发时，我们可以从指标直接跳到同一批请求的结构化日志，而不是在全文检索里猜关键字。

追踪层：只追关键路径，不追一切

我们没有选择“全量追踪”，而是限定在高价值链路：

• 首页请求
• 搜索请求
• 项目详情页请求

每条链路只保留 3~5 个核心 span。
目标不是“看起来专业”，而是让值班同学在高压场景里一眼看懂。

告警层：可执行优先

告警模板从“现象描述”改为“动作建议”：

• 过去：p95 latency > threshold
• 现在：[region=HKG][build=2026.04.22.3] p95 +42%，建议先切换到缓存优先策略，再观察 3 分钟

这样当夜间告警触发时，处理流程可以从“开会讨论”变成“执行 playbook”。

结语

可观测性不是监控面板数量竞赛。
真正有价值的系统，应该在压力时刻帮助团队快速达成共识并做出动作。