先监控用户能否访问，再监控机器数字
CPU 20%、内存 60% 看起来正常，域名解析错误或证书过期仍会让网站完全不可用。监控应从外到内分层：外部 HTTPS 请求、反向代理、应用健康、依赖、系统资源、备份。每一层都要有负责人和处理动作，否则只是把图表收藏起来。 对单服务器而言，少量高信号指标比几十张仪表板更实用。先建立能在夜里把真正故障告诉你的最小集合。
第一层：从服务器外部请求真实域名
每分钟或五分钟从另一网络请求 https://www.example.com/health，检查 DNS、TCP、TLS、状态码和响应时间。只在服务器本机 curl 会漏掉公网路由、证书和防火墙问题。 健康页面应轻量，不泄露版本、数据库地址或密钥。可以区分 liveness 与 readiness：前者说明进程活着，后者说明已经准备接收请求。公开监控还要检查证书剩余天数和域名到期提醒。
第二层：进程、容器和依赖
systemd 服务检查 active 状态、重启次数和最近失败；Compose 检查容器状态与 health。数据库监控连接是否成功、容量是否接近限制、慢查询是否突然增加。不要只监控 PID 存在，必须请求实际功能。
systemctl is-active myapp caddy
systemctl show myapp -p NRestarts
docker compose ps
journalctl -u myapp --since '15 minutes ago' --no-pager手工命令适合排查，持续监控可由现有监控系统采集。无论使用哪种工具，都保留一条不依赖被监控服务器本身的外部告警路径。
第三层：CPU、内存、磁盘和负载
CPU 短时 100% 可能只是构建或压缩，持续高占用并伴随响应变慢才值得告警。内存要同时看 available、Swap 活动和 OOM 记录，不要只看 used，因为 Linux 会利用空闲内存做缓存。负载值要结合 CPU 核数和 I/O 等待解释。 磁盘往往比 CPU 更紧急。根分区达到 85% 后先找增长来源，日志、容器层、备份和上传分别处理；不要写一个自动 rm -rf 清理未知目录。还要监控 inode，很多小文件也能让磁盘无法继续写入。
备份年龄是必须告警的业务指标
监控最近成功备份时间、体积与校验结果。今天的文件只有昨天一半，任务即使退出码为 0 也可能异常。异地上传失败、本地备份不断增长、恢复演练过期都应进入检查清单。 以 RPO 决定阈值：每天备份的网站，超过 26 或 30 小时没有成功副本就应提醒；不要等一周后才发现定时任务早已失效。
日志告警看模式，不转发全部文本
关注短时间 5xx 激增、登录失败异常、数据库连接耗尽、OOM、磁盘只读和服务反复重启。单个偶发 404 不值得半夜叫醒人。告警内容带上时间、主机、服务、最近变更和排查入口，但过滤密码、Cookie 与请求正文。 阈值同时包含数值与持续时间，例如磁盘使用超过 85% 持续 10 分钟。设置 warning 和 critical 两级，并设计恢复通知，避免问题已经结束却无人知道。
每个告警必须有第一步动作
“CPU 高”不够，告警附上查看进程、最近发布和流量的步骤；“网站不可用”先从外部重试，再看 DNS/TLS/Caddy/上游。每月回顾误报、漏报和无人处理的告警，删除无法行动的噪声。 完成标准是：公网故障、服务退出、磁盘逼近上限、备份过期和 5xx 异常都能在用户投诉前被发现，且接收者知道第一步做什么。下一篇把这些信号放进 502、504 与 HTTPS 分层排错。
参考来源
- journalctlsystemd