分散式系統之後，系統變的錯綜複雜，一般很難全盤理解整個系統，並且錯誤比較難定位，需要有呼叫鏈監控，快速的幫我們定位監控問題，瞭解微服務體系。
如果沒有應用監控：
- 線上釋出了服務，怎麼知道一切正常
- 大量報錯，到底是哪裡產生的，誰才是原因
- 人工配置錯誤，通宵排查，勞民傷財
- 資料庫問題，在出問題之前能洞察嗎
任何可能出錯的地方都會出錯，微服務需要應用監控 —— 康威定律
如何儘早的發現問題？
-
實踐1：要提升，必先能測量。需要給開發人員一把測量反饋的尺子
-
實踐2：誰構建，誰允許，誰監控。運維不知道開發的上下文，理解有限，開發人員自助的話，能更好的提升系統
呼叫鏈監控原理
2010年的時候，谷歌釋出過Dapper的論文，可以讀一下論文。論文地址
- traceid：有的會命名為requestNo，整個呼叫鏈路中的traceid是相同的，這樣可以通過一個traceid找到系統間所有互動過的請求和響應
- spanid：僅僅有traceid，無法精確的得知到底是哪個服務先被呼叫的，哪個服務後被呼叫的，spanid和parentSpanid組合起來就可以表示成一個樹形的呼叫關係。
當系統出錯的時候：
- 把traceid收集到一個集合中，包含請求與響應
- 通過spanid與parentSpanId恢復成樹形呼叫
- 識別超時與出錯的節點，進行標記
- 把上面的資訊與出錯節點資訊展示出來
現在開源的呼叫鏈監控系統：
- Cat，美團點評開源，原型和理念源自ebay的CAL系統 ，我們公司是基於Cat進行改造的。github.com/dianping/ca…
- Zipkin：基於谷歌Dapper論文的開源實現，zipkin.io/
美團點評Cat
介紹可以參考官方文件，提供了監控，報警。
- 報表豐富，有助於從各個角度瞭解系統整理概括
- 便於快速發現和根音問題
- 有助於培養網際網路人的：DevOPS自主和自助的意識，卓越質量意識
- 發現技術債，紅黑榜，效能好系統的放在紅榜，效能差的系統放在黑榜，督促人員優化
使用
這裡顯示的是基於Cat做了一些改造。
報錯大盤
- 快速發現分鐘級異常狀況
- 點進去檢視異常的型別與具體資訊
- 點選異常概要，檢視異常的完整呼叫鏈路，點選發生時間，可以看到異常的方法呼叫鏈
關於報錯大盤的使用，參考我之前的一篇記錄：記一次簡單排錯經歷
效能分析
- 檢視埋點的效能，平均呼叫時長，最大時長，95%的呼叫耗時等，可以快速定位效能波動情況
- 針對某一時刻的呼叫，進行分析。
- 點選某一點時刻的呼叫，可以看到分鐘級的呼叫統計，再對某一個呼叫進行跟蹤可以到上面報錯分析的呼叫鏈。
事件統計
- 對上面效能分析中的服務點進去，檢視具體某些服務都呼叫了多少次
服務關係
檢視某個系統被那些系統呼叫過，我們呼叫了那些系統
某一個服務，可以看到是誰呼叫的
資料庫大盤
檢視某些sql呼叫了多少次，失敗次數，可用率，平均耗時之類的
趨勢大盤
自定義自己想要看的系統的指標，新建的指標會放在個人皮膚中
服務狀態
檢視主機的資訊，CPU，記憶體，網路，JVM，執行緒池，磁碟等資訊，Cat自身不適合做這些監控資訊，對於主機的監控也可以選擇其他的系統。
有時候錯誤也可能出現在磁碟問題上，所以這個也要注意下。
生產實踐
在cat專案的github站點上，它已經做了一些整合好的埋點，整合地址：github.com/dianping/ca…
埋點：
- 跨程式的時候，要把上下文的資訊傳遞下去，比如Http呼叫，可以把呼叫資訊放在Http的Header中。
- Cat埋點是有侵入的，如果不想侵入程式碼的話，可以基於AOP，基於註解做一些埋點
部署：
- 建議採用物理機，做叢集
- 如果長期儲存資料，可以使用HDFS
最後
主要說了為甚需要呼叫鏈監控與呼叫鏈監控的好處，簡單講解了呼叫鏈監控的原理，最後以一個基於Cat的呼叫鏈系統使用做了演示。