ヽ(・ω・。)ノ有没这样一个日志管理系统?

最早接触的日志管理应用是ELK,当时忽悠君坐在我对面成天喊要招个ES的大牛,一会林大师又在旁边写着各种正则式。还搞不清楚状况的我就开始改KIBANA,给KIBANA换个皮。无奈KIBANA实在太不好改了,时间也不是特别充裕,好吧,从头写一个还快,虽然效果不太好。具体那玩意是做什么的,当时也没细想,反正能展示出来就好了,就是给个关键字,然后展示下对应人日志。

过了没多久,就跑去听了一下Splunk的安利会议,听半天,好像什么都没收获到,提问的人问的问题也很技术,没有落到实用性上。不过现在回过头来想想,要说收获其实也算有的,就是我坐在会场,安装了环境之后半天都没搞明白怎么把日志塞进去。。。一堆的选项,都不知道点哪个好。再后来,就入坑了(具体是怎么入的参见《自动化运维软件设计实战》。。血泪史 (≡ω≡.) )

经历了一系列系统开发与运维后,其实作为开发者,我希望我接入的日志管理系统是这样的。

能够让我轻易的就把日志放进去

也算是当初刚上手Splunk的不满之一,太多的选项,都不知道点哪个,点下去会不会爆炸什么的。其实,作为开发者,我不就想把一些日志都收集起来,方便找嘛

不要一上来就要我写正则式

写了这么久程序,反正我是记不住几个正则式(/”≡ _ ≡)/~┴┴ (这反人类的正则式。。。我就只记住了.*)最好是能通过简单的几个符号就解决搜索的问题了(假如在谷歌或者百度上面搜个东西还要用正则式的话,请自行脑补)

能够搜索到上下文

有些时候日志打的很快,他们可能是不同线程打出来的,他们可能是不同服务器打出来的(不过带有一定的先后性),他们可能是不同应用打出来的,这个时候上下文就很重要了,没有了上下文,无论是运维还是开发,在排除的时候都只能看到一个点,没办法根据实际的情况进行排查。遇到复杂问题的时候也就这么2种处理方法。一种是:哦,这样啊,我试了没什么问题啊,要不,你下次再做操作的时候我这边也一起看看?另外一种情况是:这样啊,我们花时间查查究竟是什么原因(有很大几率是查不出来的ㄟ( ▔, ▔ )ㄏ )然后就不了了之了。所以上下文其实是挺重要的。这个地方出错了,那前面发生了什么事情了呢?

能够对日志进行平行的分析

场景1:在应用稳定之前,我基本上都是采取单服务器的方式跑,有些小伙伴会说,你这样单点了呢,不够可靠。且不说应用未完全稳定之前会对程序频繁的进行改动导致发布的不便(好吧,这个时候那些搞CI的就会跳出来了,我只能说,事情总不是想象中那么顺利的(´Д`) ,而且。。我一个人的话,我也懒得去搞就是了,哈哈),特别是多台服务器打日志的时候,我就会很烦恼,究竟这个请求落到哪台服务器上了? 报的什么样的错误?为什么其他服务器上又不会等等问题。碰到这种情况下,也就只能一台一台的登上去,tail -f xxxx.log,然后喊:”麻烦。。再点一次试试“。

场景2:小菜找到DBA,觉得数据库的主从是不是没同步到,DBA登上主库打开binlog,再登上从库打开binlog,看完日志之后,告诉小菜,从日志上来看,他们是同步的。

能够提取一些有价值的数据,做点图表

小菜在调用公司另外一个业务的接口的时候速度慢的不行,对方总说没问题啊,我这边看都挺好的。小菜心想,好吧,你不认账,我给你放个监控,每分钟都拨测你一下,等我手里有数据了,我还怕你不成?结果一周下来了,监控到的指标性能都挺不错的,但是用户还是反应调用接口的时候性能很差。无奈的小菜翻了翻服务器上自己每次调用接口打出来的日志,的确是挺慢的。但是小菜也没办法,这。。旧的日志自己当做垃圾数据给rm掉了,新的数据有是有那么些,但是一方面数据量不够,另外一方面,自己再去这么一堆日志文件里面提取挺费劲的,╮(╯▽╰)╭赶进度赶进度,性能的事情以后再说吧。

能够产生告警

监控告警这种事情本应该是监控系统干的,但是从日志上出发,也会给我们带来不一样的想法:在一个阳光明媚的早上,小菜熟练的打开了MySQL的客户端工具,在键盘下敲下来select * from …. 结果半天回不来结果?”奇怪?昨天都还很正常的啊?“于是赶紧向DBA求助,DBA登上服务器一看日志,发现服务器磁盘满了。。。。当然这种情况在生产环境下还是比较少见的,但是另外一种情况就比较多见了。B系统对A系统提供了对外的接口,A系统调用后出现调用失败,或者B系统返回调用成功但实际上却是调用失败的情况。这种时候就应该出现告警信息,提醒我们需要留意这个事件了,不然对于某些关键业务很容易就会出大问题的。(同时也保留一些罪证,哈哈哈o(*≧▽≦)ツ┏━┓)

小结

日志管理应用能够做的事情其实也挺多的,以上只是一些比较零散的点,晚上泡完脚突然有些想法,写下来顺便分享一下(话说晚上泡个脚还是挺舒服的(•̀ᴗ•́)و ̑̑ )但是都是从实际应用上出发提出的。看到过有些厂商貌似做了个服务器挂了之后就把日志传回去,然后自动生成一个case,接着就会有人处理了(好吧,反正我就只看过这种推广 (´・ω・`)。。实际是不是这个效果我就不知道了)。

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值