题图： from Zoommy
记得十年前，我曾问过一名应用运维工程师，若何用两个要害词描述下本身的平常工作？
他居然不假思索，略带奚弄的回覆我， “背锅” 与 “惊醒”，立即愣了一下，改口说，“发布” 与 “排障”。
切实，在人肉化运维时代，“你的软件是否支撑傻瓜式运维？” 似乎成为了一种剖断系统可运维能力的尺度，找个应届生，懂点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 - 对某究竟集的查询速度
任何事物总有两面性，在短暂的测验后，也发现了一些Kylin对我们来说的劣势。
| 手艺栈对照深
因为大数据对手艺深度要求高（好比hadoop生态圈），并且对手艺人员的经验和阅历的要求也不低，是以，相对应的拉高了对特定人才的需求。
不光如斯，ELK布置简洁，把持轻便，进修成本低。而大数据手艺那么热点，面临这种说高不高，说低不低的手艺场景，太好的人才则不肯来，培育起来的人才又留不住。
究竟人这器材，是世界上最难管的物件。
图12. Hadoop生态与Kylin
图13. Kylin的整体架构
| 更适合离现场景，实时场景欠佳
固然Kylin有好多第三方插件，支撑雷同Spark如许的实时较量解决方案，但对于特定人才的要求就会更高，这也是我们无法应对的。
若是同样采用准时距离触发如许的手段，Kylin的实时性却没有ELK高，只能知足分钟级如许的场景。
对于实时性要求较高的监控需求，显然是错误适的。
图14. Kylin的插件式架构
| 开源的不敷友好，贸易的成本太高
既然是开源项目，Kylin的错误显露与流程把持显然还不敷友好，排错也对照难题。
当然，Kyligence供应的基于Apache Kylin的企业级大数据智能剖析..，能够知足几乎所有的场景，能够说是最终解决方案。
但对于我们如今的成本状况，显然就更错误适了。
基于Apache Kylin的阶段性功效
经由几个月的起劲，基于Kylin的相关剖析买卖已经陆续上线。
为了纰谬另外买卖造成影响（首要是存储池和算力池），我们把Kylin零丁布置在一台自力的PC办事器上。
图15. 虚拟化节点划分
经由通俗虚拟化手艺，将3台4核8G作为掌握节点，首要用来布置hadoop相关的掌握节点、zookeeper、kafka、mysql等，还有3台8核16G的虚拟机作为较量节点，首要用来跑MapReduce义务。
手艺微立异就是如斯神奇，谁能想到我们居然能在沟通数据量级的前提下，在如许6台虚拟机共用64G内存的情形下，跑出了5项新指标：
1、分布式调剂系统的线程掌握
2、分布式调剂系统的执行耗时趋势
3、分布式调剂系统的执行规划
4、分布式缓存（A组代理层）的流量趋势（每分钟）
5、分布式缓存（A组客户端）的流量趋势（每分钟）
这些指标已在生产情况正常运行了100天以上，今朝运行状况精巧。
此外，调剂系统更是行使ECharts把监控集成到了调剂掌握台中，不光彻底解决了存储空间有限，无法历久剖析的问题，在对cpu和内存的依靠上也降低好多。
写 在 最 后
或许有人会感觉，若是雷同需求显现在他们公司，完全不需要用如许粗笨的手艺栈加以实现，写俩剧本，搞俩号令行就能搞定，这纯属没事谋事。
总的来说，使用Apache Kylin切实存在 “为了手艺而手艺” 的嫌疑，究竟中小型公司更甘愿选择 “ELK+剧本” 如许轻量级的解决方案。
但在我看来，在成本受限的大配景下，与其认命，还不如选择索求，只要知足节约成本的前提下，追求功能索求与手艺盼望，又何尝不是一种选择呢？
再说了，局部性测验罢了，就算失败，也是一种成长。
岂非不是吗？
转载自：吃草的罗汉
