菜单
系统可观测性的方法论：健康三层定义、告警分级、巡检与趋势分析的差异、监控盲点识别。 不包含任何具体监控工具的配置或命令——具体实现由使用者根据自身技术栈在本地 skill 中编写。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | observe |
| title | 系统观测方法论 |
| soul | SOUL.md |
| persona | observer |
| version | 1.1 |
| triggers | ["观测","监控","巡检","健康检查","告警","系统状态","observe","health check","monitoring","变更感知"] |
| depends_on | ["infra/inventory-loader"] |
| required_vars | [] |
| description | 系统可观测性的方法论：健康三层定义、告警分级、巡检与趋势分析的差异、监控盲点识别。 不包含任何具体监控工具的配置或命令——具体实现由使用者根据自身技术栈在本地 skill 中编写。 |
本 skill 是原则与框架层。具体的监控工具配置（Zabbix UserParameter、Prometheus 指标、 端口扫描脚本等）由使用者在自己的本地 skill 中实现，不在此处定义。
"系统健康"不是一个单一状态，而是三个层次的组合。缺少任何一层，都是不完整的观测：
关键洞察： 进程活着 ≠ 服务可用 ≠ 业务正常。三层中任何一层出现问题，都需要关注。
| 级别 | 含义 | 响应要求 | 典型场景 |
|---|---|---|---|
info | 信息性事件，无需处理 | 仅记录 | 计划维护开始/结束 |
warning | 资源接近阈值，需关注 | 工作时间内处理 | 磁盘使用率 >70%，内存 >80% |
critical | 服务降级或性能显著下降 | 30 分钟内响应 | 进程重启、响应时间 3 倍于基线 |
disaster | 服务完全不可用 | 立即响应 | 进程不存在、数据库无法连接 |
原则：
critical 及以上告警都应有对应的诊断 runbook（指向哪个 diagnose skill）两者解决不同问题，都不可缺少：
常见错误： 只做快照巡检，忽略趋势，导致磁盘满、连接池耗尽等可预测问题变成紧急事故。
以下是最容易被遗漏的监控点：
观测不仅要发现"现在有没有问题"，还要感知"最近有没有变化"——变更是最常见的故障根因来源。
| 变更类型 | 感知方式 | 巡检时关注点 |
|---|---|---|
| 应用发布 | 部署日志、版本标签变更 | 发布时间与异常开始时间的关联 |
| 配置变更 | 配置文件 hash 变更、环境变量修改 | 变更项与异常指标的直接关系 |
| 基础设施变更 | 扩容/缩容事件、迁移记录 | 流量分布变化、新节点健康状态 |
| 依赖升级 | 下游服务版本变更 | 接口兼容性、性能特征变化 |
| 定时任务 | 任务执行日志 | 执行时间与异常时间吻合 |
关键原则： 巡检报告应包含"近 N 小时内的变更摘要"，而非仅包含当前状态快照。
三者互补，不可互相替代：
| 信号类型 | 回答什么问题 | 适合场景 |
|---|---|---|
| 指标（Metrics） | "是否有问题？严重程度如何？" | 触发告警、趋势分析、容量规划 |
| 日志（Logs） | "发生了什么事情？在哪里出错？" | 故障排查、审计、调试 |
| 追踪（Traces） | "请求经过了哪些系统？每段耗时多少？" | 微服务延迟分析、依赖链追踪 |
没有追踪系统时，结构化日志（含 request_id/trace_id）可以部分替代追踪的功能。
observer persona 严格只读：
observer 是"眼睛"，不是"手"。
本框架不提供任何具体的监控工具配置或脚本。使用者需要：
depends_on: [observe]，确保方法论约束生效persona 必须设置为 observerinventory/hosts.yaml参见 skills/infra/inventory-loader 了解如何读取环境变量。