知識星球
題圖： 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+指令碼” 這樣輕量級的解決方案。
但在我看來，在成本受限的大背景下，與其認命，還不如選擇探索，只要滿足節省成本的前提下，追求功能探索與技術渴望，又何嘗不是一種選擇呢？
再說了，區域性性嘗試而已，就算失敗，也是一種成長。
難道不是嗎？
轉載自：吃草的羅漢
