查看异常分布

首先根据经验，我们看看自己的服务器的情况，看下异常到底出现在哪些机器，通过监控切换到单机维度，看看异常是否均匀分布，如果分布不均匀，只是少量的host特别高，基本可以定位到出现问题的机器。

Redis情况

再次按照经验，我们看看redis集群是否有节点负载过高，比如以常规经验看来的80%可以作为一个临界值。
如果有一个或少量节点超过，则说明可能存在热key问题，如果大部分节点都超过，则说明存在redis整体压力大问题。
另外可以看看是否有慢请求的情况，如果有慢请求，并且时间发生问题的时间匹配，那么可能是存在大key的问题。

CPU

我们假设自己还是很无助，还是没发现问题在哪儿，别急，接着找找别人的原因，看看CPU咋样，可能运维偷偷滴给我们把机器配置给整差了。
我们看看CPU使用率多高，是不是超过80%了，还是根据经验，我们之前的服务一般高峰能达到60%就不错了。
再看看CPU是不是存在限流，或者存在密集的限流、长时间的限流。
如果存在这些现象，应该就是运维的锅，给我们机器资源不够啊。

GC停顿

再看看GC咋样。频繁的GC、GC耗时过长都会让线程无法及时读取redis响应。
这个数字怎么判断呢？
通常，我们可以这样计算，再次按照我们一塌糊涂的经验，每分钟GC总时长/60s/每分钟GC个数，如果达到ms级了，对redis读写延迟的影响就会很明显。
为了稳一手，我们也要对比下和历史监控级别是否差不多一致。
好了，打扰了，我们继续。

网络

网络这块我们主要看TCP重传率，这个基本在大点的公司都有这块监控
TCP重传率=单位时间内TCP重传包数量/TCP发包总数

我们可以把TCP重传率视为网络质量和服务器稳定性的一个只要衡量指标。
还是根据我们的经验，这个TCP重传率越低越好，越低代表我们的网络越好，如果TCP重传率保持在0.02%（以自己的实际情况为准）以上，或者突增，就可以怀疑是不是网络问题了。