小团队 VPS 监控清单：系统上线后先看这六件事

作者： OpsMate 团队
更新于 2026-10-29
基于 OpsMate 实机排查整理；命令请在你有权限的服务器上执行，路径与服务名按环境替换。

小团队 VPS 监控，先建立「能发现故障、留住证据、通知到人」的最小流程，而不是一次打开所有告警。服务能打开，不代表有人能及时发现下一次宕机；没有专职运维时，按下面六件事做完第一轮即可上线。

1. 场景：谁需要这份清单

适用：自己管一台或几台 Linux VPS 的开发者、创始人，或刚接手外包搭的机器、招不起全职运维的小团队。不适合：已有完整 SRE 平台、只差微调阈值的大厂环境——那些团队可把本文当对照清单。

常见痛点：上线后只盯首页能不能打开；磁盘或内存打满才从用户投诉里知道；告警发到已离职同事的邮箱；备份脚本在跑，但从没做过恢复演练。

若你还在「接手别人搭的服务器」阶段，先完成盘点再配监控，见接手别人搭的服务器，先查什么？。

2. 步骤：先确认监控对象（六件事）

先写下对象和负责人，再开告警。阈值用你自己的基线，不要套用「所有 VPS 通用」的百分比。

2.1 外部可用性

从服务器以外检查用户真正访问的 HTTPS 路径，记录状态码和延迟。进程在跑不等于用户能打开。可用本机或另一台机器：

curl -sS -o /dev/null -w '%{http_code} %{time_total}s\n' --max-time 10 https://example.com/

把 example.com 换成真实入口。连续失败再告警（例如连续 2–3 次），减少单次网络抖动误报。半夜打不开时的分流顺序见凌晨两点网站打不开。

2.2 资源趋势

看 CPU、可用内存、磁盘容量与 inode；按正常时段的基线和持续时间设阈值，不要只看某一个瞬间。

uptime
nproc
free -h
df -h
df -i

uptime 的 load 要和 nproc 对比。
free -h 看 available，不要把缓存算成「内存不够」。
df -i 为 100% 时，写入会失败，表现常像应用挂了。磁盘飙升分流见磁盘占用突然飙升。

2.3 服务与容器

记下应运行的服务、监听端口、健康检查与重启次数，并为每个服务指定负责人。

systemctl --failed --no-pager
sudo ss -ltnp
docker ps --format 'table {{.Names}}\t{{.Status}}\t{{.Ports}}'

容器反复 Restarting 时，先查退出码和日志，见 Docker 容器反复重启。

2.4 错误日志

关注新增或持续增长的错误，并对照发布时间；同时设保留与轮转，避免日志把盘写满（见 Docker 日志占满磁盘）。

journalctl -p err --since "1 hour ago" --no-pager | tail -n 80

分享前遮盖令牌、连接串和客户信息。

2.5 备份与恢复

不仅看备份任务是否「成功」，更要在隔离环境演练恢复，并写明可接受的数据丢失（RPO）和恢复时间（RTO）。从未演练的备份，不能算监控项完成。

2.6 通知与处置

写清：谁接收、谁确认、谁有变更权限。安排一次人工测试，确认手机真的收到通知。之后要定期故意停掉一个服务（或人为制造一次失败），验收推送是否真到手机；这条通道不要和业务绑在同一台机器上，免得主机挂了，通知也一起断掉。只收告警不需要把 SSH 凭证存到云端；要从 Telegram 远程 SSH 排障，才需要云端托管凭证，见用 Telegram 收服务器告警。

3. 第一轮只读基线（上线当天做一次）

在业务低峰登录机器，执行并记下观察时间：

uptime
free -h
df -h
df -i
systemctl --failed --no-pager
docker ps --format 'table {{.Names}}\t{{.Status}}'

这组命令面向 Linux；未装 systemd 或 Docker 时跳过对应行。单次正常结果不能证明长期健康。外部可用性、恢复演练和通知送达仍需单独验证。

4. 告警：怎么设才不吵死

建议从业务时段和故障影响出发：

类型	建议做法
关键入口	持续探测；连续失败 N 次再告警（如 N=3）
资源	按基线+持续时间；发布后加一轮检查
重复告警	合并或静默窗口，避免同一问题刷屏
升级	写明「只通知」与「需要负责人审批」的边界

具体频率与阈值由负载决定，本文不提供适合所有 VPS 的固定百分比。告警文案里带上：机器名、检查项、最近证据时间，方便值班的人直接对照。

5. 和 OpsMate 的关系

OpsMate（itops.sh）把 SSH 终端和 AI 放在同一页，并可做持续巡检与 Telegram 告警。适合把上面的六件事落成可重复执行的检查，而不是替代你对监控范围的确认。

连接服务器后，可以用自然语言让 AI 帮忙列出服务与风险，例如：

请列出这台服务器上在跑的服务、可观察到的风险和建议监控项。先只收集信息，告诉我哪些尚未验证。由我确认监控范围；任何修复方案都先说明影响、回退和验证步骤。

边界：

AI 以排查为主。未通过安全检查的命令会被拦截且不会执行。低风险修复默认自动执行，每一步都会记录。建议不等于批准。
每次让 AI 帮忙看，终端里最近的输出都会一起发到云端 AI，敏感信息请先去掉。
桌面端默认把 SSH 凭证留在本机；云端巡检和 Telegram SSH 需要你显式选择云端可用的凭证。
OpsMate 自己会做什么、不会做什么，以官网常见问题为准。

巡检适合「持续盯」；终端双通道适合「此刻排障」，见终端里的一句话 AI + 手敲命令。

试用

官网：https://www.itops.sh/
控制台注册：https://app.itops.sh/login?screen=register&lang=zh

每月免费 500 次 AI 调用；服务器数量不限。桌面端默认把 SSH 凭证保留在本机。

参考

curl 手册：用状态码与耗时探测 HTTP(S) — 外部可用性检查的常用工具说明
df(1)：文件系统容量与 inode — 资源与磁盘告警前的基线命令
Prometheus 概览 — 需要自建指标与告警时的参考架构（可选，非必须）
journalctl(1) — 系统错误日志的只读查看

需要帮助理解排查结果？

OpsMate（itops.sh）把 SSH 终端和 AI 放在同一页，由你核对证据。每次让 AI 帮忙看，终端里最近的输出都会一起发到云端 AI，敏感信息请先去掉。

免费开始本地凭证桌面端

排障指南