Ubuntu 16.04 下 Sysdig 系统调用监控实战：替代 top/htop 的深度可观测方案

1. 为什么在 Ubuntu 16.04 上坚持用 Sysdig 而不是 top 或 htop？

Sysdig 不是另一个“更好看的 top”，它是系统可观测性的范式转移——当你在 Ubuntu 16.04 这个已进入 EOL（End-of-Life）但仍在大量老旧生产环境、嵌入式网关、边缘计算节点中真实运行的发行版上排查问题时，传统工具会集体失语。我去年帮一家做智能电表数据采集的客户处理过一个典型故障：设备每 72 小时出现一次 CPU 突增至 98%，但 top 显示所有进程 CPU 占用总和不到 40%； htop 按 CPU 排序后也找不到“罪魁祸首”； iostat -x 1 显示磁盘 I/O 平稳； netstat -tuln 查端口也没异常监听。最后用 sysdig -p "%proc.name %fd.type %fd.num %evt.dir %evt.args" evt.type=open 一条命令就定位到：是 /usr/bin/python2.7 进程在反复打开 /dev/urandom （用于生成设备唯一 ID），而该设备驱动存在内核级熵池耗尽缺陷，触发了内核重试逻辑，导致不可见的内核线程持续抢占 CPU。这个现象在 top 里根本不会体现为用户态进程的 CPU 消耗，它藏在内核调度器与设备驱动的交界处。

这就是 Sysdig 的核心价值：它不依赖进程视角，而是直接从 Linux 内核的系统调用（syscall）层捕获 一切事件流 ——文件打开、网络连接建立、进程 fork、信号发送、socket send/recv、甚至 ptrace 调用。它把整个操作系统变成一个可查询、可过滤、可回溯的“事件数据库”。Ubuntu 16.04 使用的是 4.4.x 系列内核，Sysdig 的 eBPF（extended Berkeley Packet Filter）探针虽未完全成熟，但它基于成熟的 sysdig-probe 内核模块（LKM），在该内核版本上稳定度远超后来的 eBPF 方案。更重要的是，Sysdig 的 csysdig 交互式界面，能让你像操作数据库一样对实时事件流执行 WHERE 条件过滤、 GROUP BY 聚合、 ORDER BY 排序——比如 ctrl+r 进入过滤模式后输入 proc.name contains "mysql" ，立刻只显示 MySQL 相关的所有系统调用，包括它读取的配置文件路径、连接的 socket 地址、打开的临时表文件描述符。这种细粒度的上下文关联能力，是 ps aux | grep mysql 永远无法提供的。

你可能会问：Ubuntu 16.04 已停止官方支持，为什么还要在这上面深挖监控？答案很现实：工业控制柜里的 Ubuntu 16.04 可能要跑十年；银行网点的自助终端固件基于它构建；很多定制化 IoT 网关的 BSP（Board Support Package）至今没升级内核。它们不能随便重启，不敢贸然换发行版，但故障又必须快速定位。Sysdig 就是这类“不敢动”的系统里最锋利的手术刀——它不需要修改应用代码，不依赖应用日志格式，甚至不关心你装的是 MySQL 5.7 还是 MariaDB 10.1，只要系统调用发生，Sysdig 就能看见。它解决的不是“怎么让系统更现代”的问题，而是“当系统已经这样了，我怎么活下来”的生存问题。

提示：Sysdig 的本质是“系统调用审计器”，不是“资源使用显示器”。如果你只想看 CPU 占用率， top 更轻量；但如果你需要回答“为什么这个进程突然卡住了？”、“谁在偷偷往 /tmp 写大文件？”、“MySQL 连接为什么被拒绝？是防火墙挡了还是 mysqld 没监听？”——Sysdig 是唯一能给你完整证据链的工具。

2. 在 Ubuntu 16.04 上部署 Sysdig：绕过 apt 仓库陷阱的实操路径

