全鏈路監控（一）：方案概述

爲何須要監控，在哪些層次上監控，監控什麼

監控是爲複雜的分佈式系統服務的，它收集跨不一樣的應用，不一樣的服務器的系統行爲信息，可經過採樣收集所需的性能指標，幫助分析性能問題，並在指標超過正常值時報警。

全鏈路監控

全鏈路監控的起源

全鏈路監控又名分佈式監控系統，全鏈路追蹤。 目前市面的全鏈路系統基本都是參考Google的Dapper（大規模分佈式系統的跟蹤系統）來作的。 論文

全鏈路監控的思想

APM(Application Performance Management)的核心思想是什麼？ 在應用服務各節點相互調用的時候，從中記錄並傳遞一個應用級別的標記，這個標記能夠用來關聯各個服務節點之間的關係。好比兩個應用服務節點之間使用HTTP做爲傳輸協議的話，那麼這些標記就會被加入到HTTP頭中。可見如何傳遞這些標記是與應用服務節點之間使用的通信協議有關的，經常使用的協議就相對容易加入這些內容，一些按需定製的可能就相對困難些，這一點也直接決定了實現分佈式追蹤系統的難度。 它經過探針自動收集所需的指標，並進行分佈式追蹤。經過這些調用鏈路以及指標，APM會感知應用間關係和服務間關係，並進行相應的指標統計。 如何衡量一個大規模集羣的跟蹤系統的優劣？ 它應該知足低損耗、應用透明的、大範圍部署這三個需求的。

全鏈路監控系統的功能

• web應用過程：分析url調用過程當中性能消耗緣由,抓取超過閾值url的詳細數據
• 數據庫性能：支持多種數據庫類型的監測，定位並追蹤慢SQL語句問題
• 錯誤分析：記錄錯誤發生時的詳細信息，統計應用錯誤率，定位問題具體至代碼行
• 外部API調用：能夠監測全部服務端應用外部調用API的耗時，並進行彙總統計
• 線程剖析：能夠實現生產環境下實時在線的線程剖析,可在運行時瞭解代碼性能
• NoSQL分析：實時監控Memcache, MongoDB，Redis等NoSQL數據庫的性能問題
• JVM性能：實時監控JVM運行狀態，經過圖表展現JVM內存分配狀況、內存使用狀況、垃圾收集信息、類加載數量、JVM 線程信息以及會話信息。
• HTTP 會話：分析每一個應用程序的 HTTP 會話數，包括：活躍、過時、拒絕的會話。

一個比較完整的全鏈路監控系統，一般會包括幾個部分。

• 第一，數據埋點和採集。
• 第二，指標計算。
• 第三，指標存儲、查詢、展示。
• 第四，調用鏈的存儲、查詢、展示。
• 第五，告警、問題定位。
• 第六，自監控。
• 第七，治理。

全鏈路監控系統的解決方案

Pinpoint （開源）

Pinpoint is an open source APM (Application Performance Management) tool for large-scale distributed systems written in Java. Pinpoint等相關工具的做用就是追蹤每一個請求的完整調用鏈路，收集調用鏈路上每一個服務的性能數據對代碼的零侵入，運用JavaAgent字節碼加強技術，只須要加啓動參數便可

* Pinpoint-Collector：收集各類性能數據
* Pinpoint-Agent：和本身運行的應用關聯起來的探針
* Pinpoint-Web：將收集到的數據顯示成WEB網頁形式
* HBase Storage：收集到的數據存到HBase中
複製代碼

SkyWalking （開源）

https://baijiahao.baidu.com/s?id=1585656128092617457&wfr=spider&for=pc skywalaking整體架構分爲三部分

• skywalking-collector：鏈路數據歸集器，數據能夠落地ElasticSearch，單機也能夠落地H2，不推薦，H2僅做爲臨時演示用
• skywalking-web：web可視化平臺，用來展現落地的數據
• skywalking-agent：探針，用來收集和發送數據到歸集器

Zipkin （開源）

https://www.cnblogs.com/zhongpan/p/7506930.html

官網：OpenZipkin · http://zipkin.io/

github地址：https://github.com/openzipkin/zipkin 這個是twitter開源出來的，也是參考Dapper的體系來作的。 Zipkin的java應用端是經過一個叫Brave的組件來實現對應用內部的性能分析數據採集。

