一、服务器监控Skill的设计
服务器监控Skill的核心目标是实现服务器健康状态和性能指标的自动化监测，帮助运维人员和开发团队快速发现并诊断性能问题。通过将监控能力封装为Claude Code Skill，可以在日常开发运维工作中随时调起监控流程，无需切换工具或平台。
1.1 设计原则
- 全面覆盖：覆盖CPU、内存、磁盘、网络、进程、日志等关键维度，不留监控死角
- 自动化执行：一键触发自动采集和分析，减少人工干预和重复劳动
- 智能告警：基于阈值和异常检测算法，及时推送告警通知
- 可追溯：保留历史监控数据，支持趋势分析和容量规划
- 可扩展：插件化架构支持自定义监控指标和告警规则
1.2 Skill定义示例
# CLAUDE.md 中的Skill定义
server-monitor:
description: 执行服务器性能和健康监控
triggers:
- /monitor server
- /server-health
args:
- name: target
description: 监控目标（如 localhost、IP地址 或 服务器组名）
required: false
- name: duration
description: 监控持续时间（秒），默认60
required: false
steps:
- 收集指定服务器的系统资源指标（CPU、内存、磁盘、网络）
- 检查关键进程运行状态和端口可达性
- 扫描应用日志中的ERROR级别异常
- 分析性能瓶颈并提供优化建议
- 生成健康状态报告
设计思路：将服务器监控Skill设计为通用可配置的斜杠命令。通过target参数指定监控目标，duration参数控制采样时长，使其既可用于快速健康检查，也可用于深度性能诊断。
二、系统资源监控
系统资源监控是服务器监控的基础层，涵盖CPU、内存、磁盘和网络四大核心资源。实时的资源数据采集和趋势分析是发现性能问题的第一道防线。
2.1 CPU使用率和负载监控
CPU监控需要关注以下关键指标：整体使用率、用户态/内核态占比、I/O等待时间、以及系统平均负载（load average）。通过采集这些指标可以判断CPU是否成为系统瓶颈。
#!/bin/bash
# CPU监控采集脚本
echo "=== CPU 使用率 ==="
# 使用 top 获取CPU使用率概况（批处理模式，单次采集）
top -bn1 | head -5
echo ""
echo "=== CPU 负载平均值 ==="
cat /proc/loadavg
echo ""
echo "=== 每个CPU核心使用率 ==="
mpstat -P ALL 1 1
echo ""
echo "=== 上下文切换次数 ==="
vmstat 1 1 | tail -1
2.2 内存使用分析和泄漏检测
内存监控需要关注总内存、已用内存、空闲内存、缓存/缓冲区和Swap使用情况。内存泄漏是长期运行服务的常见问题，需要通过进程级别的内存增长趋势来检测。
#!/bin/bash
# 内存监控采集脚本
echo "=== 内存使用概况 ==="
free -h
echo ""
echo "=== 内存详细统计 ==="
cat /proc/meminfo
echo ""
echo "=== 按内存使用率排序的进程 Top 10 ==="
ps aux --sort=-%mem | head -11
echo ""
echo "=== SWAP 使用情况 ==="
swapon --show
注意：内存泄漏的典型特征是进程RSS（ Resident Set Size）持续增长不回落，即使在没有活跃请求的空闲状态下也是如此。建议对关键服务设置进程内存上限，并结合历史数据做趋势对比。
2.3 磁盘使用率和IO统计
磁盘监控包含两个维度：空间使用率（是否会写满）和IO性能（是否成为瓶颈）。空间使用率关注各分区的已用百分比和Inode使用率；IO性能关注iowait%、IOPS、吞吐量和平均服务时间。
#!/bin/bash
# 磁盘监控采集脚本
echo "=== 磁盘分区使用率 ==="
df -h
echo ""
echo "=== Inode 使用率 ==="
df -i
echo ""
echo "=== 磁盘IO统计 ==="
iostat -x 1 3
echo ""
echo "=== IO密集型进程 ==="
iotop -b -n 1 -o
2.4 网络流量和连接数监控
网络监控关注带宽使用率、连接数、连接状态分布和错误包统计。异常的连接数增长或大量TIME_WAIT状态连接通常预示着应用层问题。
#!/bin/bash
# 网络监控采集脚本
echo "=== 网络接口流量统计 ==="
ip -s link
echo ""
echo "=== 当前TCP连接状态分布 ==="
ss -t state all | awk '{print $1}' | sort | uniq -c | sort -rn
echo ""
echo "=== 监听端口列表 ==="
ss -tlnp
echo ""
echo "=== 各连接状态的计数 ==="
netstat -n | awk '/^tcp/ {print $6}' | sort | uniq -c
2.5 关键指标趋势分析
单次采集只能反映瞬态状态，趋势分析才能揭示问题的演变规律。通过定时采集（如每分钟一次）并将数据存入时序数据库，可以绘制出资源使用趋势图，用于容量规划和异常检测。
最佳实践：建议将监控数据持久化到时序数据库（如Prometheus、InfluxDB或VictoriaMetrics），并结合Grafana等可视化工具展示趋势图表。保留周期建议：原始数据保留7天，聚合数据（5分钟粒度）保留30天，日聚合数据保留1年。
三、进程和应用监控
进程和应用监控关注的是运行在服务器上的软件服务的健康状态。与系统资源监控不同，应用监控更关注服务是否按预期工作，而不仅仅是资源是否充足。
3.1 关键进程运行状态检查
通过检查关键进程的存在性、运行时长和资源消耗来判断服务是否正常运行。对于守护进程，还需要检查其子进程管理是否正常。
#!/bin/bash
# 进程状态检查脚本
APP_LIST=("nginx" "mysqld" "redis-server" "java")
echo "=== 关键进程状态检查 ==="
for proc in "${APP_LIST[@]}"; do
pid=$(pgrep -x "$proc" | head -1)
if [ -n "$pid" ]; then
cpu=$(ps -p "$pid" -o %cpu --no-headers)
mem=$(ps -p "$pid" -o %mem --no-headers)
rss=$(ps -p "$pid" -o rss --no-headers)
uptime_sec=$(ps -p "$pid" -o etime --no-headers)
echo "[OK] $proc | PID=$pid | CPU=$cpu% | MEM=$mem% | RSS=${rss}KB | Uptime=$uptime_sec"
else
echo "[DOWN] $proc - 进程未运行!"
fi
done
3.2 应用端口和HTTP端点可达性
端口监听检查只能确认进程绑定了端口，但不能保证应用正常工作。HTTP端点健康检查通过访问应用的健康检查接口（如 /health、/actuator/health）来验证应用是否真正可用。
#!/bin/bash
# HTTP端点健康检查脚本
SERVICES=(
"nginx:80:/health"
"app:8080:/actuator/health"
"api:3000:/api/v1/health"
)
echo "=== HTTP端点可达性检查 ==="
for service in "${SERVICES[@]}"; do
IFS=':' read -r name port path <<< "$service"
response=$(curl -s -o /dev/null -w "%{http_code}" --connect-timeout 5 "http://localhost:${port}${path}" 2>&1)
if [ "$response" = "200" ] || [ "$response" = "204" ]; then
echo "[OK] $name (端口 $port) - HTTP $response"
else
echo "[WARN] $name (端口 $port) - HTTP $response"
fi
done
3.3 应用日志中的ERROR级别异常检测
日志是了解应用内部状态最重要的途径。通过实时扫描日志中的ERROR、FATAL、Exception等关键字，可以在用户发现问题之前主动告警。同时需要对日志风暴（短时间内大量重复日志）进行检测，避免日志淹没存储。
#!/bin/bash
# 日志异常检测脚本
LOG_DIR="/var/log/applications"
SINCE="5 minutes ago"
echo "=== 最近5分钟日志异常分析 ==="
for logfile in "$LOG_DIR"/*.log; do
[ -f "$logfile" ] || continue
filename=$(basename "$logfile")
error_count=$(grep -c -i "ERROR\|FATAL\|Exception\|NullPointer" "$logfile" 2>/dev/null)
warn_count=$(grep -c -i "WARN\|WARNING" "$logfile" 2>/dev/null)
if [ "$error_count" -gt 0 ]; then
echo "[ALERT] $filename - $error_count 条错误, $warn_count 条警告"
echo " 最新错误:"
grep -i "ERROR\|FATAL\|Exception" "$logfile" | tail -3
else
echo "[OK] $filename - 无错误 ($warn_count 条警告)"
fi
done
3.4 进程资源使用异常检测
进程资源使用异常往往是最先出现的预警信号。CPU使用率突增、内存持续增长、文件描述符泄漏、线程数异常增长等都需要纳入检测范围。
#!/bin/bash
# 进程资源异常检测脚本
THRESHOLD_CPU=80
THRESHOLD_MEM=70
THRESHOLD_FD=1000
echo "=== 进程资源异常检测 ==="
ps aux --sort=-%cpu | tail -n +2 | while read -r line; do
pid=$(echo "$line" | awk '{print $2}')
cpu=$(echo "$line" | awk '{print $3}')
mem=$(echo "$line" | awk '{print $4}')
cmd=$(echo "$line" | awk '{for(i=11;i<=NF;i++) printf "%s ", $i; print ""}')
fd_count=$(ls /proc/"$pid"/fd 2>/dev/null | wc -l)
[ -z "$fd_count" ] && continue
if [ "$(echo "$cpu > $THRESHOLD_CPU" | bc -l)" -eq 1 ]; then
echo "[WARN] CPU超标: PID=$pid CPU=$cpu% CMD=$cmd"
fi
if [ "$(echo "$mem > $THRESHOLD_MEM" | bc -l)" -eq 1 ]; then
echo "[WARN] MEM超标: PID=$pid MEM=$mem% CMD=$cmd"
fi
if [ "$fd_count" -gt "$THRESHOLD_FD" ]; then
echo "[WARN] FD超标: PID=$pid FD=$fd_count CMD=$cmd"
fi
done
四、性能瓶颈分析
性能瓶颈分析是在发现异常指标后进行的深度诊断。目标是从系统层面定位导致性能下降的根本原因，并给出可行的优化建议。
4.1 CPU密集型进程识别
当系统CPU使用率持续偏高时，需要找出消耗CPU最多的进程，并进一步分析是用户态（用户代码逻辑）还是内核态（系统调用）消耗了CPU。
- 使用
top -H -p $PID查看进程内的线程CPU消耗分布
- 使用
perf top -p $PID采样分析热点函数
- 使用
strace -c -p $PID统计系统调用耗时
- 对于Java应用，使用
jstack抓取线程栈分析
#!/bin/bash
# CPU性能瓶颈深度分析
echo "=== CPU 密集型进程 Top 10 ==="
ps aux --sort=-%cpu | head -11
echo ""
echo "=== CPU 负载趋势（最近1、5、15分钟）==="
uptime
echo ""
echo "=== 每个核心的中断分布 ==="
cat /proc/interrupts | head -10
echo ""
echo "=== 如果是Java应用，采集线程栈 ==="
# jstack $PID > /tmp/thread_dump_$(date +%s).txt
echo "建议: 连续采集3次线程栈（间隔5秒），分析锁竞争和热点"
4.2 内存使用异常进程定位
内存问题通常表现为内存泄漏或内存碎片。定位内存异常需要通过进程级内存使用趋势分析和堆内存转储（heap dump）来确诊。
- 通过
ps的RSS和VSZ列识别内存使用异常的进程
- 使用
smem工具查看更准确的USS/PSS内存统计
- 使用
valgrind --leak-check=full检测C/C++程序内存泄漏
- 使用
jmap -dump生成Java堆转储文件，借助MAT或JHAT分析
#!/bin/bash
# 内存异常深度诊断
echo "=== 按RSS排序的进程 Top 15 ==="
ps aux --sort=-%mem | head -16
echo ""
echo "=== 检查OOM Killer历史记录 ==="
dmesg | grep -i "oom" | tail -5
echo ""
echo "=== 检查Swap使用趋势 ==="
vmstat 1 5 | awk '{print $7, $8}'
小技巧：内存泄漏的典型诊断方法是：在服务低峰期记录进程RSS基线值，然后每隔10分钟采集一次，连续采集1小时。如果RSS持续增长而业务流量没有明显变化，大概率存在内存泄漏。
4.3 磁盘IO高延迟问题诊断
磁盘IO延迟高会影响所有依赖磁盘操作的应用性能。诊断时需要区分是IO吞吐达到上限、存在IO冲突、还是特定进程的IO模式导致性能下降。
#!/bin/bash
# 磁盘IO延迟诊断脚本
echo "=== 磁盘IO延迟统计 ==="
iostat -x 1 3
echo ""
echo "=== 等待IO的进程 ==="
ps -eo state,pid,cmd | grep "^D"
echo ""
echo "=== IO队列深度 ==="
for disk in $(lsblk -d -o name | tail -n +2); do
echo "磁盘 $disk 队列深度: $(cat /sys/block/$disk/queue/nr_requests)"
done
echo ""
echo "=== 文件系统使用率 ==="
df -h | grep -E "^/dev|Filesystem"
4.4 网络延迟和丢包分析
网络性能问题可以从延迟、吞吐、丢包和重传四个维度进行分析。使用ping测量基础延迟，使用mtr进行逐跳路径分析，使用ss/tcpdump进行TCP状态分析。
#!/bin/bash
# 网络性能诊断脚本
TARGET_HOST="your-api-server.com"
echo "=== 基础延迟测试 ==="
ping -c 10 "$TARGET_HOST" | tail -1
echo ""
echo "=== 路由路径分析 ==="
mtr -r -c 5 "$TARGET_HOST" 2>/dev/null || echo "mtr 未安装"
echo ""
echo "=== TCP重传统计 ==="
netstat -s | grep -i "retransmit"
echo ""
echo "=== 网络错误统计 ==="
netstat -s | grep -i "error\|drop\|overflow"
echo ""
echo "=== 带宽测试建议 ==="
echo "使用 iperf3 -c 测试TCP吞吐量"
echo "使用 iperf3 -u -c 测试UDP吞吐量和丢包"
4.5 优化建议汇总
CPU优化：优化热点代码逻辑、增加缓存减少重复计算、使用连接池减少线程创建销毁开销、考虑水平扩展分散负载。
内存优化：修复内存泄漏、调整JVM/应用内存参数、使用对象池复用大对象、对大集合设置最大容量限制。
磁盘IO优化：使用SSD替代HDD、调整文件系统挂载参数（noatime等）、优化SQL查询减少全表扫描、增加缓存层减少直接IO。
网络优化：启用TCP快速打开（TFO）、调整内核网络参数（net.core.somaxconn等）、使用CDN减少跨区域延迟、开启HTTP/2多路复用。
五、告警阈值设置与通知
告警系统是监控体系的价值输出端。合理的阈值设置能有效平衡"不漏报"和"不误报"，高效的通知渠道确保问题及时触达责任人。
5.1 告警阈值配置
阈值的设定需要结合实际业务场景和历史数据，避免使用一刀切的固定值。推荐采用三级告警体系：
| 监控指标 |
警告(WARN) |
严重(CRITICAL) |
说明 |
| CPU使用率 |
> 70% 持续5分钟 |
> 90% 持续2分钟 |
需排除短时突发 |
| 内存使用率 |
> 80% |
> 90% |
关注Swap使用量 |
| 磁盘使用率 |
> 80% |
> 90% |
区分数据盘和系统盘 |
| 磁盘IO等待 |
> 30% 持续10分钟 |
> 50% 持续5分钟 |
需要结合IOPS综合判断 |
| 网络连接数 |
> 基线值的150% |
> 基线值的200% |
基线值根据业务峰谷动态调整 |
| 进程状态 |
进程重启 |
进程停止 |
结合进程管理工具自动拉起 |
| 日志ERROR率 |
> 5次/分钟 |
> 20次/分钟 |
排除已知的周期性错误 |
5.2 告警通知渠道配置
不同的告警级别应该对应不同的通知渠道和响应时效：
- INFO（信息）：记录到日志文件或Dashboard展示，无需主动通知
- WARN（警告）：发送到企业微信/钉钉/Slack群机器人，值班人员确认即可
- CRITICAL（严重）：电话/短信告警 + 群机器人@负责人，要求5分钟内响应
- ESCALATION（升级）：严重告警在指定时间内未确认时，自动升级通知到上级主管
# 告警通知配置示例（CLAUDE.md Alert Skill）
alert-manager:
description: 发送监控告警通知
args:
- name: level
description: 告警级别 (info/warn/critical)
required: true
- name: message
description: 告警内容
required: true
- name: source
description: 告警来源（服务器名称）
required: true
steps:
- 根据告警级别选择通知渠道
- 格式化告警消息内容
- 通过Webhook发送到对应渠道
- 记录告警到历史数据库
六、综合健康报告生成
综合健康报告是监控数据的最终产品形态，将采集和分析结果汇总为结构化的报告文档，便于团队了解服务器整体健康状况、跟踪问题处理进度和规划容量。
6.1 报告模板设计
# 服务器健康状态报告
报告时间: $(date '+%Y-%m-%d %H:%M:%S')
服务器: $SERVER_NAME
报告类型: $REPORT_TYPE（快速检查/全面检查/深度诊断）
## 一、整体健康评分
健康评分: 85/100
状态: 良好（存在需要注意的指标）
关键发现: 发现 2 个警告, 0 个严重问题
## 二、系统资源概览
- CPU: 使用率 45% - [OK]
- 内存: 使用率 67% - [OK]
- 磁盘 /: 使用率 72% - [WARN]
- 磁盘 /data: 使用率 85% - [WARN]
- 网络入站: 125 Mbps - [OK]
## 三、进程状态
- nginx: running (PID 12345) - [OK]
- mysql: running (PID 12346) - [OK]
- redis: running (PID 12347) - [OK]
- app-server: running (PID 12348) - [OK]
## 四、性能瓶颈分析
无严重性能瓶颈。磁盘 /data 使用率接近阈值，建议关注。
## 五、优化建议
1. 磁盘 /data 使用率已达85%，建议在1周内扩容或清理数据
2. 近期内存使用呈上升趋势，建议关注是否为业务正常增长
6.2 定期检查计划
不同类型和级别的检查应按照不同的频率执行，以平衡监控覆盖面和资源消耗：
- 快速健康检查（每分钟）：CPU使用率、内存使用率、关键进程状态、端口可达性
- 标准检查（每5分钟）：磁盘使用率、网络流量、日志错误扫描
- 深度检查（每小时）：磁盘IO性能、进程资源趋势、慢查询分析
- 全面检查（每天）：完整系统健康报告、安全审计、证书过期检查
- 容量检查（每周）：资源使用趋势分析、容量预测、扩容建议
实践建议：在生产环境中，将监控Skill与CI/CD流水线或定时任务（Cron Job）集成，实现完全自动化的周期性检查。结合Claude Code的Schedule功能，可以配置每天上午9点自动执行全面健康检查并推送报告到团队群聊。
七、核心要点总结
全面覆盖
监控体系应当覆盖CPU、内存、磁盘、网络、进程和日志六大维度，不留盲区
阈值科学
告警阈值应基于历史数据和业务特征设定，采用三级告警体系减少误报和漏报
趋势为王
单次指标无法反映问题全貌，持续的趋势分析和历史数据比对才是发现隐患的关键
闭环处理
从发现告警到诊断分析到修复验证到复盘总结，形成完整的运维闭环
优化驱动
监控的最终目的是驱动优化，每个告警和发现都应转化为具体的优化行动项
自动化
将监控流程封装为Skill，配合Schedule实现全自动定期检查和告警通知
服务器监控Skill的建设目标：
第一，将所有日常服务器监控工作封装为可复用的Claude Code Skill，实现"一句话"唤起监控能力。
第二，建立从数据采集、指标分析、告警通知到优化建议的全链路自动化体系。
第三，通过持续的趋势分析和容量预测，将运维工作从被动救火转变为主动预防。