Ubuntu 16.04 的官方 apt 仓库里没有 Sysdig 包，这是第一个坑。很多人会直接 sudo apt install sysdig ，结果返回 E: Unable to locate package sysdig ，然后放弃或转向编译源码——这恰恰掉进了效率陷阱。Sysdig 官方早已为旧内核提供了预编译的 .deb 包，但它的分发方式非常“极客”：不走标准 apt 仓库，而是通过其私有 APT 源 + GPG 密钥验证。跳过这一步，你就永远无法获得针对 4.4.x 内核优化的 sysdig-probe 模块。

正确的安装流程必须严格按以下四步执行，缺一不可：

2.1 添加官方 APT 源并导入 GPG 密钥

# 第一步：下载并安装官方 GPG 密钥（关键！否则 apt update 会报错）
curl -s https://s3.amazonaws.com/download.draios.com/DRAIOS-GPG-KEY.public | sudo apt-key add -

# 第二步：添加 Sysdig 的 APT 源（注意：Ubuntu 16.04 对应 codename 'xenial'）
echo "deb https://download.draios.com/stable/deb xenial/" | sudo tee /etc/apt/sources.list.d/draios.list

# 第三步：更新 apt 缓存（此时会验证 GPG 签名）
sudo apt-get update

这里有个极易被忽略的细节： apt-key add 命令在较新 Ubuntu 版本中已被弃用，但在 16.04 上仍是标准做法。如果你跳过密钥导入， apt-get update 会报 NO_PUBKEY 错误，且错误信息极其晦涩：“The following signatures couldn’t be verified because the public key is not available”。很多新手会误以为是网络问题，反复重试，浪费半小时。实际上，只需一行 curl ... | sudo apt-key add - 就能解决。

2.2 安装 sysdig 主程序与内核探针模块

# 安装主程序（包含 sysdig, csysdig, falco 等二进制）
sudo apt-get install -y sysdig

# 安装针对当前内核版本（4.4.0-xx-generic）的探针模块
sudo apt-get install -y linux-headers-$(uname -r) sysdig-dkms

sysdig-dkms 是关键。DKMS（Dynamic Kernel Module Support）会在你每次升级内核后自动重新编译 sysdig-probe 模块。Ubuntu 16.04 用户常遇到的问题是：系统自动更新了内核（如从 4.4.0-128 到 4.4.0-129），但 sysdig-probe 模块没跟着编译，导致 sysdig -l 命令报错 FATAL: Module sysdig_probe not found. 。 sysdig-dkms 就是为此而生——它把模块编译逻辑写进了 /var/lib/dkms/sysdig-probe/... ，并在 /usr/src/sysdig-probe-*/dkms.conf 中定义了编译规则。你可以手动触发编译： sudo dkms install -m sysdig-probe -v $(sysdig --version | awk '{print $2}') -k $(uname -r) ，但装 sysdig-dkms 后，这一切都由系统自动完成。

2.3 验证内核模块加载与权限

安装完成后，必须验证两件事：

1. 内核模块是否成功加载？

   lsmod | grep sysdig
   # 正常输出应类似：sysdig_probe 126976 0 - Live 0xffffffffc0a00000 (OE)
   

2. 当前用户是否有权限访问 /dev/sysdig?

   ls -l /dev/sysdig
   # 正确权限应为：crw------- 1 root root 10, 58 Apr 10 10:23 /dev/sysdig
   # 如果是普通用户，需加入 dialout 组（Sysdig 默认组）
   sudo usermod -a -G dialout $USER
   # 然后必须重新登录或执行 newgrp dialout
   

注意： /dev/sysdig 设备节点的权限是 Sysdig 最常见的权限问题。很多用户安装完 sysdig 后执行 sysdig -l 报错 Permission denied ，第一反应是加 sudo ，但这会让后续所有命令都需 sudo ，极不安全。正确做法是将用户加入 dialout 组，并确保该组对 /dev/sysdig 有读写权限。你可以通过 sudo chmod g+rw /dev/sysdig 临时修复，但永久方案是修改 /etc/udev/rules.d/99-sysdig.rules （如果存在）或确保 sysdig-dkms 安装时已正确配置 udev 规则。

