1. 程式人生 > >Dubbo 整合 Pinpoint 做分散式服務請求跟蹤

Dubbo 整合 Pinpoint 做分散式服務請求跟蹤

在使用Dubbo進行服務化或者整合應用後,假設某個服務後臺日誌顯示有異常,這個服務又被多個應用呼叫的情況下,我們通常很難判斷是哪個應用呼叫的,問題的起因是什麼,因此我們需要一套分散式跟蹤系統來快速定位問題,Pinpoint可以幫助我們快速定位問題(當然,解決方案也不止這一種)。

什麼是Pinpoint

Pinpoint是一個開源的 APM (Application Performance Management/應用效能管理)工具,用於基於java的大規模分散式系統。 仿照Google Dapper,Pinpoint通過跟蹤分散式應用之間的呼叫來提供解決方案,以幫助分析系統的總體結構和內部模組之間如何相互聯絡。

注:對於各個模組之間的通訊英文原文中用的是transaction一詞,但是我覺得如果翻譯為”事務”容易引起誤解,所以替換為”互動”或者”呼叫”這種比較直白的字眼。

Pinpoint是一個分析大型分散式系統的平臺,提供解決方案來處理海量跟蹤資料。2012年七月開始開發,2015年1月9日作為開源專案啟動。

伺服器地圖

ServerMap

通過視覺化分散式系統的模組和他們之間的相互聯絡來理解系統拓撲。點選某個節點會展示這個模組的詳情,比如它當前的狀態和請求數量。

實時活動執行緒圖表

Realtime Active Thread Chart

實時監控應用內部的活動執行緒。

請求/應答分佈圖表

Request/Response Scatter Chart

長期視覺化請求數量和應答模式來定位潛在問題。通過在圖表上拉拽可以選擇請求檢視更多的詳細資訊。

呼叫棧

CallStack

在分散式環境中為每個呼叫生成程式碼級別的可檢視,在單個檢視中定位瓶頸和失敗點。

巡查

Inspector

檢視應用上的其他詳細資訊,比如CPU使用率,記憶體/垃圾回收,TPS,和JVM引數。

支援模組

  • 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(嵌入式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

部署

本次基礎環境搭建我就不講了,如不會,請自行搜尋或者參考我部落格文章https://www.souyunku.com
- 說下我的測試環境:hadoop-2.7.4 叢集,hbase-1.3.1 叢集,zookeeper-3.4.9 單機,一共四臺機器
- 為避免部分埠不通等可疑問題, 建議關閉防火牆

下載

wget https://github.com/naver/pinpoint/releases/download/1.7.3/pinpoint-agent-1.7.3.tar.gz
wget https://github.com/naver/pinpoint/releases/download/1.7.3/pinpoint-collector-1.7.3.war
wget https://github.com/naver/pinpoint/releases/download/1.7.3/pinpoint-web-1.7.3.war

wget https://mirrors.tuna.tsinghua.edu.cn/apache/hbase/1.4.5/hbase-1.4.5-bin.tar.gz

準備環境

  1. 配置 JDK 環境 (筆者使用 Oracle 1.8, openJdk 可以)
  2. 搭建 Zookeeper 環境
  3. 搭建 Hbase (單節點即可)
  4. 在 Hbase/bin 下執行 ./hbase shell hbase-create.hbase 建立相關儲存結構
  5. 準備 Tomcat 環境
  6. 準備可分散式部署的專案用於測試

修改 Pinpoint

pinpoint-collector-1.7.3.war

修改 WEB-INF\classes\hbase.properties 檔案
hbase.client.host 設定為 hbase 所用的 zk 地址

修改 WEB-INF\classes\pinpoint-collector.properties 檔案
cluster.zookeeper.address 修改為給 Pinpoint 準備的 zk 地址

pinpoint-web-1.7.3.war

修改 WEB-INF\classes\hbase.properties 檔案
hbase.client.host 設定為 hbase 所用的 zk 地址

修改 WEB-INF\classes\pinpoint-web.properties 檔案
cluster.zookeeper.address 修改為給 Pinpoint 準備的 zk 地址

部署 collector 和 web

  1. 將準備好的 tomcat 中 webapps 目錄清空
  2. 將上一步修好的兩個 war 包放置到 webapps
  3. pinpoint-web-1.7.3.war 修改為 ROOT.war
  4. pinpoint-collector-1.7.3.war 修改為 collector.war
  5. 啟動 Tomcat

檢視 tomcat/logs 下的日誌, 注意觀察有沒有連線不到 2181 埠的日誌, 如果有, 可能是 war 中的配置沒有修改正確, 建議清空 tomcat 下 work、temp 資料夾後重試

部署 agent

  • 安裝agent,不需要修改哪怕一行程式碼
  • Pinpoint對效能的影響最小(資源使用量增加約3%)

    1. 將 pinpoint-agent-1.7.3.tar.gz 解壓,
    2. 把 pinpoint.config 檔案中 profiler.collector.ip 屬性值修改為部署 collector 機器的主機名或 IP

注意: 每個專案所在的伺服器都需要部署 agent

準備Dubbo示例程式

配置 application.properties,修改地址 zookeeper.connect=127.0.0.1:2181 為自己的zk

mvn clean package

修改自己專案的啟動引數

需要新增三個啟動引數

-javaagent: 指向 agent 目錄下的 pinpoint-bootstrap-1.7.3.jar
-Dpinpoint.agentId:設定全域性唯一標示 ID
-Dpinpoint.applicationName: 設定專案的名稱(如果同一專案部署兩臺例項,這兩臺的引數應該一致)

Tomcat 和 Jar 專案有不同的新增方式,可參考如下方式修改

Tomcat

找到 bin/catalina.sh 新增下面的程式碼

CATALINA_OPTS="$CATALINA_OPTS -javaagent:$AGENT_PATH/pinpoint-bootstrap-1.7.3.jar"
CATALINA_OPTS="$CATALINA_OPTS -Dpinpoint.agentId=tomcat1"
CATALINA_OPTS="$CATALINA_OPTS -Dpinpoint.applicationName=webcontroller"

SpringBoot

# DUBBO 提供者
java -javaagent:/opt/pinpoint-bootstrap-1.7.3.jar -Dpinpoint.agentId=dubbo-provider-1 -Dpinpoint.applicationName=dubbo-provider -jar dubbo-provider-1.0-SNAPSHOT.jar

# DUBBO 消費者
java -javaagent:/opt/pinpoint-bootstrap-1.7.3.jar -Dpinpoint.agentId=dubbo-consumer-1 -Dpinpoint.applicationName=dubbo-consumer -jar dubbo-consumer-1.0-SNAPSHOT.jar

在自己的專案新增完畢啟動後,即可登入 web 後臺檢視叢集的狀態, 跟蹤請求

測試

訪問消費方地址模擬使用者請求

http://localhost:8080/sayHello?name=souyunku

截圖

首頁

指定時間點的,選中區域的請求明細


請求響應明細和系統拓撲

檢視中定位瓶頸和失敗點


消費者機器的, CPU使用率,記憶體/垃圾回收,TPS,和JVM引數

參考:

Contact

關注公眾號-搜雲庫