日志分析中有哪些常见但没啥用的功能？

《日志分析中有哪些常见但没啥用的功能？》要点：
本文介绍了日志分析中有哪些常见但没啥用的功能？，希望对您有用。如果有疑问，可以联系我们。

日志分析是IT运维领域非常重要的一部分工作.甚至可以说,在平台化、模块化、服务化盛行的今天,这部分工作的重要性已经逼近传统的设备监控.不过日志由于来源、使用者、管理者都比设备指标要复杂,导致日志分析的功能需求,也庞大很多.在这些庞大的,或者说『泥沙俱下』的功能需求中,有那么一些然并卵的,或许因为听起来很炫酷,或许因为想延续过去的使用习惯,今天因为出差到外地,难得有空放松下,决定吐槽几个这种然并卵的功能.

文章出处：三斗室

链接：http://chenlinux.com/2016/11/15/important-unuseful-feature-in-log-analysis/

realtimealert

排在第一位的就是所谓的『实时告警』.做一个告警系统,其实可以分成两类不同的目的：

出现了问题要修复,

快要出问题得避免.

那么分开说：

如果是要喊人来修复的,假设你的告警内容已经细化到完全不用再排查问题,从告警发出来,到你登录到服务器解决问题,至少也需要数分钟级别——根据墨菲定律,这时候你很可能在睡觉在吃饭在坐车在团建,那么十分钟已经是你行动迅速了.那么告警是第0.1秒发出来的,跟是第10秒发出来的,有什么区别?而把告警从间隔10秒压缩到1秒内的实时,需要花费的架构调整和成本上升,可不是一点半点……(你说一个关键字实时过滤没啥成本?那你需要先加强一下告警系统的追踪、扩展、抑制等功能呢,告警没那么简单)

如果是要提前避免的,一般你的基础架构已经进化的不错了,才会想要通过告警的触发动作来自动化修改你的流量、资源和任务调度编排.这种需求其实更多归入容量规划范畴,很难想象这种事情要实时性干嘛,谁家平台不打余量的?

当然,不管上面哪种,我吐槽的都是追求1秒甚至毫秒的实时.如果你的监控间隔还停留在5分钟以上,可别拿我这段话做挡箭牌——如果你从收到告警到解决问题需要小时级别,5分钟可能是也不算多,但是你的故障定位方式,或者说告警系统的内容细化水平,更加需要提高.

翻页翻页翻页

排在第二位的就是showmemoremoney,错了,logline.日志分析系统一般都会在界面上列出来日志原文供查看.而一帮『手贱』的人,就会很happy地点下一页下一页下一页下~一~页~下~然后系统出问题了.

这个功能需求其实就是过去catlogfile|grepKEYWORD|less习惯的遗毒.上来就恨不得自己能vim进去一行行开始看日志.Ctrl+F嗷嗷翻页固然很爽,不知不觉中时间全都浪费掉了——想想上一条你还想要的『实时』——运维排查问题最适合的思路是快速试错!一个想法验证下不行赶紧验证下一个.如果一页20条日志你看不出来,两页40条日志你看不出来,你就赶紧改个时间段、改个关键词吧.

当然,话说回来,老想着往后翻页,也有可能是真想不出来改用啥关键词.日志分析系统有必要提供帮助用户更快找到合适关键词的能力.这东西就是仪表盘可视化.利用正确的能力做正确的事,而不应该在有正确的方法的情况下继续使用麻烦办法.

经纬度地图

既然说到可视化,可视化方面是做日志分析乃至数据分析最容易误入歧途的方向了.有兴趣的可以看下面几个链接,是我从KibanaPlugin社区讨论组里复制过来的：

http://www.businessinsider.com/the-27-worst-charts-of-all-time-2013-6?op=1&IR=T

http://flowingdata.com/category/visualization/ugly-visualization/

这些很复杂的可视化就不提了.在日志分析方面,最常见的一个炫酷的效果就是地图.地图可真是一个被各种玩出花来的东西,诸如安全攻击喜欢放个3D地球,在google图片上随便搜『DDoSatackearth』关键词,大把大把；做个推广活动,喜欢搞个实时连线的中国地图看PV,全国各地,来一个访问,飞一个点出来到北京...

真的是酷毙了.不过,然后呢?你看到这个点能干嘛?而且飞动中的点,唰唰就过去了,压根捕捉不到.

说到实际情况,IT日志分析需要地图的大多数时候是基于行政区划的统计.全局负载均衡绝大多数都是以行政区划和运营商为基准做的划分,如果通过地图真的定位到什么访问问题,很大可能下一步你能做的是通过商务手段去联系当地电信服务运营商!你要经纬度有什么用?——别忘了免费的GeoIP国内精准度本来就低.花点时间搞一个准确到地市运营商的IP地址库,才是最应该做的事情.

全量下载(etltoBI)

另一个和翻页有些类似的功能,就是要求全量日志下载.这种需求通常目的也是分两类,一类其实跟翻页是一个需求,不知道查啥内容,干脆要求把日志都下载回来自己慢慢折腾；另一类则是环境中有一些标准的BI软件,觉得日志分析软件的可视化和统计方法不够用,还是喜欢、习惯BI,所以要求日志分析系统负责搜索,BI系统负责分析.

这块怎么说呢,列出来有些个人主观化,我个人不太觉得在IT运维领域,有啥是BI能做,而开源日志分析项目做不来的事情.退一步说：真要两个系统的结合,也应该是分层的架构.充分利用日志分析系统的分布式架构并行处理能力,将大量map操作在日志系统完成,将中间统计结果导入到BI中完成最后的reduce工作即可.

非要把原日志(即使是归一化之后的结构数据)导入到BI里做统计,是一个耗时耗力的下下之选.

SQL

第四个很常见的功能,就是SQL.这甚至不是日志分析领域的毛病,在所有和数据相关的、非关系型数据库的数据存储系统上,都会有大把人问：有SQL支持么?

就我的浅薄见识,对所有存储系统要FUSE挂载,对所有数据系统要SQL查询,应该是可以对等的两个吃力不讨好的工作了.在Hadoop上有无数个实现SQL的项目,哪怕Hive和SparkSQL这种级别的大项目在,我还是要说：研发同仁们想要SQL,不就是觉得自己已经会SQL,所以要无缝对接,不用学习新知识么?你们点开Hive文档,里面有多少是非标准SQL的函数功能?

只有极少数基础的、简单的过滤和统计函数,可以横跨API、SQL、DSL等方式,在各平台上都通用.而你选择某个大数据平台的实际理由,大多是它的xxxyyyzzz亮点功能,很好,你需要自己搞一个UDF了……这还搞SQL有什么意义.

从编程语言学来一个经验,对特定领域,采用特定领域语言,即DSL的设计方式,永远是更加高效、灵活、优秀的选择.

在日志分析方面来说,抓住关键词检索、分组统计、上下文关联、时间序列这几个特性,你就可以抽象出来几个能覆盖足够场景的函数了,而借鉴命令行操作的形式,从左到右的书写习惯也比SQL的从右到左的形式更加符合数据流向的效果.

（编辑：云计算网_泰州站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!