![](https://developer.qcloudimg.com/http-save/yehe-9717043/3648943d6dadaf4da3c52ec9f0ed1d26.png)

假设一条告警告诉你：过去 5 分钟，某区域的 webhook 投递失败率从平时的 1% 升到了 8%。这是一个示意场景，但接下来的问题很具体：哪些目标失败了？涉及哪些账号？增加的是连接超时，还是鉴权错误？

Prometheus 已经发现了异常，调查却常常还要重新开始。打开日志系统，选择服务，调整时间，猜几个关键词。找到一条报错之后，还需要判断它与这次告警有什么关系。

最近整理日志与指标的埋点实践时，我觉得最值得分享的部分，就是如何缩短这段距离：**用低基数指标发现异常，用 Canonical log line 保存事件上下文，再把告警转换成一个可以继续修改的日志查询。** 点击告警，就能进入对应的事件集合，开始比较和验证。

这套思路需要先把统计单位说清楚。以 webhook 为例，一次投递尝试结束时，更新尝试次数和耗时指标；同时，对需要保留证据的尝试输出一条结构化完成日志。指标与日志复用同一份结果分类和耗时计算，避免两边分别判断“什么算失败”。

对应的 Prometheus 计数器可以保留这些维度。下面只是某条时间序列的标识，不是完整告警表达式：

```promql
webhook_attempts_total{service="notification", env="prod", region="cn-east", outcome="failure"}
```

同一次尝试的完成日志则保留更多上下文。字段和值仅作示例：

```json
{
  "timestamp": "2026-09-01T12:00:00Z",
  "event_name": "webhook.attempt.completed",
  "service": "notification",
  "env": "prod",
  "region": "cn-east",
  "outcome": "failure",
  "duration_ms": 3012,
  "account_id": "account-456",
  "destination": "endpoint-a",
  "attempt": 2,
  "delivery_id": "delivery-123",
  "error_type": "connect_timeout",
  "error": "connection timed out"
}
```

服务、环境、区域、结果在两边保持一致；账号、目标、执行身份和错误详情留在日志里。这样可以在排障时按高基数字段筛选和统计，又不必把这些字段全部变成指标标签。Prometheus 的每个不同标签组合都会形成独立时间序列，因此标签选择仍需控制。[Prometheus 指标与标签命名建议](https://prometheus.io/docs/practices/naming/)

Canonical log line 已有成熟实践，Stripe 也公开分享过这种方法：在一个工作单元结束时，把关键上下文集中到一条记录里。它很适合这里的需求，因为账号、结果、目标和耗时在同一行，统计前不必先把多层零散日志拼起来。[Stripe 的实践文章](https://stripe.com/blog/canonical-log-lines)

这里的 `completed` 表示尝试结束，包含成功和失败。一次尝试失败，也不代表最终投递失败；第二次尝试、最终投递结果必须有各自清楚的含义。子操作如果有独立排障价值，可以单独记录，通过业务 ID 或 Trace ID 关联。同一份错误沿调用栈打印三次，不能算成三次业务失败。

接下来，在告警规则的下钻配置中，把指标对应到 `webhook.attempt.completed`，再将告警实际携带的标签和触发时间填入查询。下面是逻辑示意，具体语法由日志后端决定：

```text
event_name = webhook.attempt.completed
service = ${alert.labels.service}
env = prod
region = ${alert.labels.region}
outcome = failure
```

这个例子假设告警限定生产环境，并保留了 service 和 region。如果告警按服务、区域聚合，实例标签已经消失，下钻查询就不能再引用实例。查询时间也应固定在告警发生时，覆盖当时的计算窗口，并适当留出上下文；第二天打开同一告警，仍应看到昨天的问题。变量需要校验，并按目标查询语言转义。

**日志里不必反向保存指标名。** 一个事件可以贡献次数、耗时等多个指标，稳定的业务事件名负责定位明细，指标与事件的映射放在下钻配置中。指标也可以直接埋点，不要求先写日志、再从日志生成所有指标。

真正开始调查后，查询必须可以修改。先看失败记录中哪些错误增加；想比较目标的失败率，就移除 `outcome = failure`，补查成功事件；怀疑是某个区域的问题，就扩大区域范围；发现某类错误值得深入，再选具体执行查看 Trace。顶部图中的箭头表达的就是这个调查顺序，日志本身早已在执行时采集。

这也是我更愿意把这套路径作为告警默认入口的原因。Exemplar 可以把聚合指标关联到某次测量的上下文，适合快速打开一个执行样本。但一次连接超时的 Trace，并不能说明超时就是这次失败率上升的主要原因。它可能只是许多失败类型中的一种。[OpenTelemetry Exemplar 规范](https://opentelemetry.io/docs/specs/otel/metrics/sdk/#exemplar)

如果目标是解释一次请求，样本关联很直接。如果目标是解释一次告警，我更希望先看到相关事件的分布，再决定深入哪一次执行。支持集合搜索和聚合的 Trace 后端也能提供这种调查能力，exemplar 本身则不负责定义这个查询集合。

这套实践有一个不能省略的前提：**查询出来的证据覆盖了什么，必须说清楚。** 对选定的、有排障价值的事件，我们按全量采集设计；如果要比较成功与失败，就同时保留两类事件。如果某条路径只有异常详情，总量和成功率仍应以指标为准。日志丢失、采样、保留期和查询截断，也都会影响结论。字段一致，不代表日志数量一定与指标计算结果严格相等。

成本控制从事件取舍开始。正常心跳、空闲轮询、没有状态变化的周期检查，如果指标已经足够回答问题，就不需要逐次写完成日志；省略日志的路径仍正常更新指标。有价值的字段应在正常运行时可用，避免排障必须先开 debug、再等故障重现。结构化字段也需要真正解析入库，并支持过滤和聚合。

这与 OpenTelemetry 可以共存。一个属性完整的业务 Span，也能承担完成日志的职责；如果后端的检索、聚合和保留策略都满足需求，没有必要再存一份相同证据。需要坚持的是事件粒度、结果口径和查询入口的一致性。

对 AI Agent，我也希望提供同一份已解析查询、告警条件和时间范围。让查询系统计算分布，Agent 获取统计结果和必要样本，再提出下一步要验证的问题。它给出的判断应附带实际执行的查询，方便工程师复查。把第一条报错扩写成根因分析，很容易遗漏决定告警走势的其他事件。

落地可以从一条常见告警开始：明确它统计什么工作单元，检查对应完成日志是否有足够上下文，再把标签和时间范围接到可编辑查询上。验证成功、失败和重试，确认分母从哪里来。先把这条路径走通，就能判断这种关联是否改善了团队的调查过程。

我希望一条告警除了告诉我“哪里异常”，还能带我找到一组可以继续分析的证据。你们的团队目前如何完成这一步？更常从日志集合开始，还是先打开一条具体 Trace？

> 作者：秦晓辉。快猫星云 Co-Founder。开源项目 Open-Falcon、Nightingale 发起人。极客时间专栏《运维监控系统实战笔记》作者。

假设一条告警告诉你：过去 5 分钟，某区域的 webhook 投递失败率从平时的 1% 升到了 8%。这是一个示意场景，但接下来的问题很具体：哪些目标失败了？涉及哪些账号？增加的是连接超时，还是鉴权错误？

从 Prometheus 告警到事件证据：把指标和日志真正接起来

运维

云计算

架构设计

通过低基数指标定位异常，配合Canonical Log Line保存事件上下文，将告警转换为可编辑的日志查询，实现从异常通知到证据集合的快速跳转，显著缩短排障路径。

代码解释

Agent

2026上云采购 | AI焕新·智启新局

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

从 Prometheus 告警到事件证据：把指标和日志真正接起来-腾讯云开发者社区-腾讯云

从 Prometheus 告警到事件证据：把指标和日志真正接起来

从 Prometheus 告警到事件证据：把指标和日志真正接起来

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