关于 slos-and-triggers
面向 Honeycomb 的技能,指导设计 SLO、选择 SLO 或触发器,并解读可靠性数据。重点是配置决策与分析,而不只是工具说明。
主要功能
- 01区分 SLO 与触发器
- 02定义基于事件的 SLI
- 03设定可靠性目标与告警
- 04解读错误预算状态
- 05设计基于计数的触发器
- 06规划多服务 SLO
适用场景
- 01为用户工作流设定可靠性目标
- 02选择用于即时运维问题的告警
- 03评估错误预算消耗与部署风险
MCP 相关
为 Honeycomb 的 `get_slos` 和 `get_triggers` 工具提供指导;不能配置告警接收人。
安装
复制下面的命令,在终端中运行。
npx skills add https:/ / github.com/ honeycombio/ agent-skill --skill slos-and-triggers安装后在 Claude Code 中输入/slos-and-triggers确认已加载。
包含的文件
除 SKILL.md 外,安装时一起下载的参考资料和脚本。
references/alerting-strategy.mdslo-design-guide.mdtrigger-examples.md详细介绍
Honeycomb SLO 和触发器
有关在 Honeycomb 中配置和理解可靠性的指南。get_slos
和 get_triggers 工具会说明各自的参数;本技能侧重于如何 设计 有效的 SLO、如何在 SLO 和触发器之间 选择,以及如何 解读
这些数字的含义。
可用性:SLO 需要 Pro 或 Enterprise 计划。所有计划均可使用触发器。
SLO 与触发器——何时使用哪一个
| 问题 | SLO | 触发器 |
|---|---|---|
| “我们是否达到了可靠性承诺?” | 是 | 否 |
| “现在是否出了问题?” | 否 | 是 |
| “我们的错误预算消耗速度有多快?” | 是(消耗速率告警) | 否 |
| “错误数是否超过了阈值?” | 否 | 是 |
| “我们是否应该放慢部署速度?” | 是(剩余预算) | 否 |
经验法则:SLO 用于衡量一段时间内的可靠性是否符合承诺。触发器用于捕捉即时的运营问题。
设计有效的 SLO
定义 SLI
SLI 是一个针对每个事件的布尔值:该事件是否成功?它通过计算字段实现,返回 undefined(不相关事件)、1(成功)或 0(失败)。
- 格式:
IF(<qualifying-condition>, <success-condition>)限定条件用于筛选相关事件;成功条件用于定义成功的标准。如果不满足限定条件,公式会返回 undefined,且不会填充 SLI。 - 明确的限定条件:选择相关事件的子集(例如,对结账端点的根 span 使用
AND(EQUALS($http.route, "/checkout"), NOT(EXISTS($trace.parent_id)))) - 延迟成功条件:
LTE(duration_ms, 500)— 请求耗时低于 500ms - 可用性成功条件:
LTE(http.status_code, 499)— 非 5xx 响应 - 业务逻辑成功条件:
EQUALS(checkout.status, "completed")— 结账成功
设定目标
- 从保守的目标开始(先设为 99%,而非 99.99%)
- 先使用 P50/P99 查询测量当前基线
- 将目标设定为略高于当前性能
- 思考:用户实际需要怎样的可靠性?
配置耗尽时间告警
至少配置两种告警:
- 接近耗尽(耗尽时间约为 4h):通过 PagerDuty 通知当班人员
- 耗尽趋势(24h 内的预算消耗速率):通过 Slack 通知团队
配置消耗速率告警
即使预算尚未接近耗尽,也要检测快速消耗。例如:
- 1h 消耗速率 > 10x — 通知当班人员
创建 SLO 后,建议向用户推荐这些告警。Agent 无法设置这些告警或其接收人。
最佳实践
- 尽量在靠近用户的位置测量(在边缘,而不是在调用栈深处)
- 围绕用户工作流设计,而非围绕团队边界
- 优先考虑覆盖面广的 SLO,而不是多个范围狭窄的 SLO
- 从一个 SLO 开始,减少噪声后再扩展
解读 SLO 状态
使用 get_slos 查看 SLO 时:
- 剩余预算 > 50%:状态健康——有承担风险的空间
- 剩余预算为 10-50%:需要谨慎——放慢变更速度
- 剩余预算 < 10%:存在风险——暂停非关键部署
- 预算为负数:已超出预算——立即使用生产环境调查技能进行排查
- 合规率为 0%:SLI 可能配置错误(列选错、逻辑反了或没有匹配的事件)——检查 SLI 定义
配置触发器
优先选择基于计数的触发器,而非基于百分位数的触发器
“50 个请求耗时超过 2s”比“P99 为 2100ms”更具可操作性。
使用 COUNT WHERE duration_ms > threshold,而不是 P99 触发器。
常见模式
- 错误激增:COUNT WHERE error = true,5 min 内阈值 > N
- 请求缓慢:COUNT WHERE duration_ms > 2000,5 min 内阈值 > N
- 流量下降:COUNT WHERE is_root,10 min 内阈值 < N(低于正常水平)
最佳实践
- 名称:警报内容。描述:要采取的操作(链接到运行手册)。
- 将持续时间至少设为 5-10 分钟,以避免抖动
- 先设置得不那么灵敏,再根据误报率逐步收紧
多服务 SLO
最多可由 10 个服务共享单个错误预算。
- SLI 必须是环境级别的计算字段
- 纳入的服务产生的事件权重相同
- 使用场景:多个边缘服务、从单体迁移到微服务
与用户确认
Honeycomb 工作区的 SLO 和触发器数量有限。执行创建工具前,请先与用户确认。展示所有参数和你的理由,并征求确认。
构造指向 SLO 的链接
你所拥有的工具无法直接链接到 Honeycomb 中的 SLO 页面。 你可以改为链接到 SLO 列表。
/<team_slug>/environments/<environment_slug>/slos
其他资源
参考文件
${CLAUDE_PLUGIN_ROOT}/skills/slos-and-triggers/references/slo-design-guide.md— 详细的 SLO 设计方法、多服务 SLO 和错误预算计算${CLAUDE_PLUGIN_ROOT}/skills/slos-and-triggers/references/trigger-examples.md— 按使用场景整理的完整触发器示例库${CLAUDE_PLUGIN_ROOT}/skills/slos-and-triggers/references/alerting-strategy.md— 如何将 SLO 消耗告警和触发器结合成连贯的告警策略
交叉引用
- 有关构造 SLI 查询和计算字段,请参阅 query-patterns 技能
- 有关调查 SLO 预算消耗,请参阅 production-investigation 技能