现象
- 有几个cpu.core idle 两分钟从100直接降到0
- 机器ssh登陆hung死，无法进入机器查看
- cpu.load 很高，几乎到200多，cpu才20core，远远超过CPU core num.
故障时现象监控图：
- 几个core的idle直接降为0
通过查看iowait，时间点能对应，也就是因为iowait被占用100%
查看下机器全局load：
经验分析
出现CPU占用问题，第一步通常是上机器top或ps查看是什么进程导致的！
ssh hung死！登录的机会都不给…
根据经验，这种情况很可能是有进程卡在D状态，关于D状态大家可以google下，处在D状态的进程会被计算到load中，所以load持续增高，基本能对上。
还有一种现象就是ssh端口能通，ping也可以通，但是登陆不上，会一直hung住…（之前做SRE值班的时候业务程序hung住机器也是这个状态）
根据经验能判断，大概率是以下几个原因：
- 程序bug导致D状态，需要登陆机器查看确认（近期无变更，程序较少）
- 磁盘瓶颈，ioutil和read/write均不大，也不太可能
- 磁盘硬件问题
根据猜想验证，查看io.write，基本能够确定是磁盘问题了。因为从早上06:00开始写入从300k直接降为0了…
上图基本能反证是磁盘的问题，晚上23:00开始iowait升高，问题发生时间点其实是在06:00左右。
疑问来了，如果是磁盘问题，应该从早上6点就有问题了，而关于iowait和cpuidle为什么到晚上才告警？？
解释下iowait怎么计算的就好理解了，这个也是大部分人容易误解的地方之一：
- iowait，是指在CPU空闲的时候，CPU消耗在等待io的时间占比，也就是说，CPU必须是空闲下来时才算在iowait中，所以这个core的iowait升高的时间点和磁盘故障时间点对不上～
结论
登不上机器，只能找主机组同事来看了。连夜叫起值班同学，结论是磁盘在白天就发现坏掉了～
其实问题是在早上6点时就开始了，通过load监控图也能看出来，看来基础监控需要梳理一波。
临时做的记录，算是小case吧～
完。
赏
支付宝打赏
微信打赏
支付宝打赏
微信打赏
赞赏支持一下
