Agent Skills
返回列表
🔒

可观测性与埋点

IT 运维与安全 更新于 2026.08.30

将以下提示词粘贴到你的 AI 对话框中：

请根据 https://skillhub.cn/install/skillhub.md，安装 @user_3c6cb52e/observability-and-instrumentation-sh-k1xmdy。

技能介绍

要解决的问题

生产事故里最痛的不是代码报错，而是无法回答“请求到哪一步、为什么慢、外部依赖返回了什么”。如果埋点只是上线后补日志，第一次故障就会变成考古。这个技能把可观测性前置到功能开发流程中：先写清 on-call 要回答的 2–4 个问题，再为每个问题选择结构化日志、指标或链路追踪，避免把 console.log、高基数 label 和原因型告警当成可观测性。

技能如何工作

  • 日志：要求 JSON 事件名、稳定字段和 requestId 关联，并禁止记录密钥、令牌和完整 PII。
  • 指标：围绕 RED 与 USE，强调用直方图读取 p95/p99，而不是平均值；label 必须来自有限集合。
  • 追踪：优先使用 OpenTelemetry，覆盖 HTTP、gRPC 和常见 DB 客户端，并在异步边界传播 context。
  • 告警：只保留可执行的症状型告警，要求 runbook、阈值、持续时间和 page / ticket 两级。

适用边界

它适合新增服务、端点、后台任务、外部集成，也适合评审含重试、队列、跨服务调用的 PR。它不负责正在发生的故障排查、性能 profiling 或上线日回滚清单；这些应交给调试、性能优化和发布技能，但都依赖这套埋点作为证据来源。

使用场景

  • 新增支付回调接口前，先写清 on-call 问题，再配置结构化日志、RED 指标和 request ID。
  • 评审含重试和队列的 PR 时，检查是否有新埋点、关联 ID、有限 label 和症状型告警。
  • 上线后台任务后，用测试流量验证指标序列、追踪跨服务 span，并触发一次告警确认 runbook。
  • 事故复盘发现无法定位慢请求，按 RED/USE 补直方图 p95/p99，并把用户 ID 从 label 移到日志。

适合人员

  • 负责生产后端服务的工程师，希望新接口上线时就能查询请求 ID、错误率和延迟分位数。
  • 处理跨服务调用事故的 SRE，需要把日志、指标、追踪关联到同一请求并快速找到慢 hop。
  • 评审支付、队列、重试相关 PR 的技术负责人，要确保没有无埋点、高基数 label 或原因型告警。
  • 建设告警 runbook 的运维工程师，要求每条 page 告警可执行、有阈值、持续时间和升级路径。