必须设告警的指标包括：1. load average 持续高于 CPU 核数×1.5；2. MemAvailable 低于总内存5%；3. 某挂载点 df -P Use%≥90%且连续3次未回落；4. ss 统计 ESTABLISHED 连接突增或 LISTEN 端口消失；5. journalctl 按 unit 和时间窗捕获关键错误日志。

哪些指标必须设告警，而不是“看着办”

CPU、内存、磁盘使用率这类基础指标，单独看阈值容易误报。真正该触发告警的是：load average 持续高于 CPU 核数 × 1.5、/proc/meminfo 中的 MemAvailable 低于 5% 总内存、df -P 显示某挂载点 Use% ≥ 90% 且连续 3 次采样未回落。

• load average 高但 CPU idle 高？可能是 I/O 等待，需同步查 iostat -x 1 3 的 %util 和 await
• 内存告警必须基于 MemAvailable，而非 Free 或 Buffers+Cached，否则容器场景下几乎必误报
• 磁盘告警要排除临时文件系统（如 tmpfs）、容器 overlay2 目录，过滤命令加 | grep -vE "(tmpfs|overlay)"

用 systemd 做进程存活告警最稳的方式

别依赖定时脚本轮询 ps，systemd 自带健康检查更可靠。关键在服务单元文件里配对三行：

[Service]
Restart=on-failure
RestartSec=10
StartLimitIntervalSec=60

这表示：进程异常退出后等 10 秒重启；1 分钟内失败超 5 次（默认 StartLimitBurst=5）就停服并触发 systemctl is-failed 可捕获的状态。

• 必须显式设置 Type=simple 或 Type=notify，否则 Restart=on-failure 不生效
• 想让告警包含具体退出码，加 ExecStopPost=/usr/local/bin/alert.sh %N %L %s，其中 %s 是 exit code
• 避免用 Restart=always，它连 kill -9 都拦不住，会掩盖真实故障

netstat 已过时，用 ss 查连接数告警才准

netstat 在高并发下性能差、结果不准，ss 是唯一可信赖的替代。监控 ESTABLISHED 连接突增，执行：

ss -tan state established | wc -l

但注意：这个数字含 TIME_WAIT，真要盯活跃连接，得加 -o 看计时器，或用 ss -tn src :80 | wc -l 锁定特定端口。

• ss -s 输出的 tcp: 行里 estab 字段才是当前 ESTABLISHED 数，比管道统计快一个数量级
• 查 LISTEN 端口是否被意外关闭，用 ss -tln | grep ":22" | wc -l，返回 0 就该告警
• 不要用 netstat -an | grep ESTAB | wc -l，在万级连接时延迟可达秒级，错过告警窗口

日志关键词告警别硬匹配，先过 journalctl 过滤

直接 tail -f /var/log/messages | grep "OOM" 会漏 systemd-journald 的二进制日志，且无法按服务单位隔离。正确做法是：

journalctl -u nginx --since "2 minutes ago" | grep -q "failed\|timeout" && echo "NGINX health issue"

关键在 -u 按 unit 过滤、--since 控制时间窗，避免全量扫描。

• 高频日志（如 auditd）要用 --priority 限级别，否则 journalctl -n 1000 可能卡住
• 匹配关键词优先用 journalctl -g "Out of memory"，比外部 grep 快 3–5 倍
• 别把 journalctl 放 cron 里每分钟跑一次，改用 SYSTEMD_LOG_LEVEL=4 journalctl --follow --output=json 流式消费

监控策略最常被忽略的不是阈值设多高，而是采样周期和告警抑制没对齐——比如磁盘清理脚本每 5 分钟跑一次，而告警检测间隔设成 30 秒，结果连续 10 次告警全是虚惊。