القائمة
系统可观测性的方法论：健康三层定义、告警分级、巡检与趋势分析的差异、监控盲点识别。 不包含任何具体监控工具的配置或命令——具体实现由使用者根据自身技术栈在本地 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 了解如何读取环境变量。