Brave的github地址：https://github.com/openzipkin/brave 這個組件經過實現一系列的java攔截器，來作到對http/servlet請求、數據庫訪問的調用過程跟蹤。 而後經過在spring之類的配置文件里加入這些攔截器，完成對java應用的性能數據採集。

CAT （開源）

github地址：https://github.com/dianping/cat 跟蹤的手段，是要在代碼裏硬編碼寫一些「埋點」，也就是侵入式的。 這樣作有利有弊，好處是能夠在本身須要的地方加埋點，比較有針對性；壞處是必須改動現有系統，不少開發團隊不肯意。

其餘監控

普羅米修斯

https://www.cnblogs.com/Leo_wl/p/8143222.html http://blog.csdn.net/j3T9Z7H/article/details/78139771

Prometheus(普羅米修斯)是一個名字很是酷的開源監控系統。它支持多維度的指標數據模型，服務端經過HTTP協議定時拉取數據後，經過靈活的查詢語言，實現監控的目的。 Prometheus 能夠從配置或者用服務發現，去調用各個應用的 metrics 接口，來採集數據，而後存儲在硬盤中，而若是是基礎應用好比數據庫，負載均衡器等，能夠在相關的服務中安裝 Exporters 來提供 metrics 接口供 Prometheus 拉取。 採集到的數據有兩個去向，一個是報警，另外一個是可視化。

Zabbix

zabbix（音同 zæbix）是一個基於WEB界面的提供分佈式系統監視以及網絡監視功能的企業級的開源解決方案。 zabbix能監視各類網絡參數，保證服務器系統的安全運營；並提供靈活的通知機制以讓系統管理員快速定位/解決存在的各類問題。 zabbix由2部分構成，zabbix server與可選組件zabbix agent。 zabbix server能夠經過SNMP，zabbix agent，ping，端口監視等方法提供對遠程服務器/網絡狀態的監視，數據收集等功能，它能夠運行在Linux，Solaris，HP-UX，AIX，Free BSD，Open BSD，OS X等平臺上。

Consul 和 Zookeeper

Consul 是 HashiCorp 公司推出的開源工具，用於實現分佈式系統的服務發現與配置，內置了服務註冊與發現，具備健康檢查、Key/Value存儲、多數據中心的功能。

健康檢查

What is the Health Check

Health Check（健康狀態檢查）不只是對本身應用程序內部檢測各個項目之間的健康狀態（各項目的運行狀況、項目之間的鏈接狀況等），還包括了應用程序對外部或者第三方依賴庫的狀態檢測。
複製代碼

Why use Health Check

如今咱們的項目愈來愈多的從單體多層架構轉換成多項目多層架構即如今流行的微服務架構。
原來咱們的App把各個模塊分層分項目處理，好比Users項目僅僅處理User的一些業務需求，但在整個項目使用的時候，咱們僅僅須要引用其類庫便可，不用擔憂項目與類庫之間的不兼容問題，若是不兼容在編譯期已經會有提示。但現在，業務規模愈來愈龐大的時候，咱們單獨把Users做爲一個service來作，全部一切都在其內部處理，對於外部來講僅僅公開幾個api便可，但與項目之間的鏈接就從單純的物理引用關係轉換成了網絡調用關係。
當咱們架構從單體架構到微服務架構的時候，咱們會發現愈來愈多的引用從物理轉向了網絡，在原來咱們不須要考慮之間是否調用成功，但如今咱們必須考慮進去，網絡因素、服務器因素、其餘因素等都會影響各服務之間的調用，所以Health Check孕育而生，它在微服務架構中是舉足輕重的。
複製代碼

Health Check’s Feathure

Health Check的功能有哪些？在微服務架構中很簡單，就是檢查各services的運行狀態是否正常。在微服務的架構中，全部的一切都是service，db is service,rabbitmq is service,auth is service, shoppingcart is server……咱們的架構可以根據業務需求，橫向的擴容，多個db，多個rabbitmq，多個auth，多個shoppingcart。咱們總結下，微服務架構下的Health Check是經過網絡檢查各services是否正常運行，它的功能是：
複製代碼

• 一、提供外部調用Health Check接口，反饋自身狀態
• 二、檢測相關service狀態是否正常（好比db server，可否鏈接到db，可否打開數據庫等）
• 三、UnHealthly時處理機制

參考資源：

http://bigbully.github.io/Dapper-translation/ http://iamlile.github.io/2017/10/06/apm/ http://www.360doc.com/content/18/0129/10/52429660_726071502.shtml