應用監控預警&服務鏈路跟蹤-Pinpoint介紹

需求背景

1，在分佈式環境中，服務調用服務愈來愈頻繁，當你想跟蹤一次請求錯誤來源或者哪一個api步驟緩慢時，估計你想到的是，每一個服務裏面打印日誌，並且帶上本應用裏面的先後耗時，全局惟一的跟蹤id，而後把這個全局跟蹤Id傳遞到下一個被調用的應用中去，這樣才能根據這個全局跟蹤Id，查詢從網關開始到多個交易系統的服務器上的日誌。看起來是否是很繁瑣？有沒有工具幫你搞定？

2，生產上常常出現JVM 內存溢出OOM的狀況或者鏈接池不夠用致使接口緩慢，有沒有想過監控你的應用jvm的內存和數據庫鏈接數，並且當他們的值超過必定閾值的時候進行告警，發送短信給你，讓你提早處理這些危機？而不是過後被客戶反映出問題？有沒有工具幫你搞定這個事情？

3，應用這麼多？我如何知道當前哪些應用之間存在調用關係？最好是來個拓撲圖來展現！

4，個人應用有多個實例部署，能不能把這個應用幾個實例的監控數據歸集起來，讓我對整個應用的綜合狀況（接口響應時間，數據庫鏈接數使用狀況，內存使用，目前活動的調用事務數等）有個全局的瞭解？

 

分佈式系統和監控告警系統發展到目前，已經有不少大公司走在了前面，並且爲咱們這些中小公司貢獻了大量的開源系統，pinpoint是一款很是優秀的應用性能監控工具，對比skywalking和cat,zipkin等，綜合功能上更勝一籌，系統性能，可用性，擴展性，易用性，維護性方面都很是棒。

 

pinpoint部署架構

 

 

 

pinpoint1.7.3重要特性

易用性

a,無需應用修改任何應用代碼，輕鬆集成。採用Java字節碼加強技術，自動注入跟蹤代碼到你的應用中。

zipkin和cat都是須要本身配置插件到你的代碼中，有的須要本身寫跟蹤代碼。skywalking採用字節碼加強技術。

b,支持衆多框架，中間件的跟蹤

• JDK 6+
• Tomcat 6/7/8, Jetty 8/9, JBoss EAP 6, Resin 4, Websphere 6/7/8, Vertx 3.3/3.4/3.5
• Spring, Spring Boot (Embedded Tomcat, Jetty)
• Apache HTTP Client 3.x/4.x, JDK HttpConnector, GoogleHttpClient, OkHttpClient, NingAsyncHttpClient
• Thrift Client, Thrift Service, DUBBO PROVIDER, DUBBO CONSUMER
• ActiveMQ, RabbitMQ
• MySQL, Oracle, MSSQL, CUBRID, POSTGRESQL, MARIA
• Arcus, Memcached, Redis, CASSANDRA
• iBATIS, MyBatis
• DBCP, DBCP2, HIKARICP
• gson, Jackson, Json Lib
• log4j, Logback

只須要修改pinpontagent配置文件，便可實現上面這些框架的方法跟蹤，zipkin跟spring cloud整合只能跟蹤到不多部分方法的耗時，cat須要本身寫跟蹤代碼。skywalking支持上述框架跟蹤，這點作的比pinpoint還多。

c，強大的應用拓撲圖，監控數據走勢圖（包括單jvm和應用集羣走勢），調用鏈路展現圖（包括你的sql,調用者Ip,每一個函數的耗時），告警規則配置。

skywaling5目前不支持告警，集羣監控數據走勢圖；zipkin只有調用鏈路展現；cat展現圖標聽說豐富，沒具體使用過。

 

高性能（從設計上對比）

傳輸：pinpoint使用udp,tcp上送數據，採用thirft序列化數據，性能作了優化；skywalking採用grpc和rest兩種方式上送數據，本質上是http協議；zipkin使用Http發送數據。udp和tcp性能優於http實現。

