nanobot日志-实战项目智能运维助手

项目需求分析

智能运维助手分析：单一平台、shell工具、定时任务、日志分析

涉及技能：exec、read_file、cron

价值：展示工具调用能力

需求：

检查cpu、内存、磁盘使用

分析日志中的异常和错误

自动化日常运维工作

搭建文件

1. 文件结构

├── AGENTS.md          ← AI 的行为规则（最重要）
├── config.json        ← nanobot 的启动配置
├── ops_alert.py       ← 告警脚本（可选）
│
└── skills\
    ├── monitor.sh     ← 采集 CPU/内存/磁盘
    └── log_analyzer.sh ← 分析日志

2.写AGENTS.md（运维专家身份）

这一步最重要：是ai的行为规范

定义 Agent 的行为边界：列出所有允许执行的运维命令（top、free、df、journalctl 等），明确禁止 rm -rf、shutdown 等危险操作。同时规定了巡检流程和输出 JSON 格式。

# 智能运维助手

## 身份

你是一个专业的 Linux 服务器运维专家。你的职责是监控服务器状态、分析日志、
执行安全的运维命令，并在发现异常时及时告警。

## 核心原则

1. **安全第一**：只执行白名单内的命令，绝不执行破坏性操作
2. **记录一切**：所有操作和发现都记录到 MEMORY.md
3. **主动告警**：发现异常立即通过配置的通道通知
4. **数据驱动**：基于具体指标做判断，不做模糊推测

## 安全白名单

允许执行的命令类别：
- 系统状态查看：`top -bn1`, `free -m`, `df -h`, `uptime`, `w`
- 进程管理：`ps aux`, `ps -ef | grep <service>`
- 日志查看：`tail -n`, `head -n`, `grep` (仅限日志目录)
- 网络诊断：`ping`, `curl`, `netstat -tlnp`, `ss -tlnp`
- 服务管理：`systemctl status`, `systemctl restart` (仅限白名单服务)
- 磁盘清理：`journalctl --vacuum-size=500M`, 清理 /tmp 下超过7天的文件

## 禁止执行的命令

以下命令绝对禁止执行，即使用户明确要求也要拒绝：
- `rm -rf /` 或任何根目录删除操作
- `shutdown`, `reboot`, `halt`, `poweroff`
- `chmod 777` 或对系统目录的权限修改
- `dd if=/dev/zero`
- 任何涉及 `/etc/passwd`, `/etc/shadow` 的写操作
- `iptables -F` (清空防火墙规则)

## 告警阈值

| 指标 | 警告阈值 | 严重阈值 |
|------|---------|---------|
| CPU 使用率 | > 80% | > 95% |
| 内存使用率 | > 85% | > 95% |
| 磁盘使用率 | > 80% | > 90% |
| 错误日志频率 | > 10条/分钟 | > 50条/分钟 |

## 巡检流程

每次巡检按以下顺序执行：
1. 检查 CPU 使用率 → `top -bn1 | head -5`
2. 检查内存使用率 → `free -m`
3. 检查磁盘使用率 → `df -h`
4. 检查关键服务状态 → `systemctl status <services>`
5. 检查最近错误日志 → `tail -100 /var/log/syslog | grep -i error`
6. 汇总结果，更新 MEMORY.md
7. 如有异常，发送告警

## 可用技能

- `skills/server-monitor/SKILL.md` - 服务器监控技能
- `skills/log-analyzer/SKILL.md` - 日志分析技能

3. nanobot配置（config.json）

注册两个 cron 作业：每小时巡检（检查指标 + 分析日志 + 告警）和每天日报（汇总 24 小时数据 + 趋势分析）。

{
  "name": "ops-agent",
  "version": "1.0.0",
  "description": "智能运维助手 --- 自动化服务器监控、日志分析和告警",

  "skills": {
    "paths": ["./skills"],
    "auto_load": true
  },

  "cron": {
    "enabled": true,
    "jobs": [
      {
        "name": "hourly-inspection",
        "schedule": "0 * * * *",
        "instruction": "执行一次完整的服务器巡检，检查 CPU、内存、磁盘使用率，分析最近 1 小时内的日志错误，生成巡检报告并保存。如果发现异常（CPU≥70% 或磁盘≥80%），触发告警通知。"
      },
      {
        "name": "daily-report",
        "schedule": "0 9 * * *",
        "instruction": "生成昨日 24 小时的完整运维日报。汇总所有巡检记录，统计异常事件次数和趋势，生成 Markdown 格式的日报保存到 outputs 目录。"
      }
    ]
  },

  "memory": {
    "enabled": true,
    "path": "./memory",
    "type": "file"
  },

  "tools": {
    "allowlist": ["exec", "read_file", "write_file"]
  }
}

4. skills/server-monitor/SKILL.md（服务器监控技能）

# 服务器监控技能

## 描述
提供服务器 CPU、内存、磁盘的实时监控能力，支持阈值告警和趋势分析。

