数据中心里如何做好日志监控

日志是带时间标记的足迹、记录行为、条件和事件,数据中心里的任何设备都会有日志输出,对这些日志进行管理是数据中心运维工作的重要组成部分。日志管理不但可以对日常操作进行控制与管理提供依据,还可以在某些故障发生之前通过日志信息就能感知到,也可以在故障发生时打印一些异常记录,还可以供故障发生后分析使用。作为数据中心的运维人员学会检查和分析日志数据,是一项必备的技能。然而日志是一把“双刃剑”,用好它,可以大幅提升数据中心的运维水平,降低数据中心的故障发生概率,节约运维开销;用不好它,反而会画蛇添足,增加运维的工作量,加大开销,所以对于数据中心日志的管理和使用,是一门大学问,如何灵活运用是摆在每个数据中心运维者面前的一道难题。本文抛砖引玉,说一说这里的道道。

数据中心里的设备成千上万,尤其是大型数据中心,各种服务器、网络设备、安全与存储等,拥有数千台设备的规模很正常,如果这些设备每台一天报一条日志信息,那么就是数千条日志,这个数据量可想而知。而且最为令人头疼的是,不同厂家甚至是同一厂家的不同型号设备的日志信息格式完全不同,无法通过通用的日志服务器去采集,有时甚至要一类设备用一种日志服务器,另一类设备用另外一种。一个数据中心为了获取所有设备的日志信息,要搭建数个日志服务器,分别进行监控,这样查看和管理起来非常不便,而且不同设备的日志风格不同,有些信息含义并不十分明确,让人丈二和尚摸不着头脑,这都让日志的作用大打折扣。还有很多问题,并不能通过日志提前发现问题。平时可能设备上报了很多日志信息,但是都是一些无关痛痒的无用信息,而真正出现故障了,反而没有任何日志报出了,采集这样的日志信息无助于数据中心管理提升,而是给数据中心添乱。还有不少的数据中心为了节省管理费用,管理网与数据网合一,管理网的数据也走业务转发设备,这样在真正出现故障时,日志信息经过的网络路径也出了故障,就会导致日志信息的丢弃,也错失了避免严重故障的机会,这些都是当前数据中心在日志监控上面临的问题。

怎样将数据中心的日志监控有效做起来,是每个数据中心最为关心的问题。首先,日志信息要统一格式。作为甲方,数据中心有权利要求其采购的设备输出日志符合通用日志服务器采集的格式,无法满足的设备坚决不再进行后期采购,如此一来就可以在整个数据中心部署一套日志监控设备即可,这样可大幅节省监控设备的运维支出;其次,日志采集与业务转发分离,日志数据走单独的管理网,管理网一般是通过专有设备将所有设备的管理口,服务器的单独网卡连接起来,这样业务网络有中断,并不影响到日志数据的收集,这样往往可以给分析问题提供及时、有效的信息,缩短故障定位和恢复的时间;第三,日志信息要简洁和准确,一个大型数据中心数千台设备,不能什么日志都向日志主机发送,只有可能影响到转发业务的日志才会采集,如果设备无法控制,就在日志服务器上进行控制,对不同日志进行等级分类,平时只关注级别高的告警,级别低的忽略不计。此时,设备提供的日志准确性尤为重要,哪些日志可能会影响业务,哪些日志是提示性的,哪些日志是操作类的记录,这样分得清楚,这样在日志服务器上可以调取自己关心的那类日志,不用全部查看,这将大大节省日常运维的检查时间;第四,很多数据中心已经开始做自动化的运维管理,对日志服务器增加自动化检查的脚本,通过脚本对日志进行检查,这样可大大节省人工成本。这种自动化运维管理是通过TCL脚本,对日志进行检查,当发现异常关键字时,给出自动告警,有些脚本还可以自动执行一些恢复的设备命令,这样达到发现故障自行恢复的目的。比如:可以在自动化脚本中增加“Fan is fault”的判断,当发现日志里出现这样的字样时就主动给出提示,或者将告警直接发向运维人员的值班手机上,这样运维人员立即就能知道是哪台设备的风扇出了问题,日志自动化管理是数据中心提升运维水平的重要手段;第五,与设备商做好交流沟通,要求设备商提供完整的日志信息,包括告警级别的分类,这些日志的准确性将直接决定未来运维的效率,如果设备商的设备在故障时,并没有从日志中反映出来,就说明这些设备做得还不够好,要改进。所有的故障都应该通过日志反映出来,这样才能高效运维。设备可维护性也可作为数据中心未来采购的重要参考标准。操作灵活性差,信息记录缺失都是可维护性差的表现,对于这类设备应检查采购或不采购。数据中心出了问题并不可怕,可怕的是出了问题后还不知道怎么回事,没有历史记录可查。

日志监控是未来数据中心管理的重要组成部分,通过日志监控可以避免或者减少业务故障的时间,对于数据中心运维特别有意义。当然,日志监控并不能解决数据中心所有问题,数据中心业务特别复杂,问题表现各异,就算日志监控做得再完整,很多问题也不能通过日志完全反映出来。比如通过FTP下载数据慢,这样业务层问题,通过日志很难反映出来,就需要借助抓包、统计报文等其它手段再深入分析。总之,日志监控还需要不断完善,不仅是数据中心,也需要数据中心设备提供商一起努力,将日志监控做好,从而提升数据中心的运维水平。

本文转自d1net(原创)

时间: 2024-10-18 11:06:15

数据中心里如何做好日志监控的相关文章