存儲：pinpoint使用hbase寫入，作了分區和數據老化設置，能充分享受hbase分佈式寫入併發的能力。skywalking使用elasticsearch存儲，zipkin支持Cassandra,MySQL，寫入性能上hbase介於Cassandra和elasticsearch之間，hbase跟cassandra相差不大，二者比elasticsearch寫入快不少倍；查詢上elasticsearch要優於hbase。

pinpoint使用flink預統計數據來優化查詢性能，flink做爲目前最早進的流式處理框架，性能優秀，一致性保證，輕量級容錯。

skywalking使用storm/spark stream來作統計，不過此功能在5版本中拿掉了。

綜合對比，pinpoint的寫入性能優秀，查詢性能尚可。

 

擴展性

從設計上能夠看出，部署多個collector是能夠線性擴容的，存儲方面Hbase的擴展性很是好，並且hbase本身作數據清理。

 

維護性

pinpoint提供完整的數據庫維護腳本，包括建立hbase表和清除hbase表。發現數據空間不夠使用了，可隨時使用清除Hbase表的腳本進行清理，再使用建立腳本進行恢復表結構。

 

可用性

在任何狀況下，你關閉collector或者hbase，都不影響咱們的業務應用的正常使用。

 

Pinpoint WEB UI操做指南

若是你們英文ok，請直接訪問http://naver.github.io/pinpoint/1.7.3/main.html；不須要聽我繼續了

若是不是很好，下面會對UI上的經常使用功能作介紹。

首頁操做

 

首頁上面能夠選擇一個應用進行查看拓撲圖，拓撲的深度，時間範圍過濾，只有在特色時間範圍的應用之間發生調用了，纔會出如今應用拓撲圖中。

 

在拓撲圖中點擊一個應用，在右邊會顯示這個應用的api調用響應時間狀況，使用鼠標點擊，畫出一個方框，就能夠把方框裏面rpc的鏈路展現在新的頁面中。

 

 

 

鏈路展現，能夠查看到調用鏈上的耗時，調用的api，Ip地址，執行的sql語句等。

 

應用監控

從首頁點擊Inspector進去，展現當前應用集羣的監控走勢圖，也能夠單獨看一個實例的走勢。

 

應用告警設置

在首頁拓撲圖，或者應用監控頁面，點擊右上角的齒輪圖標，便可打開告警設置界面

設置告警消息發送的用戶：

 

設置告警規則，監控的應用，監控的指標超過某個閾值，發送什麼類型的消息，發送給哪一個用戶組

 

 

 

告警規則

• SLOW COUNT / 慢請求數

  當應用發出的慢請求數量超過配置閾值時觸發。

• SLOW RATE / 慢請求比例

  當應用發出的慢請求百分比超過配置閾值時觸發。

• ERROR COUNT / 請求失敗數

  當應用發出的失敗請求數量超過配置閾值時觸發。

• ERROR RATE / 請求失敗率

  當應用發出的失敗請求百分比超過配置閾值時觸發。

• TOTAL COUNT / 總數量

  當應用發出的全部請求數量超過配置閾值時觸發。

以上規則中，請求是當前應用發送出去的，當前應用是請求的發起者。 如下規則中，請求是發送給當前應用的，當前應用是請求的接收者。

• SLOW COUNT TO CALLEE / 被調用的慢請求數量

  當發送給應用的慢請求數量超過配置閾值時觸發。

• SLOW RATE TO CALLEE / 被調用的慢請求比例

  當發送給應用的慢請求百分比超過配置閾值時觸發。

• ERROR COUNT TO CALLEE / 被調用的請求錯誤數

  當發送給應用的請求失敗數量超過配置閾值時觸發。

• ERROR RATE TO CALLEE / 被調用的請求錯誤率

  當發送給應用的請求失敗百分比超過配置閾值時觸發。

• TOTAL COUNT TO CALLEE / 被調用的總數量

  當發送給應用的全部請求數量超過配置閾值時觸發。

下面兩條規則和請求無關，只涉及到應用的狀態

• HEAP USAGE RATE / 堆內存使用率

  當應用的堆內存使用率超過配置閾值時觸發。

• JVM CPU USAGE RATE / JVM CPU使用率

  當應用的CPU使用率超過配置閾值時觸發。