基础设施与可用性监控

像一位敏锐的运维工程师一样监控你的服务器和端点，告诉你真正需要关注的问题，而不是一个堆满47个数字的仪表盘。

触发条件

当用户满足以下任一情况时激活此技能：

• 询问服务器健康状态、运行状况或资源使用情况
• 提供服务器指标（CPU、内存、磁盘、网络）以供评估
• 询问端点的可用性、停机时间或上线时间
• 询问 SSL 证书到期日期
• 提供来自 top、htop、df、free、uptime、vmstat、iostat 等命令的系统输出
• 要求获取基础设施的状态报告
• 提及服务器的监控、健康检查或故障检测
• 询问容量规划或资源趋势分析
• 提供 ping、curl 或 HTTP 响应数据用于分析
• 要为新服务器或端点设置监控

不激活的情况：

• 用户需要应用层业务指标（建议使用数据分析报告类技能）
• 用户需要 APM 或分布式追踪功能（建议使用 Datadog、New Relic 等工具）
• 用户希望构建监控仪表盘的 UI
• 用户需要实时流式指标摄入
• 用户希望进行网络安全性扫描或渗透测试
• 用户询问云服务商账单或成本优化，但缺乏基础设施上下文

处理请求的顺序

1. 明确范围 — 在执行任何检查前，先理解用户正在监控的内容及其原因：

- “你需要检查哪些服务器或端点？”

- “这是例行检查还是针对特定问题的排查？”

- “你认为‘健康’状态应该是什么样的？”

若用户提供清晰上下文（如系统指标粘贴、具体待检查端点），可跳过此步直接进入第2步。

1. 收集数据 — 获取或解析基础设施相关数据：

- 解析用户提供的系统命令输出（如 top、df、free、uptime 等）

- 对提供的端点执行 HTTP/HTTPS 检查

- 解析提供的日志片段或监控数据导出内容

- 识别数据类型并验证完整性

- 若数据不足以做出有意义评估，请在继续前要求补充细节

1. 健康评估 — 根据阈值对各项指标进行评估：

- 使用 references/metrics-thresholds.md 中的阈值将每个指标分类为 健康、警告 或 严重

- 考虑上下文：20GB 磁盘使用率达 85% 的紧急程度高于 2TB 磁盘的相同比例

- 判断变化趋势：指标是稳定、上升还是下降

- 识别关联关系：高 CPU + 高 swap 通常意味着内存压力，而非 CPU 本身问题

- 检测复合风险：多个警告单独看可能无害，但组合起来可能预示潜在问题

1. 生成状态报告 — 按照以下默认格式结构化输出：

- 优先说明需要关注的问题，而非正常状态

- 将相关问题归类（不要对同一服务器发出五条独立的磁盘告警）

- 包含时间背景：该问题是新出现、持续存在还是重复发生

- 注明自上次检查以来已有改善的情况（如有历史上下文）

1. 推荐操作 — 提供按紧急程度排序的具体下一步行动：

- 严重问题的立即处理措施

- 警告项的计划维护安排

- 监控配置优化建议以提升可见性

- 针对趋势性问题的容量规划提示

默认输出结构

除非用户明确要求其他格式，否则请使用以下结构：

1. 需重点关注事项 — 按严重性和紧迫性排序的严重与警告项。每项包括：

- 问题描述（用通俗语言表达）

- 严重程度（严重 / 警告）

- 建议操作

- 紧急程度（立即处理 / 本周内安排 / 监控观察）

若无问题：显示“所有系统健康，无需采取行动。”

1. 服务器健康概览 — 每台服务器的简要总结：

- 主机名 / 标识符

- 整体状态：健康 / 警告 / 严重

- 关键指标：CPU、内存、磁盘、运行时间

- 一句话评估（例如：“运行良好，磁盘持续增长——约45天后达到90%”）

1. 端点状态 — 每个端点的概览：

- URL / 端点标识符

- 状态：正常 / 降级 / 不可用

- 响应时间与状态码

- HTTPS 证书剩余天数（若适用）

- 监控周期内的可用率百分比

1. 资源趋势 — 关键指标的方向性指示：

- 哪些指标正在上升、保持稳定或下降

- 变化速率（如有意义）

- 预计阈值到达时间（例如：“按当前增长速度，磁盘将在约30天内达到90%”）

- 如有历史对比，提供与上次检查的差异分析

1. 事件时间线 — 如有近期事件，请列出：

- 事件开始与结束时间（或“仍在持续”）

- 触发检测的原因

- 影响评估

- 解决进展或当前缓解状态

1. 建议操作 — 推荐三项具体行动：

- 一项立即处理事项（若有严重或警告项）

- 一项预防性措施（基于趋势分析）

- 一项监控改进建议（提升下次观察的可见性）

1. 系统详情 — 供参考的原始指标数值：

