普元雲計算-微服務來了，監控怎麼辦？

轉載本文需註明出處：EAII企業架構創新研究院，違者必究。如需加入微信羣參與微課堂、架構設計與討論直播請直接回復公衆號：「EAII企業架構創新研究院」。（微信號：eaworld）

 

設想今天是個愉快的週末，天氣很好，你帶着孩子在公園閒逛，這時候，一條短信來了：

 

 

瞬間整我的都很差了，到底怎麼回事，上面的業務有沒有預警，趕忙把相關人召集一下，最好趕忙去下公司吧！也許這時候你會想：能不能有些智能監控手段，給我看到我最想要的信息，這種模棱兩可的信息，只會讓人心情變差。

 

 

回到主題，如今只要說微服務，必須先說單塊應用了，那單塊應用架構下，監控都怎麼作呢？這是一個非0即1的問題，若是宿主服務器指標一切正常，那就是單塊應用出問題了。對於宿主服務器的監控技術也算蠻成熟，好比Nagios、Zabbix；而對於應用的監控，主要經過應用服務器的管理平臺，或者直接上去拿應用日誌就能夠了。

隨着微服務愈來愈多的被採用，之前是單個服務器+單個服務，如今轉變成是多個服務器+多個服務的模式了，出現一個異常，如何快速找出問題根源，顯然對監控能力的要求更高了：

 

· 分散在各處的日誌怎麼辦？

 

· 是某個宿主服務器的問題？仍是某個服務的問題？

 

· 不管是服務仍是服務器問題，影響鏈有哪些？

 

· ……

 

固然，前面一直在拿故障定位舉例，但監控可不是隻爲了故障定位，通常監控目標無非下面幾種：

 

· 事故預警：好比基於閥值對比的實時的事件告警等

 

· 故障定位：好比靜態點的異常日誌收集等

 

· 優化決策：好比用戶行爲數據分析，發現瓶頸等

 

不管是上述的哪一個目標，又或是微服務帶來的諸多難點，有同樣東西是一直沒有變的，那就是來源，要麼是落地日誌、要麼是硬件設備或系統信息、要麼就是一堆自定義的程序埋點（固然也能夠把日誌做爲埋點的一種實現方式）。只是在微服務架構下，信息收集後你須要的處理動做（關聯、合併、過濾、去重等等）更多更復雜了，咱們能夠想一想一些實際的應用場景：

 

1. 微服務的日誌收集場景，假設如今我是一個平臺的運維人員，我確定不但願登到每臺宿主服務器上去看各類日誌，最好是把日誌都收集到一塊兒展示，而後作後續的分析挖掘，基本流程以下圖所示：

 

 

從左至右，先是從宿主服務器上去收日誌，緊接着是一個管道，負責數據傳輸，接着數據被分流，部分進了存儲系統，好比ElasticSearch、Hadoop，部分進了實時系統，好比storm、esper，再往右就很明瞭了。這個架構已經被不少的互聯網公司應用，我所知道的淘寶、噹噹、美團等都是這個基礎架構。但這個架構設計中有幾個點值得你們關注：

 

· 管道除了傳輸，還有不少能力，最經常使用的是簡單預處理和數據緩衝（好比不少架構裏用到了kafka）

 

· 傳輸能夠是多級，通常來講規模大到必定程度，數據往一個點的海量匯聚很容易出問題，分級處理是個很好的方式

 

· 日誌收集方式儘可能統一，不少設計裏對於業務日誌、容器日誌（如docker）、宿主機日誌等採用不一樣agent，這是一個很差的設計方式，agent也要管理，引入太多agent只會給本身增長沒必要要的麻煩

 

2. 行爲數據分析場景，不少創業公司都在關注這塊，一個經常使用的方式就是基於埋點，通常埋點可分爲前端（終端）和服務端兩種，二者各有利弊：好比前端的好處在於可獲取更豐富的界面操做信息，從而指導界面UI（如佈局）的演進，而其最大的問題在於採集數據的傳輸對網絡要求較高（通常採用批量方式）。微服務架構下，基於埋點的被統計進程變得愈來愈多，好比服務健康檢查這類，既要有點，又要有鏈。埋點的設計裏有幾點經驗供你們參考：

 

· 均可以作到的前提下，後端採集是首選

 

· 前端採集儘可能採用框架進行埋點，不要處處插入自定義代碼（框架的作法其實不復雜，好比web端，用過相似selenium這些框架天然就清楚原理了）

 

· 埋點很難作到語言無關性，尤爲後端埋點，微服務架構下，儘可能結合各微服務語言特徵來實現

 

