Linux服务器监控应围绕“可观测性三支柱”构建闭环：指标量化状态并发现异常，告警需可操作、低误报、带上下文；核心指标分层聚焦CPU、内存、磁盘I/O、网络、进程与服务；告警规则须分级收敛、绑定业务语义、附带上下文；采集宜轻量稳定，优选Node Exporter+自定义exporter；存储按规模选型，冷数据归档；上线后须做故障注入测试、告警回顾及监控自身健康度看板。
Linux服务器监控不是堆工具，而是围绕“可观测性三支柱”（指标、日志、追踪）构建闭环：指标用于量化状态、发现异常；告警是指标的策略化输出，必须可操作、低误报、有上下文。
核心监控指标：分层聚焦，拒绝堆砌
指标不在多，在关键、可解释、可归因。建议按系统层级收敛：
-
CPU：重点关注
cpu_usage_percent{mode="idle"}的反向值（即非 idle）、load1与 CPU 核数比值（>0.7 警示过载）、cpu_steal（云环境突增说明宿主机资源争抢） -
内存：区分
mem_used_percent（含 cache/buffer）和mem_available_bytes（内核 3.14+ 提供真实可用量），警惕swap_in/out持续活跃（内存严重不足） -
磁盘 I/O：看
disk_io_time_ms（单设备每秒 I/O 等待毫秒数）、disk_io_wait_percent（I/O 等待占 CPU 时间比）、disk_used_percent（根分区 >90% 必须告警） -
网络：关注
net_bytes_sent/received（基线对比突增/突降）、net_drop_packets（持续丢包指向驱动、队列或网卡故障）、conn_established（连接数突变常关联业务异常） -
进程与服务：不监控“进程是否存在”，而监控
process_cpu_seconds_total、process_resident_memory_bytes、以及服务端口的probe_success{target=":8080"}（黑盒探测）
告警规则设计：从“触发即告警”到“值得介入”
90% 的无效告警源于规则未绑定业务语义和处置路径。关键原则：
- 分级收敛：P0（立即响应，如 root 分区满、核心服务不可达）、P1（2 小时内处理，如 CPU 持续 >95% 超 10 分钟）、P2（记录观察，如 load1 > 核数但
-
消除抖动：所有阈值类告警必须加
for持续时间（如cpu_usage_percent > 90 for 5m），避免瞬时毛刺；用rate()或irate()替代原始计数器（如错误率用rate(http_requests_total{status=~"5.."}[5m])） -
附带上下文：告警信息中必须包含主机名、IP、关键指标当前值、最近 1 小时趋势链接（如 Grafana 面板跳转 URL）、初步排查指令（如
df -h / && iostat -x 1 3）
数据采集与存储：轻量、稳定、可扩展
采集层决定监控生命力，避免“重客户端、弱服务端”陷阱：
- Agent 选型：Prometheus Node Exporter（标准指标全、资源占用低） + 自定义 exporter（如业务埋点用 Python client lib）；避免全量采集，通过
collector.参数关闭不用项（如--no-collector.wifi） - 抓取配置：对高频率指标（如网络包计数）设长间隔（
scrape_interval: 30s），对关键状态（如服务存活）设短间隔（10s）并配scrape_timeout略小于间隔 - 存储优化：Prometheus 本地存储建议单实例 ≤ 1TB；超规模时用 Thanos 或 VictoriaMetrics；冷数据归档至对象存储（S3/MinIO），保留 30 天高频指标 + 180 天聚合指标
验证与演进：让监控真正“活”起来
上线后必须做三件事：
- 故障注入测试：手动触发 OOM、填满磁盘、kill 关键进程，验证告警是否准时到达、内容是否可指导操作
- 告警回顾机制：每周检查告警记录，标记“误报”“漏报”“无响应”，每月更新规则（如调整阈值、合并相似告警、下线失效规则）
-
指标健康度看板：建一个独立面板，展示各主机采集成功率、指标延迟（
prometheus_target_sync_length_seconds）、告警静默率，把监控系统自身也纳入监控
不复杂但容易忽略