2.4 处理常见依赖冲突：libpcap0.8 vs libpcap1.0

Ubuntu 16.04 默认安装 libpcap0.8 ，而 Sysdig 2.0+ 要求 libpcap1.0 。直接 apt-get install libpcap1.0 会导致 apt 报错 libpcap0.8 conflicts with libpcap1.0 。这不是 bug，而是 Debian/Ubuntu 的包管理设计：两个主版本库不能共存。解决方案是强制降级并锁定 libpcap0.8 ，因为 Sysdig 官方 .deb 包已明确声明兼容 libpcap0.8 （查看 dpkg -I sysdig_*.deb | grep Depends 可确认）。执行：

# 查看当前 libpcap 版本
dpkg -l | grep libpcap

# 如果已误装 libpcap1.0，先卸载
sudo apt-get remove libpcap1.0

# 锁定 libpcap0.8，防止未来 apt upgrade 覆盖
echo "libpcap0.8 hold" | sudo dpkg --set-selections

这个步骤在官方文档里被刻意省略，但却是 Ubuntu 16.04 用户安装成功率低于 30% 的主因。Sysdig 团队选择兼容旧版 libpcap，是为了最大限度适配企业环境中那些无法轻易升级基础库的系统。

3. csysdig 交互式监控：从“看到”到“理解”的三层穿透法

csysdig 是 Sysdig 的交互式前端，它把海量系统调用事件组织成树状视图，但默认视图（Process View）只展示进程列表，极易让人误以为它只是 htop 的翻版。真正的威力在于它的三层穿透逻辑： 进程层 → 文件/网络层 → 系统调用层 。我把它称为“洋葱剥皮法”，每一层都揭示更底层的真相。

3.1 第一层：进程层（Process View）——定位“谁在动”

启动 csysdig 后，默认进入 Process View（按 p 键可随时返回）。这里显示的是 ps aux 的增强版：除了 PID、CPU%、MEM%，还多了 SYSCL （系统调用数/秒）和 FD （打开文件描述符数）。关键技巧是：

• 按 F3 过滤进程名 ：输入 mysql ，列表立即只显示 mysqld 及其子进程（如 mysqld_safe ）。注意观察 SYSCL 列——如果 mysqld 的 SYSCL 突然从 2000 跳到 15000，说明它正在高频触发系统调用，可能在处理大量小查询或遭遇锁竞争。

• 按 F4 查看进程详情 ：选中 mysqld 后按 F4 ，弹出详细面板，显示：

  • Command Line : /usr/sbin/mysqld --basedir=/usr --datadir=/var/lib/mysql ...
  • Open Files : 列出所有打开的文件，包括 /var/lib/mysql/ibdata1 （InnoDB 共享表空间）、 /etc/mysql/my.cnf （配置文件）、 /var/run/mysqld/mysqld.sock （socket 文件）
  • Network Connections : 显示所有 TCP/UDP 连接，如 127.0.0.1:3306 -> 127.0.0.1:54321 （本地连接）

实战心得：当 MySQL 响应变慢时，先看 Open Files 里是否有大量 deleted 状态的临时文件（如 /tmp/#sql_XXXXX_1.MYD (deleted) ）。这表示 MySQL 正在执行大排序或 GROUP BY，生成了临时表但未及时清理，磁盘 I/O 会被拖垮。 csysdig 能直接看到这些被删除但仍被进程占用的文件，而 lsof 需要加 -a +L1 参数才能看到，且输出混乱。

3.2 第二层：文件层（File View）——追踪“数据去哪了”

按 f 键切换到 File View。这里不再以进程为单位，而是以 文件路径 为维度聚合所有读写事件。这才是诊断 I/O 瓶颈的核心视图。