3. 系統性能跟蹤場景，這個其實倒和傳統架構下的方案相似，好比經過協議採集系統的CPU、內存、磁盤IO等，進而分主題入指標庫。不過像咱們採用容器來承載微服務的作法，比起傳統架構來講，須要採的系統信息更多了，好比容器的性能信息，同時在建立性能相關的主題時，數據的關聯性也顯然更復雜了。

 

一樣有些經驗你們可參考：

 

· 指標庫的選型通常會採用一些內存計算框架，對於主題的設計和優化要充分考慮內存容量。

 

· 不管容器、虛機、物理機，性能數據採集都面臨着窗口的問題，通常是兩個窗口（多長時間採集一次和採集的數據是多長時間的數據平均值），需結合業務設置合理值。

 

· 還有一點，包括上述的兩個場景也都要注意，就是採集器自己對宿主機的性能影響，需儘可能降到最低。

 

前面從技術或業務架構上談監控，除此以外，微服務架構下，在作監控設計時，還有一項重要因素：人（PS：我不是要說康威定律），前面有一句話，不知道你們有沒有在乎，「給我看到我最想要的信息」，「我」很重要，我能夠是不少角色，即便是同一個微服務，不一樣的角色對於想看到的信息均可能是不同的，結合角色考慮，每每在微服務架構中能夠給咱們的設計留有很大優化空間，舉個例子：

 

咱們曾經在一個項目中採集性能信息，後端的指標庫用了influxDB，存儲虛擬機的各性能數據，每次採集信息做爲某時間點的一條完整記錄（默認是1分鐘採集一次），中間架了緩衝（kafka），而後由處理器訂閱，並對一批數據向InfluxDB作批量插入，示意圖以下：

 

 

咱們一開始認爲這就能夠了，後面基於類sql語句和內置函數徹底就能夠獲得想要的信息了。好比天天的性能曲線，能夠將一天的數據經過mean計算出24個點，而每月的時間曲線，能夠將一個月的數據計算出30個點。咱們就這麼傻呵呵的把數據持續積累着（要求半年），直到一段時間後，發現撐不住了，怎麼辦呢？咱們回過頭來，看看實際上不一樣的角色要什麼信息？他們是怎麼消費數據的？

 

· 決策者：最關注的是這周或這個月比前段週期負載增長或下降了多少，給他的只需是個數字對比結果，明細數據根本不重要，最多他但願能對比到半年前便可

 

· 運維人員：運維人員其實對數據實時性要求很高，他們根本不在意幾個月前的數據，只要能看到最近時間的數據有沒有問題便可

 

這麼一考慮，那優化方式其實就不少，詳細數據雖然須要存檔，但徹底可不放在時序庫中，針對決策者，數據按每週或每個月彙總再存入線性指標庫便可（influxdb continuous queries）；而針對運維人員，數據駐留內存週期可大幅縮短。

 

總的來講，在微服務架構下，監控確實變得愈來愈複雜，但不管怎麼複雜，咱們都時刻須要結合業務須要和角色識別，來進行監控方案的設計與優化。

 

最後給你們分享下咱們目前平臺中使用的一些技術棧：

 

·日誌收集的需求，由於咱們是基於容器技術的，使用的CoreOS系統，最終咱們採用了Journald+Fluentd+ElasticSearch的技術（業務日誌亦是如此），簡單場景下，ELK、Flume等其實就足夠了，咱們在一些小項目中實踐過。而實時分析系統部分，你們可選擇akka、或者esper、或者storm做爲實現框架，akka經過actor模型實現信息流轉，esper咱們是用來作CEP產品的，storm就不用多說了。

 

 

·對於埋點的一些需求，你們可參考java的Metrics項目，或者Netflix的Suro項目，都是java實現，前者簡單，後者則考慮更周全。

 

·對於性能指標的一些需求，influxdb可做爲後端存儲（不過influxdb的版本間兼容性作的很通常），你們儘量使用最新版本，還有opentsdb，有朋友推薦過，不過畢竟是基於HBase的，比較重，你們有興趣可嘗試。

 

關於做者：

顧偉

EAII-企業架構創新研究院 專家委員

現任普元軟件產品部主任架構師，前後參與華爲，中信銀行，工商銀行，中航信，阿里雲，興業銀行等客戶定製項目。擅長OSGI，eclipse插件，web前端，雲計算，CI/CD等領域技術，對新技術有着濃厚的興趣。

 

關於EAII

EAII（Enterprise Architecture Innovation Institute）企業架構創新研究院，致力於軟件架構創新與實踐，加速企業數字化轉型。

 

eaworld項目（微信號：eaworld，長按二維碼關注）

eaworld是EAII的官方微信帳號。