應用性能監控（APM）

一、主要目標

考慮接入應用性能監控主要想解決如下問題：

• 分佈式鏈路追蹤
• 應用級別性能監控（jvm等）
• 低侵入

二、選型

方案	cat	zipkin	pinpoint	skywalking
依賴	Java 6 7 八、Maven 3+ MySQL 5.6 5.七、Linux 2.6+ hadoop可選	Java 6，7，8 Maven3.2+ rabbitMQ	Java 6，7，8 maven3+ Hbase0.94+	Java 6，7，8 maven3.0+ nodejs zookeeper elasticsearch
實現方式	代碼埋點（攔截器，註解，過濾器等）	攔截請求，發送（HTTP，mq）數據至zipkin服務	java探針，字節碼加強	java探針，字節碼加強
存儲	mysql , hdfs	in-memory ， mysql ， Cassandra ， Elasticsearch	HBase	elasticsearch , H2
jvm監控	不支持	不支持	支持	支持
trace查詢	支持	支持	須要二次開發	支持
stars	5.5k	9.1k	6.5k	4k
侵入	高，須要埋點	高，須要開發	低	低
部署成本	中	中	較高	低

基於對應用盡量的低侵入考慮，以上方案選型優先級pinpoint>skywalking>zipkin>cat。

三、原理

基於咱們的選型，重點關注pinpoint和skywalking。

3.1 google dapper 主流的分佈式調用鏈跟蹤技術大都和google dapper類似。簡單介紹下dapper原理：

span 基本工做單元，一次鏈路調用（能夠是RPC，DB等沒有特定的限制）建立一個span，經過一個64位ID標識它，uuid較爲方便，span中還有其餘的數據，例如描述信息，時間戳，key-value對的（Annotation）tag信息，parent_id等,其中parent-id能夠表示span調用鏈路來源。

上圖說明了span在一次大的跟蹤過程當中是什麼樣的。Dapper記錄了span名稱，以及每一個span的ID和父ID，以重建在一次追蹤過程當中不一樣span之間的關係。若是一個span沒有父ID被稱爲root span。全部span都掛在一個特定的跟蹤上，也共用一個跟蹤id。 trace 相似於 樹結構的Span集合，表示一次完整的跟蹤，從請求到服務器開始，服務器返回response結束，跟蹤每次rpc調用的耗時，存在惟一標識trace_id。好比：你運行的分佈式大數據存儲一次Trace就由你的一次請求組成。

每種顏色的note標註了一個span，一條鏈路經過TraceId惟一標識，Span標識發起的請求信息。樹節點是整個架構的基本單元，而每個節點又是對span的引用。節點之間的連線表示的span和它的父span直接的關係。

總體部署結構：

• 經過AGENT生成調用鏈日誌。
• 經過logstash採集日誌到kafka。
• kafka負責提供數據給下游消費。
• storm計算匯聚指標結果並落到es。
• storm抽取trace數據並落到es，這是爲了提供比較複雜的查詢。好比經過時間維度查詢調用鏈，能夠很快查詢出全部符合的traceID，根據這些traceID再去 Hbase 查數據就快了。
• logstash將kafka原始數據拉取到hbase中。hbase的rowkey爲traceID，根據traceID查詢是很快的。

3.2 pinpoint

3.3 skywalking

以上幾種方案數據採集端都採用了字節碼加強技術，原理以下：

在類加載的過程當中，執行main方法前，會先執行premain方法來加載各類監控插件，從而在運行時實現整個鏈路的監控。

四、部署

下面重點介紹pinpoint部署,目前咱們線上是集羣部署，總體架構以下：

機器	部署應用
master	zookeeper,hadoop,hbase,pinpoint-collector
node1	zookeeper,hadoop,hbase
node2	zookeeper,nginx,hadoop,hbase,pinpoint-web,pinpoint-collector

搭建pinpoint線上用了三臺服務器,master、node一、node2。應用數據採集端agent-client將採集到的數據經過udp發送到部署在node2的nginx,經過負載均衡分流到兩臺pinpoint-collector服務器，落庫經過hadoop集羣master節點負載均衡到兩臺hbase服務器上。

4.1 編譯

pinpoint編譯條件比較苛刻，須要jdk6,7,8環境。

4.2 hbase

集羣部署，須要先搭建hadoop集羣，hbase集羣。搭建完成後初始化表，執行 ./hbase shell /pinpoint-1.7.2/hbase/scripts/hbase-create.hbase，能夠根據本身對歷史數據的需求設置表的ttl時間。

4.3 pinpoint-web

/pinpoint-1.7.2/web/target/pinpoint-web-1.7.2.war拷貝到tomcat webapps目錄下 修改tomcat目錄/webapps/pinpoint-web-1.7.2/WEB-INF/classes/hbase.properties hbase配置啓動

4.4 pinpoint-collector

/pinpoint-1.7.2/collector/target/pinpoint-collector-1.7.2.war拷貝到tomcat webapps目錄下，修改tomcat目錄/webapps/pinpoint-collector-1.7.2/WEB-INF/classes/hbase.properties和pinpoint-collector.properties配置並啓動

4.5 agent

將/pinpoint-1.7.2/agent整個目錄拷貝到應用服務器指定目錄下修改/agent/target/pinpoint-agent-1.7.2/pinpoint.config配置業務應用啓動時增長參數-javaagent:/root/agent/target/pinpoint-agent-1.7.2/pinpoint-bootstrap-1.7.2.jar -Dpinpoint.agentId=application01 -Dpinpoint.applicationName=application

具體集羣部署能夠參考： blog.csdn.net/yue530tomto…

須要注意： 默認配置的日誌級別是DEBUG,會產生海量日誌，要將其修改爲INFO級別

五、功能簡介

首頁能看到應用的拓撲信息，接口調用的成功失敗數，響應時間等。

能夠查看具體的某一次請求的整個調用鏈路信息

能夠查看jvm相關信息

針對某個慢請求，咱們能夠經過pinpoint跟蹤整個調用鏈，從而定位慢在哪裏。