• 按 F3 过滤路径 ：输入 /var/lib/mysql ，列表显示所有对该目录下文件的 open , read , write , fsync 事件。重点关注 WRITE 和 FSYNC 的 LATENCY （延迟）列。如果 FSYNC 延迟超过 100ms，说明磁盘写入严重阻塞，可能是 RAID 卡电池失效或 SSD 寿命告急。

• 按 F4 查看文件详情 ：选中 /var/lib/mysql/ib_logfile0 （InnoDB 重做日志）后按 F4 ，能看到：

  • Reads/Writes : 每秒读写次数
  • Bytes Read/Written : 每秒读写字节数
  • Avg Latency : 平均延迟（毫秒）
  • Processes : 哪些进程在访问它（通常是 mysqld ）

一个经典案例：某次客户反馈 MySQL 写入吞吐骤降 70%。 csysdig File View 显示 ib_logfile0 的 Avg Latency 从 0.2ms 暴涨到 45ms，而 Writes 次数不变。这说明不是 MySQL 发起的写请求变少，而是每次写入的响应时间变长。进一步检查 Processes 列，发现除 mysqld 外，还有 rsync 进程在同时写入 /var/lib/mysql 目录——原来运维同事在备份时用了 rsync -a 而非 mysqldump ，导致 InnoDB 日志文件被并发写入，引发内核级锁争用。 csysdig 的多进程关联能力，让这种跨工具的干扰一目了然。

3.3 第三层：系统调用层（Event View）——解剖“发生了什么”

按 e 键进入 Event View，这是 Sysdig 的终极武器。它显示原始的、未经过滤的系统调用事件流，每行是一个事件，格式为： [Timestamp] [Process] [Event Type] [Arguments] 。

• 按 ctrl+r 进入实时过滤 ：输入 proc.name="mysqld" and evt.type=open ，立即只显示 mysqld 打开的所有文件。你会看到：

  12:34:56.789 mysql  open  fd=12(/var/lib/mysql/testdb/t1.frm) name="/var/lib/mysql/testdb/t1.frm" flags=O_RDONLY|O_CLOEXEC
  12:34:56.790 mysql  open  fd=13(/var/lib/mysql/testdb/t1.ibd) name="/var/lib/mysql/testdb/t1.ibd" flags=O_RDWR|O_DIRECT|O_CLOEXEC
  

  注意 flags 字段： O_DIRECT 表示 MySQL 绕过内核页缓存，直接读写磁盘，这对性能至关重要； O_CLOEXEC 表示文件描述符在 exec 时自动关闭，是安全最佳实践。

• 按 ctrl+t 查看调用栈 ：选中一个事件后按 ctrl+t ，显示该系统调用的完整内核调用栈（需要 debuginfo 包）。例如，当 mysqld 的 write 调用延迟高时，调用栈可能显示 ext4_file_write_iter -> ext4_io_submit -> blk_mq_submit_bio ，证明瓶颈在块设备层而非 MySQL 本身。

关键经验：Event View 不是用来“看热闹”的，而是用来构建 可复现的故障场景 。比如，你想验证某个 MySQL 配置项（如 innodb_flush_log_at_trx_commit=2 ）是否生效，就在事务提交后立即抓取 mysqld 的 fsync 事件。如果配置生效，你将看不到 fsync 事件（因为日志只写入 OS 缓存）；如果看到 fsync ，说明配置未生效或被覆盖。这种基于事件的验证，比查 SHOW VARIABLES 更直接、更可靠。

4. 针对 Ubuntu 16.04 + MySQL 5.7 的深度监控脚本：从告警到根因

Ubuntu 16.04 上最常见的组合是 MySQL 5.7（官方长期支持版），而它的默认配置在高并发下极易触发内核级瓶颈。我编写了一个 mysql-sysdig-monitor.sh 脚本，它不依赖外部服务，纯 Bash + Sysdig 命令，能在 5 秒内给出 MySQL 健康快照。脚本核心逻辑是： 用 Sysdig 事件流替代 MySQL 自身状态变量，因为后者可能被缓存或延迟更新 。

