Margrop
Articles189
Tags383
Categories23
1password AC AI AP API AppDaemon Aqara Caddy Cookie 认证 Cron Date Diagrams.net Docker HA HADashboard HomeAssistant IP IPv4 Java LVM‑Thin Linux MacOS Markdown MiniMax MySQL NAS Nginx OpenAI OpenClaw OpenResty PPPoE PostgreSQL ProcessOn Prometheus Proxmox VE SOCKS5 SSL Shell TTS TimeMachine UML Uptime Kuma VPN VPS Web Windows activate ad adb adblock agent aligenie aliyun alpine annotation aop authy autofs backup baidupan bash bitwarden boot brew browser caddy2 cdn centos cert certbot charles chat chrome classloader client clone closures cloudflare cmd command commit container crontab ctyun ddsm demo dependency deploy developer devtools dll dns docker domain download draw drawio dsm dump dylib edge exception export fail2ban feign firewall-cmd flow frp frpc frps fuckgfw function gcc gfw git github golang gperftools gridea grub gvt-g hacs havcs heap hello hexo hibernate hidpi hoisting homeassistant hosts html htmlparser https idea image img img2kvm import index install intel io ios ip iptables iptv ipv6 iso java javascript jetbrains jni jnilib jpa js json jsonb jupter jupyterlab jvm k8s kernel key kid kms kodi koolproxy koolproxyr kvm lan lastpass launchctl learning lede letsencrypt linux live low-code lvm lxc m3u8 mac macos mariadb markdown maven md5 microcode mirror modem modules monitor mount mstsc mysql n2n n5105 nas network nfs node node-red nodejs nohup notepad++ npm nssm ntp oop openfeign openssl os otp ovz packet capture pat pdf pem perf ping pip plugin png powerbutton print pro proxy pve pvekclean python qcow2 qemu qemu-guest-agent rar reboot reflog remote remote desktop renew repo resize retina root route router rule rules runtime safari sata scipy-notebook scoping scp server slmgr so socks source spk spring springboot springfox ssh ssl stash string supernode svg svn swagger sync synology systemctl tap tap-windows tapwindows telecom template terminal tls token totp tvbox txt ubuntu udisk ui undertow uninstall unlocker upgrade url v2ray vhd vim vlmcsd vm vmdk web websocket wechat windows with worker wow xiaoya xml yum zip 中国电信 云电脑 交换机 健康检查 光猫 公网IP 内存 内网IP 升级 反向代理 启动 夏令时 天猫精灵 天翼云 安全 安装 容器 导入 小米 常用软件 广告屏蔽 序列号 应用市场 异常 打工 技术 抓包 描述文件 效率工具 日记 时区 显卡虚拟化 智能家居 智能音箱 梯子 模块 流程 流程图 浏览器 漫游 激活 火绒 电信 画图 监控 直播源 续期 网关 网络 网络风暴 群晖 脚本 腾讯 自动化 虚拟机 证书 语雀 路由 路由器 软件管家 软路由 运维 运维监控 配置 钉钉 镜像 镜像源 门窗传感器 问题排查 防火墙 阿里云 阿里源 集客

Hitokoto

Archive

从零构建服务器健康检查体系:我的自动化运维实践

从零构建服务器健康检查体系:我的自动化运维实践

前言

作为一名运维工程师,日常工作中最头疼的事情是什么?我相信很多人都会说:是那些”突然爆炸”的服务和永远不知道什么时候会出问题的服务器。

传统的人工巡检方式效率低下,且无法及时发现问题。你不可能24小时盯着监控面板,也不可能每隔5分钟手动检查一次所有服务状态。

于是,我开始思考:能不能写一个自动化健康检查脚本,让它帮我自动完成这些繁琐的工作?

答案是:当然可以。本文将分享我从零构建服务器健康检查体系的完整实践,希望能给遇到类似问题的同学一些参考。

为什么需要健康检查

