一、概述
之前在社区发了一篇故障分析 | 有效解决 MySQL 行锁等待超时问题文档，主要介绍了下行锁超时的监控方法，下方评论中有人提到了 pt-stalk 工具也可以监控行锁超时，因为个人没怎么用过这个工具，所以下意识的就去 google 了一下。因为没找到有介绍具体监控输出的文档，就以为这个工具没法监控行锁等待，最后果断被打脸了。
以上是个小插曲，个人在本地测试了下 pt-stalk 的监控输出后，发现其监控项远远比我预测的多，用起来也比较方便，所以在这里分享下这个工具。
二、介绍
首先介绍下 pt-stalk，它是 Percona-Toolkit 工具包中的一个工具，说起 PT 工具包大家都不陌生，平时常用的 pt-query-digest、pt-online-schema-change 等工具都是出自于这个工具包，这里就不多介绍了。
pt-stalk 的主要功能是在出现问题时收集 OS 及 MySQL 的诊断信息，这其中包括：
OS 层面的 CPU、IO、内存、磁盘、网络等信息；
MySQL 层面的行锁等待、会话连接、主从复制，状态参数等信息。
而且 pt-stalk 是一个 Shell 脚本，对于我这种看不懂 perl 的人来说比较友好，脚本里面的监控逻辑与监控命令也可以拿来参考，用于构建自己的监控体系。
三、使用
接着我们来看下如何使用这个工具。
pt-stalk 通常以后台服务形式监控 MySQL 并等待触发条件，当触发条件时收集相关诊断数据。
触发条件相关的参数有以下几个：
function：
默认为 status，代表监控 SHOW GLOBAL STATUS 的输出；
也可以设置为 processlist，代表监控 show processlist 的输出；
variable：
默认为 Threads_running，代表 监控参数，根据上述监控输出指定具体的监控项；
threshold：
默认为 25，代表 监控阈值，监控参数超过阈值，则满足触发条件；
监控参数的值非数字时，需要配合 match 参数一起使用，如 processlist 的 state 列；
cycles：
默认为 5，表示连续观察到五次满足触发条件时，才触发收集；
连接参数：host、password、port、socket。
其他一些重要参数：
iterations：该参数指定 pt-stalk 在触发收集几次后退出，默认会一直运行。
run-time：触发收集后，该参数指定收集多长时间的数据，默认 30 秒。
sleep：该参数指定在触发收集后，sleep 多久后继续监控，默认 300 秒。
interval：指定状态参数的检查频率，判断是否需要触发收集，默认 1 秒。
dest：监控数据存放路径，默认为 /var/lib/pt-stalk。
retention-time ：监控数据保留时长，默认 30 天。
daemonize：以后台服务运行，默认不开启。
log：后台运行日志，默认为 /var/log/pt-stalk.log。
collect：触发发生时收集诊断数据，默认开启。
collect-gdb：收集 GDB 堆栈跟踪，需要 gdb 工具。
collect-strace：收集跟踪数据，需要 strace 工具。
collect-tcpdump：收集 tcpdump 数据，需要 tcpdump 工具。
下面是一段 Percona 官方贴的伪代码，逻辑也比较清晰，大家可以看下：
while true; do
if --variable from --function > --threshold; then
cycles_true++
if cycles_true >= --cycles; then
--notify-by-email
if --collect; then
if --disk-bytes-free and --disk-pct-free ok; then
(--collect for --run-time seconds) &
fi
rm files in --dest older than --retention-time
fi
iter++
cycles_true=0
fi
if iter < --iterations; then
sleep --sleep seconds
else
break
fi
else
if iter < --iterations; then
sleep --interval seconds
else
break
fi
fi
done
rm old --dest files older than --retention-time
if --collect process are still running; then
wait up to --run-time * 3 seconds
kill any remaining --collect processes
fi
四、使用场景
下面是几个我个人可以想到的关于 pt-stalk 的使用场景：
4.1 场景一
后台运行 pt-stalk 监视 SHOW GLOBAL STATUS 中的 Threads_connected 状态值，即如果 客户端连接数 连续 5 次超过 1000，则触发收集主机和 MySQL 的性能与状态信息。
pt-stalk --function status --variable Threads_connected --threshold 2500 --daemonize --user=root --password=######
4.2 场景二
后台运行 pt-stalk 监视 SHOW GLOBAL STATUS 中的 Threads_running 状态值，即如果活跃线程数连续 5 次超过 500，则触发收集主机和 MySQL 的性能与状态信息。
pt-stalk --function status --variable Threads_running --threshold 500 --daemonize --user=root --password=######
4.3 场景三
非后台模式下立即收集主机和 MySQL 的性能与状态信息 60s，等待 180s 自动退出，无需任何触发条件，主要用于临时保留问题场景信息，便于事后分析。
pt-stalk --no-stalk --run-time=60 --iterations=1 --user=root --password=Gepoint
五、监控输出
接着来看下 pt-stalk 可以监控些什么信息，如下图所示：
从上图可见输出文件有很多，基本从文件名字就可以知道内容是什么，且大多数文件都是以命令来命名的，这里就不一一介绍了。
有些比较重要的监控项我用红标指示了，对于排查问题帮助比较多。
对于本文最开始所说的 pt-stalk 也可以监控行锁等待信息，其实就是依赖于 lock-waits 与 transactions 2 个监控文件。
我们来看下其内容：
首先是 lock-waits 日志，其实与我之前的后台监控脚本输出有点类似，不过这里信息更加丰富。
然后是 transactions ，记录了所有活动事务的详细信息，更加利于分析行锁等待情况。
虽然 lock-waits 与 transactions 2 个监控文件详细的记录了阻塞情况，但还是存在那个问题，如果原因是 事务挂起，还是需用借用 general_log 分析整个事务。
六、pt-sift
在学习 pt-stalk 的时候，发现 PT 工具包里专门有个工具用于分析 pt-stalk 采集的数据，那就是 pt-sift。
pt-sift 可以根据之前 pt-stalk 监控采集的数据进行汇总性的展示，使用比较简单，下面是其输出示例：
七、小结
pt-stalk 工具个人感觉还不错，尤其是其丰富的监控项，与其特有的触发式监控机制。
对于没有部署监控系统，但为了临时排查解决 MySQL 问题的环境非常有效。
最后对于 pt-stalk 再总结两点：
pt-stalk 适合在 MySQL 本地环境运行，远程运行则无法收集到对应的主机信息。
触发条件貌似是单一的，无法选择多个，也算是一个明显的弊端。
附录：
316
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
