首先确定慢请求是哪些osd
由于mon01的monitor服务关闭，所以慢请求日志记录只有保存在mon02和mon03的ceph.log日志里，日志位于/var/log/ceph目录下。在日志里搜索slow request即可找到当日慢请求的osd，如下图：
一般来说最开始出现慢请求和最后结束的慢请求osd才是主因，因为其他osd都是因为请求卡在这些主osd上才相继出现慢请求的。如图中的109，贯穿整个慢请求的过程。
通过osd查询当时对应的慢请求时长、以及rbd_data
在对应osd节点执行以下命令（将osd.x里面的x替换为osd的ID，例如osd.109）：
ceph daemon osd.x dump_historic_slow_ops > osd109.txt
打开osd109.txt，搜rbd_data关键字并复制后面的uuid，如下图：
通过rbd_data的uuid 查询对应是哪一块盘
通过以下命令查找UUID对应的盘符（-p后面的参数为存储池，厦门这边虚机有2个池，一个是volumes池，一个是vms池）：
rados listomapvals rbd_directory -p volumes | grep -a5 c694e6b8b4567
通过对应盘符查找虚机
假设找到的磁盘在volumes池中
在控制节点01执行命令查到对应虚机：
Source /root/keystonerc_admin
Cinder show uuid
Nova list --all |grep uuid
假设找到的磁盘在vms池中
直接在控制节点01执行NOVA命令查到对应虚机：
Source /root/keystonerc_admin
Nova list --all |grep uuid