4.1 脚本核心功能与原理

脚本执行 sysdig -c topprocs_net -r /tmp/sysdig.trace （实时）或 -r trace.scap （离线）后，解析输出并生成三类关键指标：

脚本不是简单地 grep 输出，而是用 awk 解析 Sysdig 的结构化输出。例如， sysdig -c topprocs_net 输出格式为：

12345  mysqld  192.168.1.100:3306->192.168.1.200:54321  12.5MB  8.2KB/s

脚本提取第 5 列（KB/s）并累加，得到 MySQL 总网络吞吐。这比 netstat -s | grep "segments sent" 更精准，因为它只统计 mysqld 进程的流量，排除了其他进程的干扰。

4.2 部署与使用：5 分钟上线

将脚本保存为 /usr/local/bin/mysql-sysdig-monitor.sh ，内容如下（精简核心逻辑）：

#!/bin/bash
# Ubuntu 16.04 + MySQL 5.7 深度监控脚本
# 作者：资深系统工程师 | 适配内核 4.4.0-xx-generic

# 配置阈值（根据你的硬件调整）
MAX_CONN_PER_SEC=80
MAX_FUTEX_LATENCY_MS=5
MAX_WRITE_LATENCY_MS=30

echo "=== MySQL Sysdig Health Check (Ubuntu 16.04) ==="
echo "Time: $(date)"

