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

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

livetail

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

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

直接从agent建联,意味着后续的归一化结构是无法用来做复杂过滤的,同样还意味着跨平台能力削弱；

需要限制使用者的并发数,以及每个连接的流速.一般来说是每秒不许超过1000条——人肉眼其实每秒也看不过来这么多数据；

为了限速,必须指定具体的hostname和filename,无法使用通配符,无法跨文件关联查询；

为了解决跨文件,在同一页面上切分屏幕,考虑美观和视觉,最多也就是切分一次,即一次可以看两个文件的tail.

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

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

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

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

（编辑：ASP站长网）