Linux 如何建设可观测性体系？

linux可观测性体系需统一采集metrics、logs、traces三类信号：journald为日志唯一入口，rsyslog用imjournal转发；node_exporter须精简collector并过滤虚拟设备；ebpf_exporter补足内核级指标；全链路时间同步与label设计是关联分析关键。

Linux 环境下建可观测性体系，不是装一堆工具就完事——核心是围绕 metrics、logs、traces 三类信号，用最小侵入方式把真实运行态数据持续、稳定、可关联地采集上来。

用 systemd-journald + rsyslog 统一日志入口

直接读 /var/log/messages 或轮询 journalctl 输出，会导致时间戳不一致、字段缺失、权限混乱。应让 systemd-journald 作为唯一日志接收端，再通过 rsyslog 转发结构化数据：

• ForwardToSyslog=yes 在 /etc/systemd/journald.conf 中启用，确保所有服务日志进 journald
• 用 imjournal 模块（非 imuxsock）在 rsyslog.conf 中对接 journald，保留 _PID、_COMM、SYSLOG_IDENTIFIER 等原生字段
• 禁用 imfile 直接读文件——它无法捕获 journal 的二进制元数据，且容易丢行

用 node_exporter 但别全量采集

node_exporter 默认开启 20+ collector，其中 textfile、netstat、conntrack 在高并发机器上会显著拖慢采集周期，甚至触发 prometheus 抓取超时。

• 启动时显式关闭低价值项：--no-collector.hwmon --no-collector.rapl --no-collector.bonding
• 对 diskstats，用 --collector.diskstats.ignored-devices="^(ram|loop|fd|nvme[0-9]+n[0-9]+|zram)[0-9]*$" 过滤虚拟设备
• 自定义指标优先走 textfile collector：写入 /var/lib/node_exporter/textfile_collector/app_build.prom，内容如 app_build_info{branch="main",commit="a1b2c3"} 1，避免在进程内硬编码指标逻辑

用 ebpf_exporter 补足传统 metrics 盲区

进程级 CPU/内存等基础指标掩盖了内核调度、IO 调度、TCP 重传等关键瓶颈。靠 perf 或 sysdig 手动分析太滞后，需实时导出 eBPF 指标到 Prometheus：

• 用 ebpf_exporter 加载预编译的 tcp_rtt.py 或 biolatency.py（来自 bcc-tools），暴露 tcp_rtt_us_bucket、biolatency_us_bucket 等直方图指标
• 避免在生产环境跑 bpftrace 一类交互式工具——它会动态编译，可能触发内核模块加载失败或占用大量内存
• 注意 ebpf_exporter 的 config.yaml 中 maps 定义必须与 eBPF 程序中 map 名称严格一致，否则指标为 0 且无报错

真正难的不是部署组件，而是让 logs 中的 request_id 能查到对应时刻的 node_exporter CPU 队列长度，再关联上 ebpf_exporter 的 TCP 重传次数——这要求所有采集器使用同一 NTP 源、所有日志打点带纳秒级时间戳、所有指标 label 设计预留 trace 关联字段。漏掉任意一环，可观测就退化成“可看见”。