- 每台服务器的完整指标明细

- 以清晰表格形式呈现

- 实际值与阈值并列展示

- 此部分供希望查看详细数据的用户使用

健康评估逻辑

依据 references/metrics-thresholds.md 中的阈值，遵循以下原则：

• 上下文比绝对数值更重要。Web 服务器在高峰时段 CPU 达到 70% 与凌晨 3 点的 70% 含义不同。
• 趋势比快照更重要。60% 磁盘使用率且每日增长 2% 的情况，比连续数月稳定在 80% 更需关注。
• 复合信号需综合判断。高 CPU + 高内存 + 高磁盘 I/O 共同出现时应深入排查；单一指标仅处于警告水平则只需监控。
• 考虑容量大小的阈值调整。90% 的 10GB 磁盘比 90% 的 1TB 磁盘更早需要干预。
• 可用性上下文决定影响程度。12 分钟的 API 端点中断对关键服务的影响远大于对每周批处理任务服务器的影响。

严重程度分类

Skill: Infra Monitoring

Version: 0.1.0

Chunk: 2/2

请参阅 references/alert-severity.md 获取完整的告警严重性分类体系。摘要如下：

SSL 证书监控

检查 HTTPS 端点时：

• 报告证书到期剩余天数
• 在应用阈值前确定证书是否自动续期：

自动续期证书（如 Let's Encrypt、云服务商管理的证书等）：

• Critical：剩余天数 < 7 天（续期几乎肯定失败）
• Warning：剩余天数 < 14 天（续期应已触发 — 需调查）
• Healthy：剩余天数 > 14 天

手动续期证书（购买的证书、企业 CA、自管理证书）：

• Critical：剩余天数 < 14 天（无足够时间完成采购/安装）
• Warning：剩余天数 < 45 天（立即启动续期流程）
• Healthy：剩余天数 > 45 天

未知续期类型（无法判断是自动还是手动）：

• Critical：剩余天数 < 7 天
• Warning：剩余天数 < 30 天
• Healthy：剩余天数 > 30 天

如何判断续期类型：检查证书颁发者。Let's Encrypt、AWS ACM、Cloudflare、Google 管理的证书为自动续期。企业 CA（DigiCert、Sectigo、内部 PKI）及自签名证书通常为手动续期。若有疑问，归类为未知，并注明不确定性。

• 标记证书链问题、主机名不匹配或中间证书过期等问题

事件检测与聚合

当多个告警由同一根本原因引发时：

• 将其合并为一个事件叙述
• 识别可能的根本原因（例如：“磁盘满导致数据库停止，进而引发 API 返回 500 错误”视为一个事件，而非三个）
• 记录时间线：首次发现、升级、影响峰值、解决时间
• 生成通俗易懂的事件复盘总结

数据稀疏与部分检查处理

当用户提供不完整数据时：

1. 评估可处理的部分 — 不因某项指标缺失而拒绝整个检查
2. 明确指出缺失项 — “我可以评估 CPU 和内存，但未提供磁盘使用率 — 是否需要我检查？”
3. 调整置信度 — 部分数据仅能给出有条件评估，而非确定结论
4. 建议补充完整信息 — “要获得全面健康检查，我还需以下信息：[列出]”

无数据准入机制

当用户请求监控但未提供任何服务器信息或指标时：

1. 询问他们希望监控的内容（服务器、端点或两者）
2. 建议最小可行检查：提供主机名/IP 及其上运行的服务
3. 提供来自 references/monitoring-checklists.md 的初始监控清单
4. 给出示例健康检查输出，帮助用户了解预期结果

不得虚构服务器指标，也不得假装检查不存在的基础设施。

边界限制

• 无显式配置则不访问任何资源。未经用户明确提供连接信息，不得主动连接服务器、端点或服务。
• 不在技能文件中存储凭证。禁止在输出中写入密码、API 密钥、SSH 密钥或连接字符串。仅可引用环境变量或密钥管理器。
• 不执行直接修复操作 — 仅提供指导。本技能仅提供监控、诊断和建议，不直接执行修复动作（如重启服务、删除文件、扩容资源、修改配置）。若用户请求修复，请提供逐步操作指南和命令，并在每步前说明风险。
• 区分监控数据与诊断推测。清晰区分观测事实（如“CPU 使用率为 92%”）与推断（如“可能由占用 4.2GB 堆内存的 Java 进程引起”）。对每一项标注类型。
• 不保证实时检测。该技能按需运行或按检查周期执行，非内核级监控或硬件看门狗。必须明确说明此限制。
• 监控输出中不包含个人身份信息（PII）。若服务器响应中包含用户数据，应在报告和事件日志中排除。
• 监控范围限定为基础设施，不包括应用层。本技能监控服务器和端点状态，不涉及业务级 KPI。如需分析业务数据，请使用 data-analysis-reporting 技能。