Linux稳定性需构建可度量SLI/SLO体系：SLI聚焦内核态调度延迟、内存压力、I/O延迟三类真实瓶颈信号；SLO按核心计算、边缘网关、批处理节点分层设定；通过Prometheus二次加工指标实现闭环校验。
Linux系统的稳定性不能只靠“没宕机”来判断，需要可度量、可监控、可追责的指标体系。SLI（Service Level Indicator）是具体可观测的量化数据，SLO（Service Level Objective）是基于SLI设定的可靠性目标。在Linux基础设施层，关键不是照搬应用层SLO，而是聚焦操作系统自身健康态的表达能力。
选对SLI：从内核态和用户态找真实瓶颈
SLI必须反映实际影响业务稳定性的底层行为，而非堆砌无意义的平均值。推荐优先采集以下三类信号：
-
CPU调度延迟：用/proc/sched_debug中的
max_latency或eBPF工具（如runqlat）捕获P99调度延迟，>10ms需告警； -
内存压力信号：不只是
free -h剩余内存，重点看/proc/meminfo中SwapTotal > 0 && SwapFree 、OOM_kill计数、pgmajfault突增； -
I/O等待质量：用
iostat -x 1关注%util > 95%且await > 50ms持续超2分钟，结合/sys/block/*/stat验证队列堆积。
定准SLO：按服务等级分层设目标
SLO不是越严越好，要匹配业务容忍度和运维能力。建议将Linux主机分为三类场景并差异化定义：
- 核心计算节点（如K8s worker、数据库宿主机）：调度延迟P99 ≤ 5ms / 天，OOM事件=0 / 周，I/O高延迟（>50ms）累计≤ 30秒 / 小时；
-
边缘网关节点（如Nginx反向代理）：进程重启率 ≤ 0.1% / 天（通过
systemctl list-jobs --state=failed统计），CPU软中断占比 ≤ 35%； -
批处理节点（如Spark executor）：允许短时内存超配，但要求
/proc/sys/vm/overcommit_ratio配置显式生效，且OOM发生前必须触发cgroup memory.high预警。
落地闭环：用Prometheus+Node Exporter做SLI采集与SLO校验
开箱即用的指标不等于可用SLI，需二次加工：
- 禁用
node_cpu_seconds_total原始指标，改用rate(node_cpu_seconds_total{mode="idle"}[5m])计算真实空闲率，排除中断抖动干扰； - 把
node_memory_MemAvailable_bytes转为内存可用率：(node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes) * 100，并设置SLO阈值线（如 - 用Prometheus Recording Rule预聚合高基数指标，例如定义
job:node_sched_delay_p99_ms=histogram_quantile(0.99, sum(rate(node_sched_delay_seconds_bucket[1h])) by (le, instance)) * 1000，供Grafana直接画SLO达标率热力图。
避免常见陷阱：SLI≠监控项，SLO≠KPI
很多团队把load average当SLI，但它混合了可运行进程、不可中断睡眠、I/O等待，无法定位根因；也有团队把“服务器在线率99.99%”设为SLO，却未定义“在线”的判定逻辑（ping通？SSH可登录？关键服务端口响应？）。正确做法是：
- 每个SLI必须附带明确的采集方式、单位、采样周期、异常判定条件（如“连续3次采样超阈值”）；
- 每个SLO必须绑定响应动作，例如“调度延迟超标持续5分钟 → 自动降级非核心定时任务”；
- 每季度用
perf record -e sched:sched_switch -a sleep 60回溯一次真实调度链路，验证SLI是否真能反映内核调度质量。
