日志分析中 6 个常见但没啥用的功能

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

realtime alert

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

出现了问题要修复，
快要出问题得避免。

那么分开说：

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

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

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

翻页翻页翻页

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

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

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

经纬度地图

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

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

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

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

全量下载(etl to BI)

另一个和翻页有些类似的功能，就是要求全量日志下载。这种需求通常目的也是分两类，一类其实跟翻页是一个需求，不知道查啥内容，干脆要求把日志都下载回来自己慢慢折腾；另一类则是环境中有一些标准的 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 等方式，在各平台上都通用。而你选择某个大数据平台的实际理由，大多是它的xxx yyy zzz亮点功能，很好，你需要自己搞一个 UDF 了……这还搞 SQL 有什么意义。

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

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

熟悉日志分析领域的人可能看出来我是在给 SPL 写软文了……自 Splunk 发明 SPL 这种日志分析领域的 DSL 以来，已经有大批日志分析产品跟进了这个形式，SumoLogic、Rizhiyi、XpoLog、MicroSoft Azure、Oracle Cloud Management 等等。不过公平的说，上面一段要点，确实也可以提炼出来跟 SPL 不一样的 DSL 设计，比如说：更接近面向对象编程语言的链式调用函数，同样也符合这个习惯 —— 这也是 ELK 从 5.0 开始分发的 timelion 插件的选择。

live tail

今天我能想到的最后一个恶习遗毒，同样还符合酷炫概念的功能，是 live tail，也有叫 web tail 或者 log tail 的。不知道从哪来的程序员情节，觉得终端的黑底白字最棒了，非要在浏览器页面上，通过 websocket 连接上某台服务器，实时查看某个日志文件的尾部滚动。或者简单说，就是一个 tail -F logfile 功能的网页化。

由于网络的限制、浏览器渲染的限制(毕竟要很多酷炫效果呢)，这类功能一般实现出来带有诸多的限制：

直接从 agent 建联，意味着后续的归一化结构是无法用来做复杂过滤的，同样还意味着跨平台能力削弱；
需要限制使用者的并发数，以及每个连接的流速。一般来说是每秒不许超过 1000 条 —— 人肉眼其实每秒也看不过来这么多数据；
为了限速，必须指定具体的 hostname 和 filename，无法使用通配符，无法跨文件关联查询；
为了解决跨文件，在同一页面上切分屏幕，考虑美观和视觉，最多也就是切分一次，即一次可以看两个文件的 tail。

我在最前面已经说到了，日志系统之所以现在重要性提高，就是因为日志前所未有的分散，两个分屏的 tail，有什么用？

当然，回到这个伪需求的根本目的：我就是在调试而不是事后排错呢，怎么让我可以快速看到我横跨好几个模块的调试日志是否正常？

这跟前面『无限翻页』类似：你真正需要的知道新入的日志有没有异常，而不是刷过去什么字样。通过 AND OR NOT 等过滤条件，通过时间排序，通过关联 ID，你完全可以在秒级得到更精准的、更有利于你阅读的日志。

就写到这里吧，我犹豫很久要不要把人工智能机器学习写进来。考虑到异常探测和预测也算是机器学习的一部分，还是不一竿子打倒全部吧~~这里只说一句：我花时间翻了一打 IT 运维日志相关的机器学习论文，用神经网络的效果普遍比回归差。嗯~总之，大家老实干活就好了。