记得十年前，我曾问过一名应用运维工程师，如何用两个关键词描述下自己的日常工作？
他居然不假思索，略带调侃的回答我， “背锅” 与 “惊醒”，随即愣了一下，改口说，“发布” 与 “排障”。
的确，在人肉化运维时代，“你的软件是否支持傻瓜式运维？” 似乎成为了一种判定系统可运维能力的标准，找个应届生，懂点 Linux 命令，上传下 JAR 包，执行下开发给你写好的脚本，或是给你搞个 WEB 导航栏，东按一下，西按一下，报错了？找开发解决就行了。
多年前，许多人都预测在不久的将来，DevOps 将彻底取代传统运维，但我却不以为然，总觉得运维人员更应该提升在自动化方面的能力，并学习和钻研在不同应用场景中如何平稳落地，不能生搬硬套，说白了，就是学会如何利用自动化工具，更大程度的节省人力。
但如果系统规模越来越大，复杂度越来越高，自动化程度达到一定高度之后，“如何利用数据代替机器决策、分析？如何基于大数据技术，帮助在告警过滤、异常监测、自动修复等环节发挥效用，提高整体运维效率，降低运维成本？”，就会成为你下一阶段的探索目标。
对许多企业来说，这是一个漫长的演进过程。在 2018 年，在部分中间件系统的监控、故障趋势与定位、资源使用等场景中，我们尝试基于 Apache Kylin 做了一些探索，通过本文分享给大家。
当时中间件运维的监控现状
在很长一段时间里，我们的运维监控都是基于 Zabbix 和 ELK 这两个工具。
Zabbix，用于监视各种网络参数，保证服务器系统的安全运营，并提供灵活的通知机制。
通过上图可以看到，我们基本用 Zabbix 来监控一些基础标准服务，什么网络呀，磁盘，内存等等。
既然是工具，总有它的局限性，虽然 Zabbix 支持 API 二次开发，但对开发能力与精力投入有一定要求，因此，如果你的系统中带有自定义协议，并还想增加一些监控逻辑的话，一般不会选择 Zabbix 进行处理。
如果按概率计算，由基础架构引发的故障毕竟是小概率事件，大部分的异常都是由应用缺陷或 BUG 引起的，而现在的应用又越拆越碎，越拆越细，大量的开源系统纵横交错，一旦问题爆发，基本很难在第一时间定位问题根源。
在这样的情况下，我们选择 ELK，希望通过对系统日志、 应用日志、安全日志的收集、分析、定位来找到故障原因，提高诊断的效率，同时对系统情况有个全面的理解，避免事后救火的被动。
图 1. 分布式缓存（A 组代理层）的日志流水
图 2. 分布式缓存（A 组代理层）的统计汇总页
图 3. 分布式缓存（A 组代理层）的流量均衡
图 4. 分布式缓存（A 组代理层）的平均耗时
乍看之下，故事讲到这就应该圆满结束了。因为我们似乎找到了解决方案，毕竟 ELK 有着强大的强大的搜索功能，完美的展示功能，还具有分布式特性，能够解决大型集群运维工作很多问题。
为什么不在 ELK 这条路上一黑到底？
去年听过某期《逻辑思维》，主题叫 “限制也能激发创造力？”。
当时听完，没什么太大的触动，只觉得故事挺精彩，观点很新奇。
2018 年下半年，互联网寒冬悄悄来袭，金融行业首当其冲，我们开始对 IT 资源的投入进行合理的调整。
第一条，便是 “无特殊需求，不再采购新服务器”。
大家都明白，系统的演进是一个不断采坑与填坑的过程，加之应用越拆越碎，越拆越细，如果你系统的部署不在容器云上，且不具备弹性伸缩的能力，光靠普通的虚拟化技术是无法达到硬件资源相对程度的最大利用率的。
通过购买新服务器来进行短时间缓冲、中转，在搞技术的小伙伴看来，似乎是一件合情合理的事情。
但在老板的眼中，业务没变化，流量没增加，花钱投资硬件？你们觉得合适吗？没毛病。
此时，我才开始逐渐领悟 “限制也能激发创造力？” 的真正含义。
有人说，应用拆分、ELK、购买引荐，这三者之间有啥关系？何况你谈的是中间件，还不是应用，你太会扯淡了吧。
先别急着喷，下面我来通过一个案例进行说明下。
对 ELK 有了解的人都知道，ELK，是 ElasticSearch、Logstash、Kibana 的组合，其中，ElasticSearch（以下简称 ES）主要负责提供搜集、分析、存储数据三大功能，也就是说一切的日志分析都是由 ES 来完成的。
图 5. ES 的优势、不足与适用场景
图 6. ES 的一些技术特点
把别的先搁一边，咱们先来算一笔存储空间的账。
由于 ES 的明细检索功能是依赖完整数据的，所以就需要大量的存储空间，保存的时间轴越久，空间就越大。单就缓存中间件来说，每天的 PV 总量 > 1 亿，高峰期更是惊人。如果想存储这些日志，每天至少需要 40G 的存储空间，如果想分析 30 天就需要 1.2T，再算上硬盘阵列 Raid5，一个月至少需要占用 1.8T 空间。
然而，这只是缓存中间件系统的需求，再加上其他中间件及应用线，真是杯水车薪。
因此，我们只能勉强满足 3 天以内的使用量，面对与日俱增的需求，水涨船高的业务，显然不是长久之计。
图 7. ES 的硬件资源
为什么选择 Apache Kylin？
因一次偶然的机会，我们接触到 Apache Kylin，在一番短暂的学习之后，觉得这正是我们所寻找的。
图 8. Kylin 的优势、不足与适用场景
图 9. Kylin 的一些技术特点
当然，技术不是算卦，或者是一拍大腿的买卖，加之我的性格更偏向行动性，找几个场景开动起来，或许会有更多的收获。
随着对 Kylin 研究的深入，我们发现它不仅可以满足我们的需求，并且相比 ELK 还有很多方面的优势。
存储空间的优势
对我们这种体量说大不大，说小不小，且对成本又极其铭感的场景来说，最大的诱惑力是存储空间占用的非常的少，因为只保留计算的结果。
以计算了 10 天 12 亿多条的数据来举例，只需占用了不到 20MB 的存储空间，而原来 ELK 保存这些日志数据需要 400G。
图 10. Kylin - 某结果集大小快照
查询速度的优势
因为采用预计算技术，所以几乎所有的查询都是亚秒级响应。
但由于尝试的业务场景更偏离线分析，所以对这块暂时并不特别关注。
图 11. Kylin - 对某结果集的查询速度
技术栈比较深
由于大数据对技术深度要求高（比如 hadoop 生态圈），而且对技术人员的经验和阅历的要求也不低，因此，相对应的拉高了对特定人才的需求。
不仅如此，ELK 部署简单，操作简便，学习成本低。而大数据技术那么热门，面对这种说高不高，说低不低的技术场景，太好的人才则不愿来，培养起来的人才又留不住。
毕竟人这东西，是世界上最难管的物件。
图 12. Hadoop 生态与 Kylin
图 13. Kylin 的整体架构
更适合离现场景，实时场景欠佳
虽然 Kylin 有很多第三方插件，支持类似 Spark 这样的实时计算解决方案，但对于特定人才的要求就会更高，这也是我们无法应对的。
如果同样采用定时间隔触发这样的手段，Kylin 的实时性却没有 ELK 高，只能满足分钟级这样的场景。
对于实时性要求较高的监控需求，显然是不合适的。
图 14. Kylin 的插件式架构
开源的不够友好，商业的成本太高
既然是开源项目，Kylin 的错误显示与流程操作显然还不够友好，排错也比较困难。
当然，Kyligence 提供的基于 Apache Kylin 的企业级大数据智能分析平台，可以满足几乎所有的场景，可以说是终极解决方案。
但对于我们现在的成本状况，显然就更不合适了。
基于 Apache Kylin 的阶段性成果
经过几个月的努力，基于 Kylin 的相关分析业务已经陆续上线。
为了不对其它业务造成影响（主要是存储池和算力池），我们把 Kylin 单独部署在一台独立的 PC 服务器上。
图 15. 虚拟化节点划分
1、分布式调度系统的线程控制
2、分布式调度系统的执行耗时趋势
3、分布式调度系统的执行计划
4、分布式缓存（A 组代理层）的流量趋势（每分钟）
5、分布式缓存（A 组客户端）的流量趋势（每分钟）
这些指标已在生产环境正常运行了 100 天以上，目前运行状态良好。
此外，调度系统更是利用 ECharts 把监控集成到了调度控制台中，不仅彻底解决了存储空间有限，无法长期分析的问题，在对 cpu 和内存的依赖上也降低很多。
写在最后
也许有人会觉得，如果类似需求出现在他们公司，完全不需要用这样笨重的技术栈加以实现，写俩脚本，搞俩命令行就能搞定，这纯属没事找事。
总的来说，使用 Apache Kylin 的确存在 “为了技术而技术” 的嫌疑，毕竟中小型公司更愿意选择 “ELK+脚本” 这样轻量级的解决方案。
但在我看来，在成本受限的大背景下，与其认命，还不如选择探索，只要满足节省成本的前提下，追求功能探索与技术渴望，又何尝不是一种选择呢？
再说了，局部性尝试而已，就算失败，也是一种成长。
难道不是吗？
本文转载自头哥侃码公众号。
原文链接：https://mp.weixin.qq.com/s/6zW5d1clPmE_zMRASJL-mA
分布式云行业实践指南（2023）
业内首个分布式云行业实践方法论、工具箱。
评论