可观测性建设
将以下提示词粘贴到你的 AI 对话框中:
请根据 https://skillhub.cn/install/skillhub.md,安装 @user_af163eaa/z-dev-observability。
技能介绍
要解决什么问题
很多系统的可观测性建设是「被动补课」:出一次故障,补一套日志;收到一次告警投诉,再砍一批规则。结果是采集项越堆越多、仪表盘越建越乱,真正出事时依然靠人肉翻日志。
可观测性建设 针对的正是这种状态——它把日志、指标与链路追踪的搭建过程整理成一套常规指南,让你在动手采集之前先想清楚:为什么要采、采到什么程度、出了数据之后谁来消费。
技能如何工作
核心方法围绕三支柱展开:
- 三支柱协同采集:日志、指标、链路追踪不是三套独立系统,而是互补的证据链,需要按场景决定各自的采集范围与保留策略。
- SLI/SLO 先行:先定义关键服务的 SLI/SLO 并和业务目标对齐,采集与告警才有取舍依据,而不是「什么都要」。
- 告警降噪与分级:通过合理的阈值与分级策略避免告警风暴,让值班同学看到的每一条告警都值得起身。
- 仪表盘与根因定位:把观测数据组织成可排查的视图,缩短从「用户报障」到「定位组件」的时间。
使用时按四个步骤推进:先明确目标与场景边界,再逐项套用上述方法执行或自查,然后输出结构化结果(清单、分级、建议),最后标注不确定项与需要人工复核的环节。
适用边界与注意点
- 适用:可观测性、日志、指标、链路追踪、SLO 相关的方法论指导与清单参考,尤其是需要结构化步骤或最佳实践对照的场景。
- 不适用:需要实时数据或外部系统直连的高频自动化任务——本技能提供的是方法论与自查清单,不是实时数据通道。
- 不适用:法律、医疗、财税等必须由持牌专业人士出具的确定性结论。
- 观测是有成本的:采集、存储、索引都会消耗资源。应避免无差别采集,先想清楚数据的消费方,再决定采集的粒度与保留周期。
使用场景
- 微服务架构下日志、指标与链路追踪分散,需要统一采集范围和保留策略,建立三支柱协同的观测体系。
- 业务对可用性有明确要求,需要从关键服务出发定义 SLI/SLO,并据此确定采集粒度和告警阈值。
- 告警数量过多导致值班人员频繁被打扰,需要按严重程度分级、合并规则,减少无效通知。
- 出现用户报障后排查耗时较长,需要把已有观测数据整理成可定位问题的仪表盘和排查路径。
适合人员
- 正在从零搭建观测体系的 SRE 工程师,需要一套可执行的三支柱建设和自查清单。
- 负责服务可用性目标的平台架构师,需要把 SLO 定义和告警分级方法落到团队规范里。
- 长期被无效告警打扰的值班工程师,需要降噪与分级策略来恢复对告警的信任。
- 需要缩短故障定位时间的后端负责人,希望用仪表盘和根因分析步骤替代人肉排查。