全栈监控需分层覆盖硬件层（磁盘iops、nvme延迟、网卡丢包）、内核层（调度延迟、中断耗时、页回收）、进程层（rss/vsz/fd数、线程数、cpu占比）、应用层（ebpf注入业务语义）；指标须可归因、可下钻，如cpu拆解为user/sys/iowait/irq/softirq并关联cgroup/pid，内存区分activefile/inactiveanon并结合memcg.stat；所有指标打标hostname/role/cgroup path/kernel version；采集策略按高频（1s，5分钟原始粒度）、低频（30s～2min，按需开启）、事件型（inotify+auditd实时捕获）分级；用ebpf_exporter降开销；指标体系支撑根因定位，预置故障组合路径（如响应慢联动tcptimeouts/retranssegs/pidstat），内置规则引擎支持阈值、同比突增、多指标联合告警。
核心监控维度要覆盖全栈链路
Linux 性能监控不能只盯 CPU 或内存单点指标，需按“硬件层 → 内核层 → 进程层 → 应用层”分层建设。硬件层关注磁盘 IOPS、NVMe 延迟、网卡丢包率；内核层重点采集调度延迟（sched_delay）、中断/软中断耗时、页回收速率（pgpgin/pgpgout）；进程层记录每个关键进程的 rss/vsz/fd_count、线程数、CPU 时间片占比；应用层则通过 eBPF 注入或 /proc/PID/status 补充业务语义，比如数据库连接数、HTTP 队列长度。
关键指标必须可归因、可下钻
避免只采集平均值。例如 CPU 使用率要拆解为：user/sys/iowait/irq/softirq 五类，并关联到具体 cgroup 或 PID；内存要区分 ActiveFile/InactiveAnon，结合 memcg.stat 判断是否由某容器触发 OOM；磁盘延迟不能只看 iostat 的 await，要同步采集 blktrace 中的 queue → issue → complete 耗时分布。所有指标需打上标签：hostname、role（db/cache/app）、cgroup path、kernel version。
采集策略需适配场景与开销平衡
- 高频指标（如 CPU idle、loadavg、proc stat）设为 1s 采集，但仅保留最近 5 分钟原始粒度，其余降采样为 15s 均值
- 低频高开销指标（如 slabinfo、vmstat -s 全量、perf record）控制在 30s～2min 一次，且默认关闭，按需开启
- 事件型指标（OOM kill、TCP retransmit、ext4 error）采用 inotify + auditd 实时捕获，不依赖轮询
- 使用 ebpf_exporter 替代部分 /proc 解析，减少上下文切换和字符串处理开销
指标体系要支撑根因定位闭环
指标不是孤立存在的。设计时需预置常见故障的指标组合路径：比如“服务响应变慢”应联动查看 netstat -s TCPTimeouts + cat /proc/net/snmp | grep RetransSegs + pidstat -w 1；“内存持续增长”需比对 cat /sys/fs/cgroup/memory/xxx/memory.usage_in_bytes 与 ps aux --sort=-%mem | head -10 是否一致，再查 slabtop -o 判断是否为内核对象泄漏。所有指标采集端内置简单规则引擎，支持阈值触发、同比突增检测、多指标联合告警（如 iowait > 70% 且 avgqu-sz > 32 同时成立才告警）。
