1、背景
日常工作中遇到被问的最多的就是“现在应用有点慢，帮忙看看db是不是有问题”，第一反应是要去看一下监控告警。
问题是线上的监控指标很多，OS的包括cpu、内存、IO、网络，DB主要有TPS/QPS、活跃连接数、锁等待(细分的更多)，就算把所有监控信息都放到grafana单个页面展示，挨个查看也要耗费一点时间。
更关键的是，即便上述指标都正常，也不等同于DB无恙，即这些指标只能算是DB健康的必要条件，而不是充分条件。在某些场景下，即便这些指标都很平稳，开发可能依然会不断的质疑你，这时要如何快速自证清白？
首先来梳理一下DB响应流程：
从应用程序的角度观察，DB响应速度 = 网络延时 + 处理延时，其中处理延时的时间从请求抵达DB服务器开始，到服务器将响应结果发出结束。
DB服务器任何一个环节出现问题，都会增大处理延时，进而触发上述场景。
为此，我们只需要监控每个db请求【进入db服务器，db响应结束】这段时间的耗时，便可计算出每个db请求的处理延时，进而判定db服务器是否健康。 tcprstat是专门为统计处理延时而生的工具。
2、原理
官档原文：原文。
Here “response time” means, for a given TCP connection, the time elapsed from the last inbound packet until the first outbound packet.
通过(src_ip, src_port, dst_ip, dst_port)四元组可以唯一标识1个tcp连接，对于每个连接，计算其最后1个入包和第1个出包的时间差，以此得出1个请求的处理延时，然后将所有连接的请求处理延时聚集统计并输出。
这里有个前提，服务端IO模型必须是同步阻塞模式，即当前request的响应完成后，才能接受下一个request，好在目前的主流DB都符合这个要求。
tcprstat在启动时会创建一个hash表，默认2053个bucket，每个bucket挂载一条单向链表，当出现hash冲突时，遍历该bucket下的链表直至找到匹配的item。
借助libpcap捕获数据包，首先将其还原成ip包(struct ip)，根据(ip->ip_p == IPPROTO_TCP)过滤掉非tcp包， 并且去除只包含控制信息的tcp包。tcprstat会记录每个符合条件数据包的时间戳tv，以及对应的四元组(src_ip, src_port, dst_ip, dst_port)，对四元组取模，以此在hash表中定位查找。
对应的数据结构很简单:
- 如果该包是入包，将其插入到hash表，若对应的item已经存在，覆盖其已有tv值。
- 如果该包是出包，根据其四元组从hash表取出对应item并将其从hash表移除，将两个包的tv相减便得出该请求的处理延时。
tcprstat将每个请求的处理延时保存到1个长整型数组中，每次输出都要对这个指针数组进行遍历，比如计算avg。
struct session {
uint32_t laddr, raddr;uint16_t lport, rport;
struct timeval tv;
struct session *next;
}
而计算99_avg时，则先对指针数组调用qsort()进行升序排列，并只计算前99%的元素，排除最高的1%
计算min和max同理。
3、安装
安装很简单，直接将二进制文件下载就会执行
该工具默认直接查询机器的网络接口，在bonding模式的网卡下会报错，可改用ip列表。
以图形化的方式展现，当应用出现性能问题时可快速排查是否由DB引发，只有avg/99_avg出现剧烈波动时，才能证明db服务器响应有问题。
4、总结
可以做如下结论：tcprstat.avg/99_avg平稳是db健康的充分必要条件。虽然作者原本是为了监控mysql开发的此工具，但是对于mongo、redis同样适用，只需要修改监控端口即可。
全文完。
Enjoy MySQL :)
</div>
