systemd journal：生产环境的日志中枢
systemd journal是Linux系统日志的核心组件，它取代了传统的rsyslog方案，提供了结构化存储、高效查询和二进制压缩等优势。在生产环境中，正确配置和使用journal是故障排查的基础。
journal默认将日志存储在/dev/shm中（临时文件系统），重启后会丢失。对于需要保留历史日志的场景，需要配置持久化存储：
# 修改/etc/systemd/journald.conf [Journal] Storage=persistent SystemMaxUse=1G SystemKeepFree=1G RuntimeMaxUse=512M
修改配置后重启systemd-journald服务生效。持久化存储将日志写入/var/log/journal目录，即使系统重启也不会丢失。
journal的查询能力非常强大。journalctl支持基于时间、优先级、系统单元等多种维度的过滤查询。常用的查询场景包括：
查询最近10分钟的错误日志：
journalctl -p err --since "10 min ago"
查看特定服务的日志：
journalctl -u nginx.service -n 100 --no-pager
实时监控日志（类似tail -f）：
journalctl -f -u myapp.service
查询某个时间范围之外的完整日志：
journalctl --since "2026-09-15 08:00:00" --until "2026-09-15 09:00:00"
perf工具链：内核级性能分析
perf是Linux内核提供的性能分析工具，基于硬件性能计数器（PMC）和eBPF实现。它可以测量CPU周期、缓存命中/MISS、分支预测命中率等底层指标，是定位性能瓶颈的强大工具。
CPU性能分析
使用perf record捕获程序的CPU性能事件，然后用perf report生成分析报告：
# 录制目标程序的性能数据 perf record -g -o perf.data ./my_application # 生成报告，按调用栈排序 perf report -i perf.data --stdio
-g选项启用调用栈采集，这对分析函数级别的性能热点非常重要。报告中会显示每个函数的自占时间占比和调用关系树。
追踪系统调用
strace和perf trace都可以追踪系统调用，但perf trace的性能开销更低，适合生产环境使用：
# 追踪特定PID的所有系统调用 perf trace -p 1234 # 追踪fork和exec调用 perf trace -e fork,execve,exit_group
eBPF性能分析
bpftrace是eBPF的高层脚本语言，非常适合快速编写性能分析脚本：
# 统计每个进程的syscall次数
#!/usr/bin/bpftrace
BEGIN
{
printf("Tracing syscalls...
");
}
kprobe:sys_read
{
@read_count[tid] = count();
}
interval:s:10
{
print(@read_count);
clear(@read_count);
}保存为syscall.bt后运行：bpftrace syscall.bt。这会每10秒输出一次每个进程的read syscall调用次数统计。
综合排查案例
某生产服务器出现CPU占用率突然升高的问题。排查步骤如下：
第一步，用top和htop定位高CPU进程：
top -p $(pgrep -f myapp)
第二步，用perf记录该进程的CPU采样：
perf record -g -p-- sleep 30 perf report -i perf.data
报告发现某个正则表达式匹配函数占用35%的CPU时间。
第三步，用strace追踪该进程的syscall：
perf trace -p--duration 30
发现大量stat系统调用，定位到代码中频繁检查文件是否存在的问题。
第四步，修改代码，使用inotify代替轮询，CPU使用率从45%降至8%。