一台小服务器的日常巡检清单:每天十分钟,别等出事才看日志
一台小服务器的日常巡检清单:每天十分钟,别等出事才看日志
手头只有一台配置不高的小服务器时,最怕的不是性能不够,而是平时没人看、出了问题才发现磁盘满了、服务早停了。我给自己定了一套每天十分钟的巡检清单,分享出来,适合个人项目和小站点参考。
先看三项硬指标
巡检从资源开始,不用上监控大盘,三条命令就够:
df -h # 磁盘用量,重点看根分区和日志分区
free -h # 内存和 Swap,Swap 长期被大量占用要警惕
uptime # 负载和运行时间,负载持续高于核数就要查
磁盘是最常见的“静默杀手”。日志、备份、下载文件会慢慢吃掉空间,等到写不进数据时,数据库和应用往往一起报错。我的习惯是根分区用到 80% 就处理:先清旧日志和临时文件,再决定要不要扩容,而不是等到 100% 才抢修。
再确认服务是不是真的活着
进程在,不等于服务可用。巡检时除了看进程,更要看端口和关键接口:
ss -tlnp | grep -E '80|443' # Web 端口是否在监听
systemctl is-active nginx # 关键服务状态
curl -s -o /dev/null -w '%{http_code}' http://127.0.0.1/health
最后一行是关键:直接请求一次健康检查接口,返回 200 才算服务真的活着。只看进程的做法,曾经让我漏掉过一次“进程在、但端口被异常配置顶掉”的故障。
日志只看异常,不通读
日志不需要每天从头读到尾,巡检的重点是找新增的异常。我的做法是只看最近一天的错误关键词:
journalctl --since "24 hours ago" -p err --no-pager | tail -50
grep -iE 'error|failed|timeout' /var/log/nginx/error.log | tail -50
如果某类错误突然变多,先记下来、再判断是不是要修,不要一看到报错就立刻改配置。很多偶发超时和重试失败,本身就是网络抖动,改动反而容易引入新问题。
备份要验证,不能只看“备份成功”
备份任务显示成功,不代表备份文件能用。每月至少做一次恢复演练,哪怕只是把备份解压到临时目录、核对文件数量和数据库能否打开:
tar -tzf backup-2026-10-29.tar.gz | head
ls -lh /backup/ # 备份文件大小异常变小也要警惕
备份还要留一份在服务器之外。同一台机器上的备份,只能防误删,防不了磁盘损坏和整机故障。异地哪怕只是一个对象存储桶,也比本地双份可靠得多。
安全巡检顺手做三件
每天顺手看三处,花不了两分钟:
- 异常登录:看最近的 SSH 登录记录,有陌生 IP 立刻处理。
- 开放端口:确认只开了业务需要的端口,多余端口及时关闭。
- 系统更新:安全更新不要拖太久,先在测试环境验证再上生产。
last -20
ss -tlnp
把巡检变成定时提醒
清单再好,靠记性也坚持不了多久。我的做法是把巡检命令写成一个脚本,每天定时跑一次,只把异常结果汇总发出来,没异常就不打扰:
# 每天 09:00 跑巡检脚本,输出写入日志
0 9 * * * /usr/local/bin/daily-check.sh >> /var/log/daily-check.log 2>&1
脚本里只做只读检查,不自动重启服务、不自动删文件。自动修复听起来省事,但误判时破坏力更大,先让人看结果、再手动处理,是小服务器更稳妥的节奏。
小结
小服务器的运维核心不是工具多高级,而是节奏稳定:每天看资源、确认服务真活着、扫一眼新增异常、定期验证备份、顺手看安全。十分钟的巡检,换来的是出问题时不慌——因为你知道昨天它还是正常的,问题范围一下子就缩小了。
- 点赞
- 收藏
- 关注作者
评论(0)