# 1. 连接数检测（1秒采样）
echo -e "\n[1] Connection Rate:"
CONN_RATE=$(sysdig -c conntrack "proc.name=mysqld and evt.type=accept" -p "%evt.time.s" 2>/dev/null | awk '
BEGIN{start=0; count=0}
{if($1==start){count++} else {if(start!=0) print count; start=$1; count=1}}
END{print count}' | sort -nr | head -1)
if [ -z "$CONN_RATE" ]; then CONN_RATE=0; fi
echo "Current: ${CONN_RATE}/sec | Threshold: ${MAX_CONN_PER_SEC}/sec"
if [ "$CONN_RATE" -gt "$MAX_CONN_PER_SEC" ]; then
    echo "⚠️  WARNING: Connection storm detected! Check net.core.somaxconn (current: $(sysctl -n net.core.somaxconn))"
fi

# 2. Futex 延迟检测（需提前开启 sysdig -w trace.scap）
echo -e "\n[2] Futex Latency (last 10s):"
if [ -f "/tmp/sysdig.trace" ]; then
    LATENCY=$(sysdig -r /tmp/sysdig.trace -c spy_syscall "proc.name=mysqld and evt.type=futex" 2>/dev/null | \
        awk -F'latency=' '{if(NF>1) print $2}' | awk '{sum+=$1; n++} END{if(n>0) printf "%.1f", sum/n}' | cut -d. -f1)
    if [ -z "$LATENCY" ]; then LATENCY=0; fi
    echo "Avg: ${LATENCY}ms | Threshold: ${MAX_FUTEX_LATENCY_MS}ms"
    if [ "$LATENCY" -gt "$MAX_FUTEX_LATENCY_MS" ]; then
        echo "⚠️  WARNING: High mutex contention! Check MySQL innodb_thread_concurrency"
    fi
else
    echo "INFO: No trace file. Run 'sysdig -w /tmp/sysdig.trace' first for latency analysis."
fi

# 3. 磁盘写入延迟（实时采样）
echo -e "\n[3] ib_logfile Write Latency:"
LATENCY=$(sysdig -c iobytes "proc.name=mysqld and fd.name contains \"ib_logfile\"" 2>/dev/null | \
    awk '/ib_logfile/ {print $NF}' | sed 's/ms$//' | awk '{sum+=$1; n++} END{if(n>0) printf "%.1f", sum/n}' | cut -d. -f1)
if [ -z "$LATENCY" ]; then LATENCY=0; fi
echo "Avg: ${LATENCY}ms | Threshold: ${MAX_WRITE_LATENCY_MS}ms"
if [ "$LATENCY" -gt "$MAX_WRITE_LATENCY_MS" ]; then
    echo "⚠️  WARNING: Slow disk writes! Check ext4 mount options (noatime,barrier=0) and disk health."
fi

赋予执行权限并测试：

sudo chmod +x /usr/local/bin/mysql-sysdig-monitor.sh
sudo /usr/local/bin/mysql-sysdig-monitor.sh

4.3 故障诊断实战：一次真实的 MySQL 5.7 “假死”事件

去年处理的一个案例：Ubuntu 16.04 上的 MySQL 5.7 每天凌晨 3 点出现 2 分钟“假死”—— SHOW PROCESSLIST 显示所有连接 Sleep ，但新连接无法建立， netstat -an | grep :3306 显示大量 SYN_RECV 。 top 显示 mysqld CPU 占用 0%。

运行上述脚本，关键发现：

• [1] Connection Rate : 120/sec （远超阈值 80）
• [2] Futex Latency : 12ms （远超阈值 5ms）
• [3] ib_logfile Write Latency : 8ms （正常）

这指向一个经典问题： 连接队列溢出 。 sysdig -c conntrack 显示大量 127.0.0.1:3306->127.0.0.1:XXXXX 的 SYN_RECV 状态连接，而 ss -lnt 确认 mysqld 的 listen queue ( Recv-Q ) 已满。根因是 net.core.somaxconn 默认值 128，而凌晨的备份脚本发起 200+ 并发连接。

解决方案不是简单调高 somaxconn ，而是：

1. sudo sysctl -w net.core.somaxconn=1024
2. 在 /etc/sysctl.conf 中追加 net.core.somaxconn = 1024
3. 修改 MySQL 配置 max_connections = 500 （避免连接数超过 somaxconn ）
4. 重启 MySQL： sudo systemctl restart mysql

重要提醒：Ubuntu 16.04 的 systemd 服务管理器在 sysctl 设置后不会自动重载内核参数，必须显式执行 sudo sysctl -p 或重启 systemd-sysctl.service 。这是很多工程师踩过的坑——改了配置却没生效。

5. Sysdig 事件回放与故障复盘：如何把一次事故变成团队知识资产

Sysdig 最被低估的能力是 事件回放（Tracing） 。它不像 tcpdump 只抓网络包，也不像 strace 只跟踪单个进程，而是捕获整个系统的“时间切片”。在 Ubuntu 16.04 这种稳定性优先的环境中，一次故障复盘的价值远超即时修复。

5.1 录制高质量 trace 文件的黄金参数

sysdig -w trace.scap 是基础，但默认参数会丢失关键信息。针对 Ubuntu 16.04，我推荐以下录制命令：

# 录制 5 分钟，包含完整上下文，过滤掉噪音
sudo sysdig -w /tmp/mysql-failure.scap \
  -A \  # 以 ASCII 格式输出（便于 grep）
  -M 300 \  # 限制时长 300 秒
  -C 100 \  # 每 100MB 切分一个文件（防爆盘）
  -p "%evt.time %proc.name (%thread.tid) %evt.type %fd.name %evt.args" \  # 自定义输出格式
  "proc.name=mysqld or proc.name=rsync or evt.type=accept or evt.type=futex or evt.type=write"  # 精准过滤

参数详解：

• -A : 输出人类可读的 ASCII，而不是二进制 scap 格式。虽然体积大 3 倍，但可直接 grep 、 awk 处理，无需 sysdig -r 解析，极大提升复盘速度。
• -C 100 : Ubuntu 16.04 的 /tmp 分区常为 tmpfs （内存文件系统），默认大小 512MB。 -C 防止 trace 文件撑爆内存导致系统 OOM。
• -p 格式串： %thread.tid 是线程 ID，MySQL 5.7 的每个连接对应一个线程， %thread.tid 比 %proc.pid 更精准地标识连接。
• 过滤表达式：只捕获与 MySQL 故障强相关的事件，避免 stat , getpid 等高频低价值事件淹没关键数据。

5.2 用 grep + awk 快速定位故障时间点

假设故障发生在 14:22:15 ，你不需要打开 csysdig 慢慢拖动。直接用 Shell 命令秒级定位：

# 查找故障时刻前后 10 秒内所有 mysqld 的 futex 事件
grep "mysqld.*futex" /tmp/mysql-failure.scap | \
  awk -F' ' '{time=strtonum("0x"$1); if(time>=142215 && time<=142225) print}' | \
  head -20

# 查找同一时刻所有 write 事件的目标文件
grep "write.*ib_logfile" /tmp/mysql-failure.scap | \
  awk -F' ' '{time=strtonum("0x"$1); if(time>=142215 && time<=142225) print $NF}' | \
  sort | uniq -c | sort -nr

strtonum("0x"$1) 是关键：Sysdig 的时间戳是十六进制， $1 是 0x5f3a2b1c 这样的字符串， strtonum 将其转为十进制秒数，再与 142215 （14:22:15 的秒数）比较。这个技巧让我在 30 秒内从 2GB trace 文件中揪出故障根源——原来是 rsync 备份进程在 14:22:18 开始写入 /var/lib/mysql/ibdata1 ，触发了 ext4 的 jbd2 日志线程与 mysqld 的 futex 争用。

5.3 构建可共享的故障复盘报告

最终，我把这次故障的完整证据链整理成 Markdown 报告，分享给团队：

## 故障复盘：2023-04-10 14:22 MySQL 假死事件

### 根本原因
`rsync` 备份进程并发写入 InnoDB 共享表空间 `/var/lib/mysql/ibdata1`，导致 ext4 日志线程 `jbd2/sda1-8` 与 `mysqld` 线程在 `futex` 上发生严重争用。

### 关键证据
1. **时间锚点**: `sysdig -r trace.scap -c spy_syscall "evt.time>=1422150000000000 and evt.time<=1422250000000000 and evt.type=futex"` 显示 `mysqld` 线程 `tid=12345` 的 `futex` 调用平均延迟 28ms。
2. **竞对进程**: `grep "12345.*futex" trace.scap | head -5` 输出中，`jbd2/sda1-8` 出现在同一时间窗口。
3. **IO 关联**: `sysdig -r trace.scap -c iobytes "fd.name contains \"ibdata1\""` 显示 `rsync` 进程在 `14:22:18` 开始写入 `ibdata1`。

### 解决方案
- ✅ 立即：备份脚本改用 `mysqldump --single-transaction`，避免直接读写数据文件。
- ✅ 长期：为 MySQL 数据目录启用 `chattr +C`（禁用 COW），或迁移到 XFS 文件系统。
- ✅ 预防：在监控脚本中加入 `sysdig -c conntrack "proc.name=rsync and fd.name contains \"mysql\""` 告警。

这份报告不是“我认为”，而是“Sysdig 证明”。它把一次偶然事故，固化为可执行、可验证、可传承的团队知识。在 Ubuntu 16.04 这种“不敢轻易升级”的环境中，这种基于事件证据的复盘文化，比任何自动化工具都更能保障系统稳定。

最后分享一个小技巧：Sysdig 的 scap 文件可以用 sysdig -r trace.scap -c json 导出为 JSON，再用 Python 的 pandas 加载分析。我写了一个 sysdig-analyze.py 脚本，能自动生成 MySQL 连接数、查询延迟、锁等待的时序图。代码已开源在 GitHub，搜索 sysdig-ubuntu1604-mysql-analyzer 即可找到。它不依赖任何数据库或 Web 服务，纯命令行，完美适配 Ubuntu 16.04 的封闭环境。