Self Monitor

核心用法

Self Monitor 是一套面向 AI Agent 和运维人员的主动式基础设施监控方案，通过标准 Shell 命令实现对 Linux/Unix 系统的全方位健康检查。核心功能分为四大模块：

1. 基础设施监控：通过 df、free、uptime、ps 等原生工具采集磁盘使用率（警告 80%/危急 90%）、内存占用（警告 85%/危急 95%）、负载平均值（警告 2.0/危急 4.0）及 TOP 进程排序。

2. 服务健康检查：支持多种检测方式——pgrep 进程检测、curl HTTP 端点探测、systemctl systemd 服务状态、docker ps 容器存活检查，以及 Tailscale 网络状态监控。

3. 定时任务监控：通过解析 /var/log/syslog 中的 CRON 日志，统计近 24 小时失败次数并生成执行报告。

4. 错误日志聚合：利用 journalctl 系统日志、tail 应用日志及 dmesg 内核消息进行多源错误扫描。

自动修复机制在检测到危急状态时触发：磁盘超限时清理 7 天以上日志与缓存；关键进程失联尝试重启；内存爆满时输出 TOP 进程清单辅助诊断。所有操作均通过纯 Shell 实现，零依赖部署。

显著优点

• 零依赖轻量：仅依赖系统预装工具（awk、grep、curl 等），无需额外安装监控 Agent
• 即插即用：提供可直接嵌入 crontab 的快速健康检查脚本
• 多平台兼容：明确支持 Claude Code、Codex CLI、Cursor、Windsurf 等主流 AI 编码工具
• 结构化报告：输出 Markdown 格式的标准化监控报表，便于 Agent 解析与归档
• 安全自动修复：内置保守策略（仅清理过期临时文件），避免误删风险

局限与注意事项

• 阈值硬编码：警告/危急阈值在文档中固定，未提供动态配置机制
• 单节点视角：设计为单机监控，无分布式集群状态聚合能力
• 日志路径假设：CRON 日志默认读取 /var/log/syslog，部分发行版（如使用 rsyslog 或 systemd 纯 journald）需手动适配
• 权限敏感：部分检查（如 journalctl -p err、systemctl）需要适当权限，在受限容器中可能失效
• HTTP 探测简单：仅检查状态码，未涵盖响应内容校验、SSL 证书有效期等进阶场景

适用人群

• 个人开发者维护云服务器/VPS 的日常健康巡检
• AI Agent 实现"自感知"基础设施状态，辅助故障诊断
• 中小规模项目（单机或少量节点）替代重量级监控栈（如 Prometheus+Grafana）
• CI/CD 流水线中的部署前环境健康预检

常规风险提示

| 风险场景 | 说明 | 建议 |

|---------|------|------|

| 误删数据 | 自动清理日志/缓存时可能误触业务文件 | 部署前审核 `find` 路径范围，生产环境关闭自动删除 |

| 权限不足 | 容器内运行可能无法访问宿主机资源 | 调整容器特权或改用宿主机 Agent 模式 |

| 告警疲劳 | 阈值设置不当导致频繁通知 | 根据实际负载调整阈值，避免使用固定数值 |

| 日志缺失 | 依赖的日志文件轮转或权限变更 | 配置日志集中采集（如 `journald` 持久化）作为兜底 |

核心用法

Self-Monitor 是一款面向基础设施运维的文档型监控技能，采用纯 Markdown 格式提供系统健康检查的标准命令模板与最佳实践。用户可通过该技能快速获取检测磁盘使用率（df -h）、内存占用（free -m）、系统负载（uptime）、进程资源消耗（ps aux）等核心指标的 Bash 命令示例。同时涵盖服务健康检查（systemd、Docker、HTTP 端点）、Cron 任务状态监控以及系统日志错误追踪等场景。文档内置阈值告警表（磁盘>90%、内存>95%、负载>4.0 为危急），并附带自动清理脚本示例（安全删除 7 天以上日志与临时文件），支持集成到 crontab 实现定时巡检。

显著优点

1. 零执行风险：纯文档型设计（T-MD 分类），无可执行代码文件，无动态下载、无网络外发，从根本上杜绝供应链攻击与恶意代码注入风险。

2. 即开即用：提供可直接复制的生产级命令模板，覆盖 Linux 系统监控的核心场景，大幅降低运维人员的脚本编写成本。

3. 结构清晰：采用分层文档架构——基础设施层、服务层、定时任务层、日志层——符合 ITIL 监控体系的最佳实践。

4. 阈值驱动：预置业界通用的告警阈值矩阵，支持快速判断系统健康状态（✅正常/⚠️警告/🔴危急）。

5. 自动修复指引：针对磁盘爆满、关键进程宕机等场景，提供经安全审查的自动修复脚本（仅限清理临时文件等低风险操作）。

潜在局限

1. 纯手动执行：文档仅提供命令参考，Agent 本身不具备自动化执行能力，需用户手动复制或封装为脚本。

2. 平台依赖性强：命令示例基于 Linux/Unix 环境（systemd、journalctl、/var/log 路径），Windows 或容器化环境需自行适配。

3. 无可视化界面：输出为纯文本或 Markdown 表格格式，缺乏仪表盘（Dashboard）或时序图表能力。

4. 监控深度有限：侧重基础资源指标，未涵盖应用性能监控（APM）、分布式追踪、业务指标埋点等高级场景。

5. 告警通道单一：依赖标准输出与本地日志，未集成邮件、短信、Slack、PagerDuty 等现代告警通知渠道。

适合人群

• 中小团队运维工程师：缺乏专职 SRE，需快速搭建轻量级监控体系。
• 个人开发者/独立建站者：管理少量 VPS 或云主机，追求极简运维方案。
• DevOps 入门学习者：通过标准化命令模板理解系统监控的核心指标与检查逻辑。
• 自动化脚本开发者：将其作为命令参考库，二次封装为 Ansible Playbook、Shell Script 或 Systemd Timer。

使用风险

1. 误操作风险：文档中包含 rm -f、find -delete 等文件删除命令示例，若未理解即执行，可能导致数据丢失。建议先在测试环境验证。

2. 权限要求：部分命令（如 journalctl -p err、systemctl is-active）需 root 或特定用户组权限，直接复制可能因权限不足而失败。

3. 日志路径差异：不同发行版（CentOS/Ubuntu/Alpine）的日志路径与轮替策略不同，硬编码 /var/log/syslog 可能在某些环境失效。

4. 无持久化存储：健康检查报告输出到标准输出或本地文件，缺乏数据库持久化，历史趋势分析能力受限。

5. 并发执行隐患：若多个定时任务同时触发资源密集型检查（如 ps aux 全量排序），可能对低配置服务器造成额外负载。