凌晨两点的电话
上个月的一个晚上——准确说是凌晨两点——我被运维的电话叫醒。
“线上那个支付服务卡死了，没有任何报错日志，CPU和内存都正常，但就是不响应请求。”
我迷迷糊糊地连上服务器，top一看，进程还在，但就是一条请求都处理不了。journalctl翻到最近的日志，最后一条是正常的业务日志，之后就沉默了——就好像这个进程突然决定躺平了一样。
没有报错日志，这就很头疼了。好在，我们还有 strace。
一条命令下去，问题秒定位：进程卡在 futex 系统调用上——某个线程持锁后挂了，所有其他线程都在等这把锁。
这就是 strace 的威力：当所有日志都沉默的时候，系统调用会告诉你真相。
今天这篇文章，我不会给你抄 man page。我会用四个真实生产场景，带你掌握 strace 的正确用法——以及那些文档不会告诉你的坑。
strace 到底是什么
简单说：strace 是 Linux 下的系统调用追踪器。它可以在一个进程执行每次系统调用（syscall）时，打印出调用的名称、参数、返回值。
什么是系统调用？就是你的程序跟操作系统内核打交道的接口。读文件、写socket、申请内存、创建线程——这些操作最终都要通过系统调用完成。也就是说，strace 能看到你的程序在”物理层面”到底在干什么。
举个例子，你的 Python 代码里写了一行 open("config.json")，strace 会告诉你它实际调用的是：
openat(AT_FDCWD, "config.json", O_RDONLY) = 3
read(3, "{...}", 4096) = 1024
close(3) = 0Python解释器、标准库、底层运行时——所有层都被穿透了，你看到的是最原始的真相。
四个生产环境实战场景
场景一：定位进程”假死”——futex 死锁
回到开头的故事。进程在 top 里状态显示 S（sleeping），不消耗CPU，但就是没反应。
直接 attach 上去看看它在等什么：
$ strace -p 28491 -f -e trace=futex
strace: Process 28491 attached with 8 threads
[pid 28493] futex(0x7f8b4c0010a0, FUTEX_WAIT_PRIVATE, 2, NULL) = -1 EAGAIN
[pid 28494] futex(0x7f8b4c0010a0, FUTEX_WAIT_PRIVATE, 2, NULL输出显示所有工作线程都卡在 futex(FUTEX_WAIT_PRIVATE) 上——这是 pthread mutex 的底层实现。所有线程都在等同一把锁，而持锁的那个线程大概率已经挂了。
用 -f 追踪所有线程，用 -e trace=futex 只过滤锁相关调用，问题一目了然。
如果你想知道是哪个倒霉线程在持锁，可以加 -k 打印内核调用栈：
$ strace -p 28491 -f -e trace=futex -k -o /tmp/strace.log-k 会在每次系统调用后打印内核空间的函数调用链，帮你定位到具体是哪个内核路径导致的阻塞。这个选项在 CentOS 7 之后的内核上都支持。
场景二：文件打开失败但日志里没有
有一次上线后，服务运行正常但某个功能就是404。查了应用日志，没报错。
怀疑是没读到配置文件——但应用的错误处理写得跟屎一样，异常被吞了。直接上 strace 追文件操作：
$ strace -p 12934 -e trace=open,openat,stat -f 2>&1 | grep -E "ENOENT|EACCES"
[pid 12935] openat(AT_FDCWD, "/opt/app/config/production.yaml", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 12935] openat(AT_FDCWD, "/opt/app/config/production.yml", O_RDONLY) = 3真相大白：配置文件叫 production.yml，但程序先尝试了 production.yaml。第一次打开返回 -1 ENOENT（文件不存在），然后才 fallback 到正确的文件名。这本该是一条 WARNING 日志，但被某个 try-except 吞了。
这个场景极其常见。越是”没报错但行为诡异”的 bug，越适合用 strace 来扒。
场景三：追查”幽灵”网络调用
服务偶尔出现 5 秒级别的响应延迟，但 APM 上看不到任何慢查询或慢 RPC。
$ strace -p 18823 -f -e trace=network -T 2>&1 | grep -A2 "<5\\."
解释一下：-e trace=network 只追踪网络相关调用（connect/sendto/recvfrom 等），-T 显示每个调用的耗时（在右括号后面）。
输出显示：
connect(8, {sa_family=AF_INET, sin_port=htons(53), sin_addr=inet_addr("10.0.1.5")}, 16) = 0 <5.012345>
sendto(8, "...", 42, 0, NULL, 0) = 42 <0.000014>
recvfrom(8, "...", 512, 0, NULL, NULL) = 128 <0.000241>那个 <5.012345> 就是耗时。真相是：DNS 解析超时了 5 秒！应用在做 DNS 查询（端口53），DNS 服务器 10.0.1.5 不可达，等了 5 秒才超时。
这玩意儿 APM 根本追不到——因为它在 libc 的 getaddrinfo() 层就卡住了，还没进入应用的 trace span。
这就是 strace 的不可替代性：它能看到应用框架/APM 盲区里的东西。
场景四：权限问题——EACCES 的 N 种死法
还有一个经典场景：服务在开发机上跑得好好的，一到容器里就挂。查 strace：
$ strace -f -e trace=file /usr/local/bin/myapp 2>&1 | grep EACCES
openat(AT_FDCWD, "/var/run/myapp.pid", O_WRONLY|O_CREAT, 0644) = -1 EACCES (Permission denied)
openat(AT_FDCWD, "/etc/ssl/private/app.key", O_RDONLY) = -1 EACCES (Permission denied)
两个权限问题：写 pid 文件的目录没有写权限，读 SSL 私钥的用户不对。应用日志就一行 FATAL: startup failed，全靠 strace 才找到具体原因。
用 -e trace=file 过滤文件相关调用，加上 grep EACCES，权限问题无所遁形。
常用的参数组合速查
strace 的参数很多，但生产环境我 90% 的时间只用这几套组合拳：
| 场景 | 命令 | 说明 |
|---|---|---|
| 快速看进程在干嘛 | strace -p PID |
最简用法，直接 attach |
| 追所有线程 | strace -p PID -f |
多线程程序必备 |
| 只看文件操作 | strace -e trace=file |
排查配置、权限、路径问题 |
| 只看网络调用 | strace -e trace=network |
排查 DNS、连接建立、超时 |
| 显示耗时 | strace -T |
每个调用的墙钟时间，定位慢调用 |
| 显示时间戳 | strace -t 或 -tt |
-tt 精确到微秒 |
| 输出到文件 | strace -o /tmp/strace.log |
输出量大时必须写文件，否则 stdout 会炸 |
| 统计模式 | strace -c -p PID |
不打印每次调用，结束时输出汇总统计 |
strace -c：先概览，再深入
很多时候你不需要一开始就看每一条系统调用。先跑一个汇总，看看时间花在哪里了：
$ strace -c -p 19283
# 运行 30 秒后 Ctrl+C
% time seconds usecs/call calls errors syscall
------ ----------- ----------- --------- --------- ----------------
99.42 3.245187 32451 100 futex
0.31 0.010045 3 2999 read
0.15 0.004899 2 2000 write
0.08 0.002734 2 1003 epoll_wait
0.02 0.000624 1 500 clock_gettime
------ ----------- ----------- --------- --------- ----------------
100.00 3.263489 6602 total99.42% 的时间花在 futex 上，每次平均 32 毫秒。这直接印证了锁竞争问题。用 -c 做 top-down 分析，找到热点后再用 -e trace=futex 深入追踪。
性能开销：strace 到底有多慢？
这是被问最多的问题，也是最容易被误解的部分。先说结论：
strace 本身几乎不拖慢系统调用，但它会让每次系统调用都触发上下文切换，产生额外的 ptrace 开销。对于高频系统调用的程序（比如每秒几十万次 read/write），性能影响可能高达 30%-80%。对于大部分后端服务（每秒几千次调用），影响在 5% 以内。
我用一个 Python 脚本做了实测——分别在不挂 strace、挂 strace 但不过滤、挂 strace 且过滤特定调用三种情况下跑了 10 万次文件读取：
# 基准（无 strace）
10万次文件读取耗时: 1.82s
# strace 全量追踪 (-f -o /dev/null)
10万次文件读取耗时: 18.43s (10x 慢)
# strace 过滤追踪 (-e trace=!read,write -o /dev/null)
10万次文件读取耗时: 2.01s (1.1x 慢)关键在 -e trace=! 这个语法。用 ！ 排除掉高频调用（read/write/futex），性能开销直接从 10 倍降到可忽略。
生产环境最佳实践：
- 先用
-c统计 30 秒了解调用分布 - 然后用
-e trace=具体调用精确追踪 - 一定要加
-o /tmp/file，不要输出到 stdout（否则 strace 自己的 write 也会被追踪，递归爆炸） - 追完立刻
Ctrl+C，别挂着就跑
strace vs 其他工具：什么时候别用 strace
strace 是瑞士军刀，但不是万能工具。有几个场景它不如专用工具：
| 场景 | 用 strace？ | 更好的工具 |
|---|---|---|
| CPU 热点分析 | ❌ 不行，只能看 syscall 级别 | perf — 看函数级热点 |
| 内核态追踪 | ⚠️ -k 可以但有限 |
bpftrace / eBPF — 无侵入内核追踪 |
| 动态库函数调用 | ❌ 不行，只能看 syscall | ltrace — 追踪 libc 等动态库调用 |
| 网络抓包 | ⚠️ 能看到 syscall 但不能看包内容 | tcpdump / ss |
| 程序crash定位 | ⚠️ 可用但不优雅 | gdb / coredump |
一句话总结选型：想知道”程序在跟操作系统交互什么”→ strace；想知道”程序哪段代码慢”→ perf；想知道”内核里发生了什么”→ bpftrace。
我之前写过 Linux 性能剖析实战：perf 工具从 CPU 采样到火焰图生成全流程 和 eBPF + bpftrace 生产环境调试实战，这三者搭配使用基本能覆盖所有生产环境排查场景。
FAQ
Q: strace 会让程序变慢，生产环境能用吗？
可以，但要讲究方法。核心原则：用 -e trace= 精确过滤，用 -o 输出到文件，追踪时间控制在 30 秒以内。高频 I/O 程序先评估影响，低频程序直接上问题不大。
Q: strace 输出里 EAGAIN 是什么意思？需要担心吗？
不一定是问题。EAGAIN（Resource temporarily unavailable）在非阻塞 I/O 中极其常见——它表示”现在没数据，你待会再来”。但如果某个调用连续大量返回 EAGAIN，可能是真的有问题（比如 socket buffer 满了）。
Q: Docker 容器里能用 strace 吗？
能，但默认需要 --cap-add=SYS_PTRACE 或 --privileged。Kubernetes 里需要在 Pod Security Policy 中允许 SYS_PTRACE capability。或者可以在宿主机上 strace 容器进程（strace -p $(docker inspect -f '{{.State.Pid}}' container_name)）。
Q: strace 和 gdb 有什么区别？什么时候用哪个？
strace 看”程序在跟 OS 交互什么”（系统调用级别），gdb 看”程序内部状态是什么”（变量值、调用栈、断点）。程序卡死不响应 → strace；程序 core dump → gdb；行为诡异但没报错 → 先 strace 再看要不要 gdb。
写在最后
strace 是我工具箱里出场率最高的排查工具之一。它不需要安装额外包（几乎所有发行版都有），不需要重启进程，不需要改代码——只要是 Linux 上跑的程序，它就能给你信息。
但 strace 真正的价值不在于那几个命令行参数，而在于你对操作系统的理解。你得知道 futex 是锁的底层实现，epoll_wait 是事件循环在等 I/O，connect 超时可能是 DNS 的问题——这些背景知识决定了你看到输出时能不能反应出来”这里有问题”。
所以，学 strace 最好的方式不是背参数，而是在排查实际问题时刻意用它。下次线上出问题时，别急着翻代码，先 strace -c -p PID 跑 30 秒看看——你可能会对自己写的程序有一个全新的认识。
相关阅读：