在开始之前,让我们先思考一个问题:为什么需要健康检查?

传统运维的痛点

  1. 人工效率低:手动检查所有服务器状态耗时耗力
  2. 发现问题滞后:往往是用户反馈了,我们才知道服务挂了
  3. 重复劳动:每天都要做同样的检查,非常枯燥
  4. 夜间盲区:下班后和节假日,服务可能已经挂了很久

健康检查的价值

一个好的健康检查系统可以:

  • 实时监测:第一时间发现服务异常
  • 自动恢复:尝试自动修复常见问题
  • 告警通知:及时通知相关负责人
  • 历史记录:记录故障历史,便于分析

设计思路

1. 检查维度

一个完整的健康检查应该涵盖以下维度:

维度 检查内容 优先级
服务状态 进程是否存活、端口是否监听
资源使用 CPU、内存、磁盘使用率
网络连通性 服务间是否可以正常通信
日志异常 是否有ERROR级别日志
业务指标 关键业务功能是否正常

2. 检查频率

不同维度的检查频率应该不同:

  • 服务状态:每分钟检查
  • 资源使用:每5分钟检查
  • 网络连通性:每5分钟检查
  • 日志异常:每10分钟检查
  • 业务指标:每15分钟检查

3. 告警策略

告警不是越多越好,太多的告警会让人麻木。建议采用分级告警:

级别 触发条件 通知方式 响应时间
P0 致命 服务完全不可用 电话+短信+钉钉 5分钟
P1 严重 服务降级严重 钉钉+短信 15分钟
P2 一般 资源使用率高 钉钉 2小时
P3 警告 轻微异常 邮件 24小时

技术实现

1. 基础架构

我使用了OpenClaw的Cron功能来实现定时健康检查:

1
2
3
4
5
6
7
8
# 健康检查 Cron 配置
cron:
health_check:
enabled: true
schedule: "*/5 * * * *" # 每5分钟执行
timeout: 120 # 超时时间2分钟
retry: 3 # 失败重试3次
retryInterval: 10 # 重试间隔10秒

2. 检查脚本

以下是一个简化的健康检查脚本示例:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
#!/bin/bash

# 健康检查主脚本

# 1. 检查 Gateway 服务状态
check_gateway() {
local status=$(curl -s -o /dev/null -w "%{http_code}" http://127.0.0.1:18789/health)
if [ "$status" -eq 200 ]; then
echo "✅ Gateway: OK"
return 0
else
echo "❌ Gateway: FAILED (HTTP $status)"
return 1
fi
}

# 2. 检查端口监听状态
check_ports() {
local ports=(22 80 443 18789 9229)
for port in "${ports[@]}"; do
if netstat -tlnp 2>/dev/null | grep -q ":$port "; then
echo "✅ Port $port: LISTENING"
else
echo "❌ Port $port: NOT LISTENING"
fi
done
}

# 3. 检查资源使用
check_resources() {
# CPU 使用率
local cpu=$(top -bn1 | grep "Cpu(s)" | awk '{print $2}' | cut -d'%' -f1)
echo "📊 CPU: ${cpu}%"

# 内存使用率
local mem=$(free | grep Mem | awk '{printf "%.2f", $3/$2 * 100.0}')
echo "📊 Memory: ${mem}%"

# 磁盘使用率
local disk=$(df -h / | tail -1 | awk '{print $5}' | cut -d'%' -f1)
echo "📊 Disk: ${disk}%"
}

# 4. 检查网络连通性
check_network() {
# 检查内网连通性
local internal_hosts=("192.168.1xx.1xx" "192.168.1xx.1xx")
for host in "${internal_hosts[@]}"; do
if ping -c 1 -W 1 "$host" > /dev/null 2>&1; then
echo "✅ Internal: $host REACHABLE"
else
echo "❌ Internal: $host UNREACHABLE"
fi
done
}

# 执行所有检查
echo "========== Health Check Started: $(date) =========="
check_gateway
check_ports
check_resources
check_network
echo "========== Health Check Completed: $(date) =========="

3. 告警集成

健康检查脚本需要集成告警功能:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
# 告警通知函数
send_alert() {
local level=$1
local message=$2
local title="[${level}] Health Check Alert"

# 钉钉通知
curl -X POST "https://oapi.dingtalk.com/robot/send?access_token=YOUR_TOKEN" \
-H 'Content-Type: application/json' \
-d "{
'msgtype': 'text',
'text': {
'content': '${title}\n${message}'
}
}"

# 严重告警电话通知
if [ "$level" == "P0" ]; then
# 调用电话告警API
curl -X POST "https://alert.******.com/call" \
-d "message=${message}"
fi
}

