之前写过一篇通过shell来监控磁盘坏块的文章 http://blog.itpub.net/23718752/viewspace-1872978/
从使用情况来看，也确实发现了一些坏块很多的问题，这也给我们的工作带来一些清晰的指导。不过感觉对于硬件的监控还在隔靴搔痒，还有很多的监控不够到位。或者太细感觉有些鸡肋，或者太粗有感觉有些笼统。而且还有些问题还是说不清道不明。
比如前段时间碰到一个问题，白天刚做过磁盘巡检，没有发现任何坏块，结果到晚上服务器就崩了。也没有任何的前兆，收到一条ICMP的报警之后，服务器就彻底失去连接了。对于这种问题，我们可以肯定的是磁盘没有坏块，所以数据肯定是没有丢，不过后续又做了确认，这个库已经没有业务在上面了，所以也算是侥幸逃过了一个忙碌而又纠结的恢复过程。之后我也在感慨，如果没有备库就是在耍流氓，而且感觉心里真是不踏实，如果你知道了哪些问题，可能老得担心，直到解决了才会心里踏实一些。
而且我们也一起讨论，发现一个比较奇怪的现象就是，很多服务器奔溃的情况都出现在半夜的时候，刚好是我们睡得真香的时候，它这么一折腾，我们一天都会没精打采。恢复的好，恢复的快，还能再多睡一会，系统忙，系统非常重要，估计连带的就是一大拨人了。如果细想，这个还是有一定的原因，可能还是在半夜的时候会有大量的备份和报表查询，批处理之类的任务可能对系统资源也会使用率比较高，也会直接间接导致一些潜在的问题。
可能还有一些原因就是我们没有发现针对性的硬件问题前兆，可能有些问题已经发生了很久，硬件监控的时候不一定能够及时捕捉到，有些可能是硬件的某一部分出现了一些警告，可能也很容易被忽略。
为此，我觉得得负责看看环境，不能让这种事情概率性的发生，至少应该能够提前预防好，过年的时候也能心安理得一些。
因为手头有一大拨机器的资源，于是就通过ILO的方式来查看历史的硬件情况。我就硬着头皮整理了一下，虽然枯燥，但是整理完再来看看，发现还是有些感悟。
比如像下面的这个问题，
这台服务器是一台MySQL的备库服务器，也是最近才移交到我手上，查看历史发现竟然已经开始有了主板的警告了，那么这台备库的服务器看来还是很有可能出现问题。那么如果在备库上每天进行大批量的备份和查询请求，那么这台服务器还是比较脆弱的。
再来看一台，可以发现这台似乎最近都是正常的，很久以前看报错细细，应该是电源坏了，然后近期raid卡电池看起来有一些警告信息，至于以前的信息是无法去求证了。但是所幸的是有电源恢复的记录。
当然我发现了这么一个警告。从告警来看，应该是硬盘直接坏掉了，但是从我之前的磁盘坏块监控来看，是没有发现存在磁盘坏块的。
可见这个部分就是一个遗漏的地方。
原本是通过下面的命令来监控磁盘坏块的。
/opt/MegaRAID/MegaCli/MegaCli64 -CfgDsply -a0|grep Error
但是如果通过下面的命令去查磁盘的状态就会发现有一块磁盘确实已经坏了。
# /opt/MegaRAID/MegaCli/MegaCli64 -PDList -aALL|grep Firmware
Firmware state: Online, Spun Up
Device Firmware Level: DA07
Firmware state: Online, Spun Up
Device Firmware Level: DA07
Firmware state: Online, Spun Up
Device Firmware Level: DA07
Firmware state: Online, Spun Up
Device Firmware Level: DA07
Firmware state: Unconfigured(bad)
Device Firmware Level: DA07
Firmware state: Online, Spun Up
Device Firmware Level: DA07
Firmware state: Online, Spun Up
Device Firmware Level: DA07
Firmware state: Online, Spun Up
Device Firmware Level: DA07
多么痛的领悟。带着这种思路去查看，发现我手头还有几个库有着类似的问题，所以监控中也得把握好这个度，逐步完善吧。
当然磁盘的问题是一个，也发现了另外的一些其它的硬件问题，知道了这么多的问题，赶紧得去好好搞搞灾备了。
从使用情况来看，也确实发现了一些坏块很多的问题，这也给我们的工作带来一些清晰的指导。不过感觉对于硬件的监控还在隔靴搔痒，还有很多的监控不够到位。或者太细感觉有些鸡肋，或者太粗有感觉有些笼统。而且还有些问题还是说不清道不明。
比如前段时间碰到一个问题，白天刚做过磁盘巡检，没有发现任何坏块，结果到晚上服务器就崩了。也没有任何的前兆，收到一条ICMP的报警之后，服务器就彻底失去连接了。对于这种问题，我们可以肯定的是磁盘没有坏块，所以数据肯定是没有丢，不过后续又做了确认，这个库已经没有业务在上面了，所以也算是侥幸逃过了一个忙碌而又纠结的恢复过程。之后我也在感慨，如果没有备库就是在耍流氓，而且感觉心里真是不踏实，如果你知道了哪些问题，可能老得担心，直到解决了才会心里踏实一些。
而且我们也一起讨论，发现一个比较奇怪的现象就是，很多服务器奔溃的情况都出现在半夜的时候，刚好是我们睡得真香的时候，它这么一折腾，我们一天都会没精打采。恢复的好，恢复的快，还能再多睡一会，系统忙，系统非常重要，估计连带的就是一大拨人了。如果细想，这个还是有一定的原因，可能还是在半夜的时候会有大量的备份和报表查询，批处理之类的任务可能对系统资源也会使用率比较高，也会直接间接导致一些潜在的问题。
可能还有一些原因就是我们没有发现针对性的硬件问题前兆，可能有些问题已经发生了很久，硬件监控的时候不一定能够及时捕捉到，有些可能是硬件的某一部分出现了一些警告，可能也很容易被忽略。
为此，我觉得得负责看看环境，不能让这种事情概率性的发生，至少应该能够提前预防好，过年的时候也能心安理得一些。
因为手头有一大拨机器的资源，于是就通过ILO的方式来查看历史的硬件情况。我就硬着头皮整理了一下，虽然枯燥，但是整理完再来看看，发现还是有些感悟。
比如像下面的这个问题，
这台服务器是一台MySQL的备库服务器，也是最近才移交到我手上，查看历史发现竟然已经开始有了主板的警告了，那么这台备库的服务器看来还是很有可能出现问题。那么如果在备库上每天进行大批量的备份和查询请求，那么这台服务器还是比较脆弱的。
再来看一台，可以发现这台似乎最近都是正常的，很久以前看报错细细，应该是电源坏了，然后近期raid卡电池看起来有一些警告信息，至于以前的信息是无法去求证了。但是所幸的是有电源恢复的记录。
当然我发现了这么一个警告。从告警来看，应该是硬盘直接坏掉了，但是从我之前的磁盘坏块监控来看，是没有发现存在磁盘坏块的。
可见这个部分就是一个遗漏的地方。
原本是通过下面的命令来监控磁盘坏块的。
/opt/MegaRAID/MegaCli/MegaCli64 -CfgDsply -a0|grep Error
但是如果通过下面的命令去查磁盘的状态就会发现有一块磁盘确实已经坏了。
# /opt/MegaRAID/MegaCli/MegaCli64 -PDList -aALL|grep Firmware
Firmware state: Online, Spun Up
Device Firmware Level: DA07
Firmware state: Online, Spun Up
Device Firmware Level: DA07
Firmware state: Online, Spun Up
Device Firmware Level: DA07
Firmware state: Online, Spun Up
Device Firmware Level: DA07
Firmware state: Unconfigured(bad)
Device Firmware Level: DA07
Firmware state: Online, Spun Up
Device Firmware Level: DA07
Firmware state: Online, Spun Up
Device Firmware Level: DA07
Firmware state: Online, Spun Up
Device Firmware Level: DA07
多么痛的领悟。带着这种思路去查看，发现我手头还有几个库有着类似的问题，所以监控中也得把握好这个度，逐步完善吧。
当然磁盘的问题是一个，也发现了另外的一些其它的硬件问题，知道了这么多的问题，赶紧得去好好搞搞灾备了。
