必须设告警的指标包括：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 次告警全是虚惊。
