数据中心该如何进行日志分析.docx

数据中心该如何进行日志分析

在数据中心里，几乎所有的系统和应用程序都会产生日志文件。日志是带时间标记的足迹、记录行为、条件和事件，通过对日志进行分析，往往能够提前预知到数据中心运行的潜在风险，也能够在发生故障之后，通过日志信息找到故障发生的原因，就像是飞机的黑匣子一样，发生事故后追查原因的一个重要手段。然而，数据中心里的设备成千上万，安装的软件和应用程序复杂多样，每台设备，每个应用都有自己的日志打印，这样每天数据中心都会产生海量的日志信息，即使是最辛勤的管理员也无法在有生之年完成对逐个日志的甄别，大型数据中心运行中不断生成日志数据的速度已远远超过人类分析的速度，传统的数据分析方法是每周或每天依照列表审查日志文件，这种方法早已无法满足现在数据中心的要求，于是出现了很多日志分析工具、网络管理软件，利用这些分析软件来检查日志信息，以便代替人工查阅的方式，提升分析日志的速度，这也是目前数据中心里对日志分析的普遍做法，但实际上能够提前通过日志，预知隐患的很少，那应该如何利用日志信息来提升数据中心的可维护性呢，或者说通过分析日志，减少数据中心故障发生的概率呢，本文就来详细谈一谈。

首先，日志分析作用的大小，取决于日志信息的准确性。如果日志信息本身就是不可信的，那分析出来的结果自然不可信，所以要对日志信息进行甄别。数据中心里的绝大部分设备都具有日志打印，有的设备还可以按照要求将日志发向网络中特定的日志主机设备商。这些设备都有很多的日志打印开关，可以对日志信息进行过滤，那么哪些模块是特定的数据中心所关心的，就打开，否则进行关闭，避免产生一些无关紧要、无用的日志。另外日志信息本身的准确性也非常重要，比如设备上报了一条TheboardisFault，那么是单板坏了，还是软件重启了，是哪个槽位的板卡坏了?一条日志的信息要将整个事件的全貌反馈出来，而不是让使用者去猜，这就要求数据中心的设备商要提供标准的日志输出设计体系，日志简单明了，能够说明问题，而不是不知所云。这样能够在有问题或者在出问题之前有日志打印还好，就怕是故障已经发生了，而却没有报出任何的日志，这让人无从进行分析，而在数据中心运行正常的时候，反到噼哩叭啦地往外报无用的日志。若遇到这样的设备或者系统，就应该将它们扔进垃圾桶，这不是给数据中心添乱吗。所以，一定要保证日志信息的准确性，打印的每一条日志，都是需要数据中心管理员去关注的，并且要采取一定的预防措施。

其次，很多时候我们不好界定一些日志有没有用，所以经过裁剪、判断，还是会有很多的日志输出出来。比如我拔插个光模块，一定会有日志打印，端口的UP/DOWN，也一定会有日志打印，如果这些日志不打印出来，一旦有的时候是非人为的端口UP/DOWN，那就要查互联端口有没有问题，光模块有没有，光纤架或者跳线架有没有问题等等，所以很多时候一些日志并不是上报问题，但又不能不打印，这时就需要甄别。因为大型的数据中心的设备实在太多，这样日志信息收集起来也还是有很多，要靠人工每年去检查，不太现实。网络上有不少这类的日志分析工具，比如SiteFlow、IIS日志查看工具、光年日志分析工具等等，这些工具可以采集多台设备的日志信息，并且根据设定的过滤条件，对关键字进行过滤，对日志进行分类：提示、一般、告警、致命等多个等级，支持告警。可以将日志实时通告给数据中心管理员，数据中心管理员对收到的日志进行检查，根据日志的具体内容，启动相应的解决预案，如果不好处理，则可以立即召集相关技术人员一起讨论商议对策。

再次，日志信息是准确的了，也会让管理员及时知道什么设备报出了哪些日志，需要及时处理的，但这还远远不够。未来拥有数千台的数据中心往往就只要几个人来管理与维护，这些日志分析工作也只是这些人平时工作其中的小部分，这些人还有很多其它的事情要做，所以很多时候对日志的输出没有时间来理会，更多的时候是已经发生故障了，然后再回查故障当时和之前有没有什么打印日志，但故障已经发生了，影响已经造成了，再去看日志无非是想找到故障的原因，有时是希望通过故障原因来对数据中心进行改进和优化，避免再出这样类似的故障，这不是一个很好的做法。最好的做法时，在故障发生之前或者故障刚发生，就通

过日志得到故障事件，并通过自动化软件自动启动提前设置好的恢复预案，避免故障发生或者将故障带来的影响降低到最小，将日志和自动化恢复的动作结合起来，通过软件自动化判断当前收到日志的严重性，根据故障的等级来执行相应的动作，让数据中心自动恢复运行。最后，更多的设备仅仅靠日志分析，起不到什么效果，还需要通过流量分析工具，命令脚本工具来单独收集一些数据中心运行信息，这些信息往往可以包含比日志还要丰富的信息，将这些信息与日志