Redis 延迟监控框架
Redis 2.8.13 引入了Latency Monitoring的一个新功能，可以帮助我们检查和排查引起延迟的原因。
Latecny Monitoring 由如下组成：
Latency hooks: 采样不同敏感度延迟的代码路径(也称作事件)；
时间序列：记录不同事件的延迟峰值(也叫延迟尖峰)；
报表引擎：从时间序列获取原始数据；
分析引擎：根据测量提供可读的报告和提示。
事件和时间序列
把监控代码路径称之为事件。例如：command 是一个测量可能较慢命令执行的延迟峰值的事件，fast-command 则是监控时间复杂度为O(1)和O(logN)的命令的事件。事件不是通用的，用来监控Redis执行的特殊操作。例如，fork事件只监控系统调用fork(2) 所消耗的时间。（写RDB文件和rewrite AOF文件都需要fork出一个后台进程，fork操作的主要消耗在于页表的拷贝，不同系统的耗时会有些差异。其中，Xen问题比较严重。）
延迟峰值(尖峰) 是指运行时间超过latency-monitor-threshold 配置的阈值的事件。每个监控事件会关联一个独立的时间序列，时间序列工作的原理：
- 每次出现峰值(尖峰)时，都会记录在合适的时间序列；
- 每个时间序列由160个元素组成；
- 每个元素都是一个值对：包含检测到延迟峰值(尖峰)出现时的unix 时间戳和事件执行的毫秒数；
- 相同事件在同一时间出现将并合并(取最大值)，因此，即使给定事件被检测到连续峰值(尖峰)，如果用户设置了比较低的阈值，将至少保留180s的历史记录；
- 对于每个元素，记录最大的延迟时间。
查看Redis 源码，可以归类监控事件的分类：
事件 | 事件内容 | 命令 | 详解 |
command | 慢命令 | latency history command | 执行时长超过 latency-monitor-threshold阈值的慢命令 |
fast-command | 时间复杂度为O(1)和O(logN)的命令 | latency history fast-command | 时间复杂度为O(1)和O(logN)的命令 |
fork | 系统调用fork(2) | latency history fork | AOF 或RDB 子进程 |
梅花香自古寒来