浅谈数据中心里的光纤测温技术

数据中心对温度要求很高,要全年365天恒温.但是,实际上在数据中心机房内部,不同位置的温度是有差别的,如果通风不好,虽然在同一个数据中心里温度也可以相差好几度,这样局部位置的温度比较高,长期处于这个位置的设备就会受到影响,甚至会加速设备的运行老化,所以一般在数据中心里会部署一些温度传感器,对数据中心的局部温度进行监控,使用方式有热电阻传感器.热电偶传感器.特殊的半导体传感器等,不过这种方式单点测量范围小.布线复杂.容易损坏.维护工作量又大,往往一个通道内只设1-2个温度采集点,采集点数量太少,无

以数据为依据做好SEO监控

大家好,我是梁磊,网名:石头.因为最近百度一直无法让很多站长和SEO人员保持淡定,每天都有许多SEO人去各大论坛.QQ群咨询问题,最多的就是"我的网站为什么被K"."多久才能恢复过来"等等诸如之类的问题满天飞,通常QQ群里大家都会各执己见,有人说你的内容做的不好.有人说你的外链太多.有人说你的站内优化过度等等,大家分析来分析去最后还是"无解",我想每个做SEO的基本上都清楚那些东西,但我们怎样才能让自己的观点有依据呢?那些看法可能都是我们的猜测,

如何做好数据中心里大本大宗的割接工作

割接是对正在使用的线路.设备进行操作,将会直接影响到上面承载的业务.割接是数据中心工作的重要部分,由于涉及到业务变更.软件升级.设备上下线等操作,可能会对现有业务造成影响,甚至中断,所以割接也是数据中心工作中最具挑战的部分.一次割接任务完成的是否漂亮,对数据中心未来的运营效果有很大影响,一般在割接之前都要做缜密计划,确保割接顺利.我们知道,数据中心里的故障80%都是人为失误造成的,而割接必然涉及到人为操作,出错是必然的,哪个数据中心割接没出过几次小问题,只要能够及时补救,一般不会产生过多负面影响

linux中MySQL慢日志监控shell脚本实例

针对脚本的注解和整体构思,我会放到脚本之后为大家详解. #!/bin/bash    MON_FILE="$2"   # 指定所要监控的脚本路径 SEC=60          # 指定所要监控的频率,即间隔多久去查看一次 MON_POINT_FILE=/tmp/mon_mysql_slow.point  # 指定MySQL慢日志的监控点存放的路径 DIFF_MON_FILE=/tmp/mon_mysql_slow.log     # 指定在监控频率内增加的MySQL慢日志信息存放路径

日志监控告警系统的设计与实现

日志监控告警系统 基于的日志进行监控,监控需要一定规则,对触发监控规则的日志信息进行告警,告警的方式,是短信和邮件. log4j---->error,info,debug 应用程序程序的日志  error级别 TimeOutException 角标越界IndexXXXException ......Error   com.alibaba.jstorm.daemon.worker.WorkerData]-[INFO] Current worker taskList:[1, 2, 3, 4, 5,

linux-java开发一个日志监控系统

问题描述 java开发一个日志监控系统 java开发一个日志监控系统,监控linux日志和windows日志,并把当前监控情况在web页面上展现 解决方案 没看明白是什么意思,是web项目不?如果是,可以用spring的AOP做日志,很方便,效率也高,把日志存数据库然后再做显示 解决方案二: 是web项目, 但是不是写日志.而已用java程序来监控window下的日志文件,有些日志文件是在linux下的(因为有些项目是部署在linux系统里的).需要是读取这些日志文件,如果监控到日志文件中有er

如何改变运维在数据中心中的地位

运维是数据中心里最为重要的工作,但却常常被人所忽略,这主要原因在于运维的工作是花钱部门,并且投入资金短时也看不到效果.而在运行出了故障时,又要运维被黑锅,将矛头指向了运维.实际上,一个数据中心运行的是否稳固是从其最开始建设就一定程度上决定了,就像一个人一样出身是非常重要的,虽然并不能代表全部.一个数据中心在最开始建设的时候要求就很高,各方面建设非常标准,冗余和备份系统非常完善,这样的数据中心后期运维也会很轻松,故障发生概率很低,即便出了故障也有备份系统正常接管业务,确保业务不受任何影响.不过,就

Entity Framework 缓存处理与日志监控

在Kooboo中使用了Entity Framework作为持久化框架,但由于EF1.0并没有提供完整缓存解决方案,一直以来都在为数据缓存而烦脑,在没有找到合适解决方案的情况下,采取了临时的解决办法:直接缓存实体.但是由于Entity实体都是带状态的,并且都与ObjectContext有间接的反向引用,缓存带状态的实体,会造成对象上下文混乱和连接资源的无法被正确释放.因此缓存的Entity实体,首先必须被分离或者重新定义POCO实体来代替Entity实体作为缓存对象.这样一来,所有的缓存实体的关联

ElasticSearch实战-日志监控平台

1.概述 在项目业务倍增的情况下,查询效率受到影响,这里我们经过讨论,引进了分布式搜索套件--ElasticSearch,通过分布式搜索来解决当下业务上存在的问题.下面给大家列出今天分析的目录: ElasticSearch 套件介绍 ElasticSearch 应用场景和案例 平台架构 下面开始今天的内容分享. 2.ElasticSearch 套件 2.1LogStash LogStash是一个开源的.免费的日志收集工具,属于Elastic家族的一员,负责将收集的日志信息输送到ElasticSe