4. 定时任务配置

使用OpenClaw的Cron功能配置定时执行:

1
2
3
4
5
6
# 添加健康检查定时任务
openclaw cron add \
--name health_check \
--schedule "*/5 * * * *" \
--script /opt/openclaw/scripts/health_check.sh \
--enabled true

实际效果

部署健康检查体系后,效果显著:

1. 故障发现时间大幅缩短

指标 部署前 部署后
平均故障发现时间 30分钟 2分钟
平均故障恢复时间 2小时 10分钟
月度告警次数 50+ 15-

2. 夜间故障不再”盲区”

健康检查脚本24小时运行,即使在夜间和节假日,也能第一时间发现问题并尝试自动恢复。

3. 运维效率显著提升

以前需要手动完成的检查工作,现在全部自动化。我们可以用更多时间在有价值的工作上,而不是重复劳动。

持续优化

健康检查体系不是一成不变的,需要持续优化:

1. 添加新的检查项

根据实际故障经验,不断添加新的检查项。例如:

  • 证书过期检查
  • 数据库连接池检查
  • 缓存命中率检查
  • 关键API响应时间检查

2. 优化告警阈值

根据实际运行情况,调整告警阈值:

  • 避免告警过于敏感(太多噪音)
  • 避免告警过于迟钝(错过问题)

3. 增加自动恢复能力

对于常见问题,尝试添加自动恢复能力:

  • 服务进程挂掉 → 自动重启
  • 磁盘空间不足 → 自动清理临时文件
  • 内存使用率高 → 尝试释放缓存

常见问题解答

Q:健康检查频率应该如何设置?

A:这取决于你的业务场景。对于关键服务,建议1-5分钟检查一次;对于非关键服务,可以10-30分钟检查一次。频率越高,对系统资源的消耗越大。

Q:如何避免告警疲劳?

A:建议采用分级告警,只对真正重要的问题发送即时通知。可以设置静默时间段,在非工作时间合并告警。

Q:健康检查脚本应该部署在哪里?

A:建议部署在专门的监控服务器上,而不是业务服务器上。这样即使业务服务器完全宕机,健康检查服务器仍能发现问题。

Q:如何处理误报?

A:分析误报原因,调整检查逻辑或阈值。也可以增加二次确认机制,减少误报概率。

Q:自动恢复会不会有风险?

A:自动恢复应该谨慎使用,只对确定性强的问题启用。建议先记录日志再执行恢复操作,便于事后分析。

总结

本文分享了我从零构建服务器健康检查体系的完整实践。核心要点包括:

  1. 设计合理的检查维度:服务状态、资源使用、网络连通性、日志异常、业务指标
  2. 采用分级告警:避免告警疲劳,确保重要问题得到及时响应
  3. 持续优化:根据实际运行经验不断完善检查逻辑

健康检查是运维自动化的基础,只有做好基础工作,才能在运维之路上走得更远。

希望这篇文章能帮到你。如果有问题,欢迎在评论区讨论。


作者:小六,一个在上海努力搬砖的程序员

Author:Margrop
Link:http://blog.margrop.com/post/2026-03-08-server-health-check-system/
版权声明:本文采用 CC BY-NC-SA 3.0 CN 协议进行许可