吐槽日志分析中几个常见但没啥用的功能_高效运维_传送门
吐槽日志分析中几个常见但没啥用的功能
前言日志分析是 IT 运维领域非常重要的一部分工作。甚至可以说，在平台化、模块化、服务化盛行的今天，这部分工作的重要性已经逼近传统的设备监控。不过日志由于来源、使用者、管理者都比设备指标要复杂，导致日志分析的功能需求，也庞大很多。在这些庞大的，或者说『泥沙俱下』的功能需求中，有那么一些然并卵的，或许因为听起来很炫酷，或许因为想延续过去的使用习惯，今天因为出差到外地，难得有空放松下，决定吐槽几个这种然并卵的功能。1. realtime alert排在第一位的就是所谓的『实时告警』。做一个告警系统，其实可以分成两类不同的目的：出现了问题要修复快要出问题得避免那么分开说：如果是要喊人来修复的，假设你的告警内容已经细化到完全不用再排查问题，从告警发出来，到你登录到服务器解决问题，至少也需要数分钟级别 —— 根据墨菲定律，这时候你很可能在睡觉在吃饭在坐车在团建，那么十分钟已经是你行动迅速了。那么告警是第 0.1 秒发出来的，跟是第 10 秒发出来的，有什么区别？而把告警从间隔 10 秒压缩到 1 秒内的实时，需要花费的架构调整和成本上升，可不是一点半点……你说一个关键字实时过滤没啥成本？那你需要先加强一下告警系统的追踪、扩展、抑制等功能呢，告警没那么简单如果是要提前避免的，一般你的基础架构已经进化的不错了，才会想要通过告警的触发动作来自动化修改你的流量、资源和任务调度编排。这种需求其实更多归入容量规划范畴，很难想象这种事情要实时性干嘛，谁家平台不打余量的？当然，不管上面哪种，我吐槽的都是追求 1 秒甚至毫秒的实时。如果你的监控间隔还停留在 5 分钟以上，可别拿我这段话做挡箭牌 —— 如果你从收到告警到解决问题需要小时级别，5 分钟可能是也不算多，但是你的故障定位方式，或者说告警系统的内容细化水平，更加需要提高。2. 翻页、翻页、翻页排在第二位的就是 show me more money，错了，logline。日志分析系统一般都会在界面上列出来日志原文供查看。而一帮『手贱』的人，就会很 happy 地点下一页下一页下一页下~一~页~下~然后系统出问题了。这个功能需求其实就是过去 cat logfile | grep KEYWORD | less习惯的遗毒。上来就恨不得自己能 vim 进去一行行开始看日志。Ctrl+F 嗷嗷翻页固然很爽，不知不觉中时间全都浪费掉了 —— 想想上一条你还想要的『实时』 —— 运维排查问题最适合的思路是快速试错！一个想法验证下不行赶紧验证下一个。如果一页 20 条日志你看不出来，两页 40 条日志你看不出来，你就赶紧改个时间段、改个关键词吧。当然，话说回来，老想着往后翻页，也有可能是真想不出来改用啥关键词。日志分析系统有必要提供帮助用户更快找到合适关键词的能力。这东西就是仪表盘可视化。利用正确的能力做正确的事，而不应该在有正确的方法的情况下继续使用麻烦办法。3. 经纬度地图既然说到可视化，可视化方面是做日志分析乃至数据分析最容易误入歧途的方向了。有兴趣的可以看下面几个链接，是我从 Kibana Plugin 社区讨论组里复制过来的：/the-27-worst-charts-of-all-time-2013-6?op=1&IR;=T/category/visualization/ugly-visualization/这些很复杂的可视化就不提了。在日志分析方面，最常见的一个炫酷的效果就是地图。地图可真是一个被各种玩出花来的东西，诸如安全攻击喜欢放个 3D 地球，在 google 图片上随便搜『DDoS atack earth』关键词，大把大把；做个推广活动，喜欢搞个实时连线的中国地图看 PV，全国各地，来一个访问，飞一个点出来到北京。。。真的是酷毙了。不过，然后呢？你看到这个点能干嘛？而且飞动中的点，唰唰就过去了，压根捕捉不到。说到实际情况，IT 日志分析需要地图的大多数时候是基于行政区划的统计。全局负载均衡绝大多数都是以行政区划和运营商为基准做的划分，如果通过地图真的定位到什么访问问题，很大可能下一步你能做的是通过商务手段去联系当地电信服务运营商！你要经纬度有什么用？—— 别忘了免费的 GeoIP 国内精准度本来就低。花点时间搞一个准确到地市运营商的 IP 地址库，才是最应该做的事情。4. 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 插件的选择。5. 全量下载(etl to BI)另一个和翻页有些类似的功能，就是要求全量日志下载。这种需求通常目的也是分两类，一类其实跟翻页是一个需求，不知道查啥内容，干脆要求把日志都下载回来自己慢慢折腾；另一类则是环境中有一些标准的 BI 软件，觉得日志分析软件的可视化和统计方法不够用，还是喜欢、习惯 BI，所以要求日志分析系统负责搜索，BI 系统负责分析。这块怎么说呢，列出来有些个人主观化，我个人不太觉得在 IT 运维领域，有啥是 BI 能做，而开源日志分析项目做不来的事情。退一步说：真要两个系统的结合，也应该是分层的架构。充分利用日志分析系统的分布式架构并行处理能力，将大量 map 操作在日志系统完成，将中间统计结果导入到 BI 中完成最后的 reduce 工作即可。非要把原日志（即使是归一化之后的结构数据）导入到 BI 里做统计，是一个耗时耗力的下下之选。6. live tail今天我能想到的最后一个恶习遗毒，同样还符合酷炫概念的功能，是 live tail，也有叫 web tail 或者 log tail 的。不知道从哪来的程序员情节，觉得终端的黑底白字最棒了，非要在浏览器页面上，通过 websocket 连接上某台服务器，实时查看某个日志文件的尾部滚动。或者简单说，就是一个 tail -F logfile 功能的网页化。由于网络的限制、浏览器渲染的限制(毕竟要很多酷炫效果呢)，这类功能一般实现出来带有诸多的限制：直接从 agent 建联，意味着后续的归一化结构是无法用来做复杂过滤的，同样还意味着跨平台能力削弱；需要限制使用者的并发数，以及每个连接的流速。一般来说是每秒不许超过 1000 条 —— 人肉眼其实每秒也看不过来这么多数据；为了限速，必须指定具体的 hostname 和 filename，无法使用通配符，无法跨文件关联查询；为了解决跨文件，在同一页面上切分屏幕，考虑美观和视觉，最多也就是切分一次，即一次可以看两个文件的 tail。我在最前面已经说到了，日志系统之所以现在重要性提高，就是因为日志前所未有的分散，两个分屏的 tail，有什么用？当然，回到这个伪需求的根本目的：我就是在调试而不是事后排错呢，怎么让我可以快速看到我横跨好几个模块的调试日志是否正常？这跟前面『无限翻页』类似：你真正需要的知道新入的日志有没有异常，而不是刷过去什么字样。通过 AND OR NOT 等过滤条件，通过时间排序，通过关联 ID，你完全可以在秒级得到更精准的、更有利于你阅读的日志。结语就写到这里吧，我犹豫很久要不要把人工智能机器学习写进来。考虑到异常探测和预测也算是机器学习的一部分，还是不一竿子打倒全部吧~~这里只说一句：我花时间翻了一打 IT 运维日志相关的机器学习论文，用神经网络的效果普遍比回归差。嗯~总之，大家老实干活就好了。还有更精彩的在这里 在12月16-17日两天，GOPS2016北京站将在国际会议中心举办，汇集成百上千的运维牛人将为你呈现内容更加精彩，时间更加持久的演讲。现在报名可享受 9折优惠请点击"阅读原文"进行报名！
觉得不错，分享给更多人看到
高效运维 微信二维码
分享这篇文章
11月23日 0:07
高效运维 最新文章
高效运维 热门文章更多公众号：rizhibang日志管理工具爱好者交流平台，分享日志管理相关知识，普及日志管理理念。发布日志管理领域的技术趋势，评测分享日志管理领域的开源及商业化产品。最新文章相关推荐搜狗：感谢您阅读日志分析中 6个常见但没啥用的功能，本文可能来自网络，如果侵犯了您的相关权益，请联系管理员。QQ:中国领先的IT技术网站
51CTO旗下网站
IT运维日志分析中有哪些常见但没啥用的功能
在这些庞大的，或者说『泥沙俱下』的功能需求中，有那么一些然并卵的，或许因为听起来很炫酷，或许因为想延续过去的使用习惯，今天因为出差到外地，难得有空放松下，决定吐槽几个这种然并卵的功能。
作者：小码哥来源：| 14:12
日志分析是IT运维领域非常重要的一部分工作。甚至可以说，在平台化、模块化、服务化盛行的今天，这部分工作的重要性已经逼近传统的设备监控。不过日志由于来源、使用者、管理者都比设备指标要复杂，导致日志分析的功能需求，也庞大很多。在这些庞大的，或者说『泥沙俱下』的功能需求中，有那么一些然并卵的，或许因为听起来很炫酷，或许因为想延续过去的使用习惯，今天因为出差到外地，难得有空放松下，决定吐槽几个这种然并卵的功能。
realtimealert
排在第一位的就是所谓的『实时告警』。做一个告警系统，其实可以分成两类不同的目的：
出现了问题要修复，
快要出问题得避免。
那么分开说：
如果是要喊人来修复的，假设你的告警内容已经细化到完全不用再排查问题，从告警发出来，到你登录到服务器解决问题，至少也需要数分钟级别&&根据墨菲定律，这时候你很可能在睡觉在吃饭在坐车在团建，那么十分钟已经是你行动迅速了。那么告警是第0.1秒发出来的，跟是第10秒发出来的，有什么区别?而把告警从间隔10秒压缩到1秒内的实时，需要花费的架构调整和成本上升，可不是一点半点&&(你说一个关键字实时过滤没啥成本?那你需要先加强一下告警系统的追踪、扩展、抑制等功能呢，告警没那么简单)
如果是要提前避免的，一般你的基础架构已经进化的不错了，才会想要通过告警的触发动作来自动化修改你的流量、资源和任务调度编排。这种需求其实更多归入容量规划范畴，很难想象这种事情要实时性干嘛，谁家平台不打余量的?
当然，不管上面哪种，我吐槽的都是追求1秒甚至毫秒的实时。如果你的监控间隔还停留在5分钟以上，可别拿我这段话做挡箭牌&&如果你从收到告警到解决问题需要小时级别，5分钟可能是也不算多，但是你的故障定位方式，或者说告警系统的内容细化水平，更加需要提高。
翻页翻页翻页
排在第二位的就是showmemoremoney，错了，logline。日志分析系统一般都会在界面上列出来日志原文供查看。而一帮『手贱』的人，就会很happy地点下一页下一页下一页下~一~页~下~然后系统出问题了。
这个功能需求其实就是过去catlogfile|grepKEYWORD|less习惯的遗毒。上来就恨不得自己能vim进去一行行开始看日志。Ctrl+F嗷嗷翻页固然很爽，不知不觉中时间全都浪费掉了&&想想上一条你还想要的『实时』&&运维排查问题最适合的思路是快速试错!一个想法验证下不行赶紧验证下一个。如果一页20条日志你看不出来，两页40条日志你看不出来，你就赶紧改个时间段、改个关键词吧。
当然，话说回来，老想着往后翻页，也有可能是真想不出来改用啥关键词。日志分析系统有必要提供帮助用户更快找到合适关键词的能力。这东西就是仪表盘可视化。利用正确的能力做正确的事，而不应该在有正确的方法的情况下继续使用麻烦办法。
经纬度地图
既然说到可视化，可视化方面是做日志分析乃至数据分析最容易误入歧途的方向了。有兴趣的可以看下面几个链接，是我从KibanaPlugin社区讨论组里复制过来的：
这些很复杂的可视化就不提了。在日志分析方面，最常见的一个炫酷的效果就是地图。地图可真是一个被各种玩出花来的东西，诸如安全攻击喜欢放个3D地球，在google图片上随便搜『DDoSatackearth』关键词，大把大把;做个推广活动，喜欢搞个实时连线的中国地图看PV，全国各地，来一个访问，飞一个点出来到北京。。。
真的是酷毙了。不过，然后呢?你看到这个点能干嘛?而且飞动中的点，唰唰就过去了，压根捕捉不到。
说到实际情况，IT日志分析需要地图的大多数时候是基于行政区划的统计。全局负载均衡绝大多数都是以行政区划和运营商为基准做的划分，如果通过地图真的定位到什么访问问题，很大可能下一步你能做的是通过商务手段去联系当地电信服务运营商!你要经纬度有什么用?&&别忘了免费的GeoIP国内精准度本来就低。花点时间搞一个准确到地市运营商的IP地址库，才是最应该做的事情。
全量下载(etltoBI)
另一个和翻页有些类似的功能，就是要求全量日志下载。这种需求通常目的也是分两类，一类其实跟翻页是一个需求，不知道查啥内容，干脆要求把日志都下载回来自己慢慢折腾;另一类则是环境中有一些标准的BI软件，觉得日志分析软件的可视化和统计方法不够用，还是喜欢、习惯BI，所以要求日志分析系统负责搜索，BI系统负责分析。
这块怎么说呢，列出来有些个人主观化，我个人不太觉得在IT运维领域，有啥是BI能做，而开源日志分析项目做不来的事情。退一步说：真要两个系统的结合，也应该是分层的架构。充分利用日志分析系统的分布式架构并行处理能力，将大量map操作在日志系统完成，将中间统计结果导入到BI中完成最后的reduce工作即可。
非要把原日志(即使是归一化之后的结构数据)导入到BI里做统计，是一个耗时耗力的下下之选。
第四个很常见的功能，就是SQL。这甚至不是日志分析领域的毛病，在所有和数据相关的、非关系型数据库的数据存储系统上，都会有大把人问：有SQL支持么?
就我的浅薄见识，对所有存储系统要FUSE挂载，对所有数据系统要SQL查询，应该是可以对等的两个吃力不讨好的工作了。在Hadoop上有无数个实现SQL的项目，哪怕Hive和SparkSQL这种级别的大项目在，我还是要说：研发同仁们想要SQL，不就是觉得自己已经会SQL，所以要无缝对接，不用学习新知识么?你们点开Hive文档，里面有多少是非标准SQL的函数功能?
只有极少数基础的、简单的过滤和统计函数，可以横跨API、SQL、DSL等方式，在各平台上都通用。而你选择某个大数据平台的实际理由，大多是它的xxxyyyzzz亮点功能，很好，你需要自己搞一个UDF了&&这还搞SQL有什么意义。
从编程语言学来一个经验，对特定领域，采用特定领域语言，即DSL的设计方式，永远是更加高效、灵活、优秀的选择。
在日志分析方面来说，抓住关键词检索、分组统计、上下文关联、时间序列这几个特性，你就可以抽象出来几个能覆盖足够场景的函数了，而借鉴命令行操作的形式，从左到右的书写习惯也比SQL的从右到左的形式更加符合数据流向的效果。
熟悉日志分析领域的人可能看出来我是在给SPL写软文了&&自Splunk发明SPL这种日志分析领域的DSL以来，已经有大批日志分析产品跟进了这个形式，SumoLogic、Rizhiyi、XpoLog、MicroSoftAzure、OracleCloudManagement等等。不过公平的说，上面一段要点，确实也可以提炼出来跟SPL不一样的DSL设计，比如说：更接近面向对象编程语言的链式调用函数，同样也符合这个习惯&&这也是ELK从5.0开始分发的timelion插件的选择。
今天我能想到的最后一个恶习遗毒，同样还符合酷炫概念的功能，是livetail，也有叫webtail或者logtail的。不知道从哪来的程序员情节，觉得终端的黑底白字最棒了，非要在浏览器页面上，通过websocket连接上某台服务器，实时查看某个日志文件的尾部滚动。或者简单说，就是一个tail-Flogfile功能的网页化。
由于网络的限制、浏览器渲染的限制(毕竟要很多酷炫效果呢)，这类功能一般实现出来带有诸多的限制：
直接从agent建联，意味着后续的归一化结构是无法用来做复杂过滤的，同样还意味着跨平台能力削弱;
需要限制使用者的并发数，以及每个连接的流速。一般来说是每秒不许超过1000条&&人肉眼其实每秒也看不过来这么多数据;
为了限速，必须指定具体的hostname和filename，无法使用通配符，无法跨文件关联查询;
为了解决跨文件，在同一页面上切分屏幕，考虑美观和视觉，最多也就是切分一次，即一次可以看两个文件的tail。
我在最前面已经说到了，日志系统之所以现在重要性提高，就是因为日志前所未有的分散，两个分屏的tail，有什么用?
当然，回到这个伪需求的根本目的：我就是在调试而不是事后排错呢，怎么让我可以快速看到我横跨好几个模块的调试日志是否正常?
这跟前面『无限翻页』类似：你真正需要的知道新入的日志有没有异常，而不是刷过去什么字样。通过ANDORNOT等过滤条件，通过时间排序，通过关联ID，你完全可以在秒级得到更精准的、更有利于你阅读的日志。
就写到这里吧，我犹豫很久要不要把人工智能机器学习写进来。考虑到异常探测和预测也算是机器学习的一部分，还是不一竿子打倒全部吧~~这里只说一句：我花时间翻了一打IT运维日志相关的机器学习论文，用神经网络的效果普遍比回归差。嗯~总之，大家老实干活就好了。【编辑推荐】【责任编辑： TEL：（010）】
大家都在看猜你喜欢
头条头条外电头条外电
24H热文一周话题本月最赞
讲师：49人学习过
讲师：32人学习过
讲师：11人学习过
精选博文论坛热帖下载排行
本书按照国家人事部、信息产业部全国计算机技术与软件专业资格（水平）考试要求编写，内容紧扣《网络管理员考试大纲》。全书共分为11章，覆...
订阅51CTO邮刊实时告警系统之jepl DSL开发 - 推酷
实时告警系统之jepl DSL开发
近半年业余时间会时不时的看一些编译原理的基础知识。这两个周终于派上用场了。
目前在开发一个json流实时处理的告警系统，需要开发一个DSL来让用户输入告警需要的metric表达式和过滤条件。考虑到运维人员大部分都擅长SQL，决定采用类SQL的方式来和用户交互一些告警相关的信息。这样可以避免web界面显示各种各样的单选框和复选框之类让人生畏的东西，同时还可以保证告警的几个模块元素复用，类似于一个个的小组件，设置一次后就可以通过托拉拽排列组合生成各种各样的告警表达式和过滤条件。
后台全部采用GO语言开发，数据源是一条条的json数据，DSL的作用就是对一条条的json数据进行过滤和聚合，然后生成时间序列的一个个数据点。基本等同于sql的select的一个子集，只有where子句，group by，limit之类的全都不需要。
目前我把这个DSL叫做jepl(JSON Event Process Language)，其实类似于spark streaming sql的一个前端，但是支持的特性肯定比spark sql要少得多。
一般定义好文法后开发一个DSL有两条路，一条是基于lex && yacc之类的工具通过文法自动生成tokenizer和grammar parser以及interpreter，各种语言都有自己的一套类似的工具。一种是自己手工写各个组件，手工写一般也是照着LL的固定套路来。考虑到后期需要进行错误的定制化输出以及语法检查，代码高亮等各种需求，最终还是决定手撸一把。
目前已经开发的差不多了，一开始自己手写了词法分析和语法分析部分，不过质量很烂，后来发现influxql的代码质量相当不错，于是废弃掉了自己的代码，直接基于influxql的代码修改，大部分还是influxql的源代码，不过做了大量的删减和一小部分的修改，还有一些对外接口封装，bug和正确性验证的东西要修改，已经可以输入一个sql语句和一段json数据，输出时间序列的数据点了。后期会投入很大一部分精力在上面。
不得不说对于一个新手来说做这个东西还是有点耗费脑力的，不过这也是在补习大学欠下的债，基本的DSL设计和实现应该是大学本科编译原理课程的基本要求吧。
总结一下近半年来看过的编译原理相关的经典书籍和文章
这个系列的文章非常好，里面作者手绘的插图非常可爱，简单易懂，也是我入门看的第一个系列的教程，使用python语言来讲解，从简单的四则运算表达式讲起，后续到复杂的四则运算表达式，再到后面的DSL的解析器，每一个步骤很清晰，而且也有github配套源代码。里面的计算器相关的代码我从头到尾手写了三遍，每隔一段时间感觉要忘记了的时候就从头来一遍。我推荐给了每一个想入门编译原理的新人。
这个文章是Influxql的其中一个开发者写的一个简单sql解析的入门文章，只有词法分析和语法分析，套路和influxql的开发是一样的，也有配套的github源代码。
这个是Go语言的作者的一个演讲，将如何用go语言开发一个字符串模版系统的词法分析器，通常的模式是parser调用lexer来一个一个的token解析，但是go语言天生的channel和goroutine特性可以让lexer和parser彻底分离开，中间通过channel来通信。
这本书是我看过的非常好的一个编译原理的入门书，说实话，比龙书容易入门多了，里面不但讲各种模式而且循序渐进的讲了为什么需要这种模式，这种模式比上一种的好处是什么，坏处是什么，解决了哪些问题。这本书需要读三遍。
上面一些博客的通用缺点是直接给出了这本书中的某一模式的代码实现，包括influxql的代码，而这本书就是为各种博客的代码提供了理论的支持，并且抽象出了通用的规则。
已发表评论数()
请填写推刊名
描述不能大于100个字符!
权限设置： 公开
仅自己可见
正文不准确
标题不准确
排版有问题
主题不准确
没有分页内容
图片无法显示
视频无法显示
与原文不一致