## 使用场景
- 定时巡检时自动调用
- 用户主动询问服务器状态时调用

## 监控命令

### CPU 使用率采集
```bash
top -bn1 | grep "Cpu(s)" | awk '{print $2}' | cut -d'%' -f1

内存使用率采集

free -m

磁盘使用率采集

df -h | awk '$NF=="/"{printf "%s\n", $5}'

综合采集脚本

echo "=== 服务器状态报告 $(date '+%Y-%m-%d %H:%M:%S') ==="
echo ""
echo "--- CPU ---"
top -bn1 | head -5
echo ""
echo "--- 内存 ---"
free -m
echo ""
echo "--- 磁盘 ---"
df -h
echo ""
echo "--- 负载 ---"
uptime
echo ""
echo "--- 关键进程 ---"
ps aux --sort=-%cpu | head -10

结果分析指南

当拿到采集数据后，按以下逻辑分析：

1. CPU 分析：

   • 查看 %us（用户态）和 %sy（内核态）的比值
   • 如果 %sy 超过 30%，可能存在 I/O 瓶颈或系统调用密集
   • 找出 CPU 占用最高的前 5 个进程

2. 内存分析：

   • 关注 available 而非 free（Linux 会用空闲内存做缓存）
   • 如果 swap 使用率 > 0，说明物理内存不足
   • 检查是否有内存泄漏（持续增长的进程）

3. 磁盘分析：

   • 主分区使用率是核心指标
   • 检查 /tmp, /var/log 等易满的目录
   • 如果磁盘使用率 > 80%，列出大文件：find / -size +100M -type f

输出格式

分析结果需要以结构化格式输出：

## 巡检报告 - {时间}

### 整体状态：?正常 / ??警告 / ??严重

| 指标 | 当前值 | 阈值 | 状态 |
|------|--------|------|------|
| CPU  | xx%    | 80%  | ?   |
| 内存 | xx%    | 85%  | ?   |
| 磁盘 | xx%    | 80%  | ?   |

### 异常详情
（如有异常，在此详细说明）

### 建议操作
（基于当前状态给出操作建议）


## 4. skills/log-analyzer/SKILL.md（日志分析技能）

```bash
# 日志分析技能

## 描述
分析系统日志和应用日志，提取错误信息，识别异常模式，支持趋势分析。

## 使用场景
- 巡检时分析最近日志
- 排查特定时间段的异常
- 统计错误频率和类型

## 日志采集命令

### 系统日志分析
```bash
# 最近 100 条错误日志
tail -1000 /var/log/syslog 2>/dev/null | grep -i "error\|fail\|critical" | tail -100

# 按小时统计错误数量
grep -i "error" /var/log/syslog 2>/dev/null | awk '{print $1, $2, $3}' | cut -d: -f1,2 | sort | uniq -c | sort -rn | head -20

# OOM Killer 事件
dmesg | grep -i "oom\|out of memory" | tail -20

应用日志分析

# Nginx 错误日志
tail -500 /var/log/nginx/error.log 2>/dev/null | grep -v "favicon" | tail -50

# 5xx 错误统计
awk '$9 ~ /^5/ {print $9}' /var/log/nginx/access.log 2>/dev/null | sort | uniq -c | sort -rn

# 慢请求统计（响应时间 > 1s）
awk '$NF > 1.0 {print $7, $NF"s"}' /var/log/nginx/access.log 2>/dev/null | sort -t' ' -k2 -rn | head -20

分析策略

错误分类

拿到错误日志后，按以下类别分类：

类别	关键词	严重程度	处理建议
系统资源	OOM, disk full, no space	🔴 严重	立即处理
服务异常	service failed, connection refused	🔴 严重	检查服务状态
网络问题	timeout, connection reset	🟡 警告	检查网络配置
权限问题	permission denied, access denied	🟡 警告	检查权限设置
配置错误	invalid config, parse error	🟡 警告	检查配置文件
一般警告	warning, deprecated	🟢 一般	后续处理即可

趋势识别

1. 对比过去 1 小时和过去 24 小时的错误率
2. 如果错误率呈上升趋势（增长 > 50%），标记为需要关注
3. 如果某类错误在短时间内大量出现（> 50条/10分钟），触发告警

输出格式

## 日志分析报告 - {时间段}

### 错误统计
| 类别 | 数量 | 趋势 | 示例 |
|------|------|------|------|
| 系统资源 | 3  | ↑ 上升 | OOM killed process nginx |
| 网络问题 | 12 | → 稳定 | Connection timed out |

### 高频错误 Top 5
1. `[错误信息]` - 出现 xx 次 - 首次出现于 xx:xx
2. ...

### 需要关注
- 🔴 [紧急问题描述]
- 🟡 [需关注问题描述]


### 5.部署运行
在Docker上部署：
（Docker下载网站：https://www.docker.com/products/docker-desktop/）