微服務的全鏈路監控

1.什么是全鏈路監控？

在分布式微服務架構中，系統為了接收並處理一個前端用戶請求，需要讓多個微服務應用協同工作，其中的每一個微服務應用都可以用不同的編程語言構建，由不同的團隊開發，並可以通過多個對等的應用實例實現水平擴展，甚至分布在橫跨多個數據中心的數千台服務器上。單個用戶請求會引發不同應用之間產生一串順序性的調用關系，如果要對這些調用關系進行監控，了解每個應用如何調用，這就產生了全鏈路監控。

 

2.為什么要進行全鏈路監控？

在微服務架構中，服務會被拆分成多個模塊，這些模塊可能由不同的開發團隊開發、維護，也可能使用不同的編程語言來實現、也有可能分布在多台服務器上，由於服務的拆分，單個用戶的請求會經過多個微服務，相互之間形成復雜的調用關系，傳統的監控手段已經不能實現如此復雜的鏈路之間的監控了，因此，就需要一些可以幫助理解系統行為、用於分析性能問題的工具，以便發生故障的時候，能夠快速定位和解決問題。

 

3.全鏈路監控能解決哪些問題？

1. 請求鏈路追蹤，故障快速定位：可以通過調用鏈結合業務日志快速定位錯誤信息。

2. 可視化： 各個階段耗時，進行性能分析。

3. 依賴優化：各個調用環節的可用性、梳理服務依賴關系以及優化。

4. 數據分析，優化鏈路：可以得到用戶的行為路徑，匯總分析應用在很多業務場景。

 

4.常見的全鏈路監控工具

4.1 zipkin

github：

https://github.com/openzipkin/zipkin

zipkin是一個分布式的追蹤系統，它能夠幫助你收集服務架構中解決問題需要的時間數據，功能包括收集和查找這些數據。如果日志文件中有跟蹤ID，可以直接跳轉到它。否則，可以根據服務、操作名稱、標記和持續時間等屬性進行查詢。例如在服務中花費的時間百分比，以及哪些環節操作失敗。特點是輕量，使用部署簡單。

zipkin還提供了一個UI界面，它能夠顯示通過每個應用程序的跟蹤請求數。這有助於識別聚合行為，包括錯誤路徑或對不推薦使用的服務的調用。

 

應用程序需要“檢測”才能向Zipkin報告跟蹤數據。這通常意味着需要配置一個用於追蹤和檢測的庫。最流行的向Zipkin報告數據的方法是通過http或Kafka，盡管還有許多其他選項，如apache，activemq、gRPC和RabbitMQ。提供給UI存儲數據的方法很多，如存儲在內存中，或者使用受支持的后端（如apachecassandra或Elasticsearch）持久存儲。

4.2 skywalking

github:  

https://github.com/apache/incubator-skywalking

 

skywalking是本土開源的調用鏈追蹤系統，包括監控、跟蹤、診斷功能，目前已加入Apache孵化器，專門為微服務、雲本地和基於容器（Docker、Kubernetes、Mesos）架構設計。

 

主要功能如下：

 

1）服務、服務實例、端點指標數據分析

2）根本原因分析，在運行時評測代碼

3）服務拓撲圖分析

4）服務、服務實例和端點依賴性分析

5）檢測到慢速服務和終結點

6）性能優化

7）分布式跟蹤和上下文傳播

8）數據庫訪問度量。檢測慢速數據庫訪問語句（包括SQL語句）。

9）報警

10）瀏覽器性能監視

 

4.3 pinpoint

github:

https://github.com/naver/pinpoint

 

pinpoint是韓國人開源的基於字節碼注入的調用鏈分析，以及應用監控分析工具。Pinpoint提供了一個解決方案，可以幫助分析系統的整體結構，以及通過跟蹤分布式應用程序中的事務來分析其中的組件是如何相互連接的。

 

功能如下：

1）一目了然地了解應用程序拓撲

2）實時監視應用程序

3）獲得每個事務的代碼級可見性

4）安裝APM代理程序，無需更改一行代碼

5）對性能的影響最小（資源使用量增加約3%）

 

Pinpoint的可視化UI界面：

 

 

 

4.4 jaeger

https://www.jaegertracing.io

Jaeger 是受 Dapper 和 OpenZipkin 的啟發，由 Uber Technologies 創建的分布式追蹤平台，現已捐贈給雲原生計算基金會。它可用於監視基於微服務的分布式系統：

• 分布式上下文傳播
• 分布式交易監控
• 根本原因分析
• 服務依賴分析
• 性能/延遲優化

Jaeger為何物？

Jaeger 是Uber推出的一款開源分布式追蹤系統，兼容OpenTracing API。分布式追蹤系統用於記錄請求范圍內的信息。例如，一次遠程方法調用的執行過程和耗時。是我們排查系統問題和系統性能的利器。
分布式追蹤系統種類繁多，但是核心步驟有三個：代碼埋點，數據存儲和查詢展示。
以上幾句描述都是我copy的，所以大家想要對Jaeger有更加深入的了解，可以參閱這篇文章Jaeger 分布式追蹤系統模塊分析,能讓你對Jaeger有一個簡單的認識。
當然我們還要記得APM的三大模塊分別是集中式日志系統，集中式度量系統和分布式全鏈接追蹤系統。
而Jaeger屬於的就是追蹤系統，度量系統我們則會使用prometheus,日志系統一般則是elk。

選用Jaeger的原因

一個是它兼容OpenTracing API,寫起來簡單方便，一個是UI相較於Zipkin的更加直觀和豐富，還有一個則是sdk比較豐富，go語言編寫，上傳采用的是udp傳輸，效率高速度快。
相比Pinpoint的缺點，當然是UI差距了，基本上現在流行的追蹤系統UI上都遠遠遜於它

5.全鏈路監控工具對比分析

 

市面上的全鏈路監控理論模型大多都是借鑒Google Dapper論文，本文重點關注以下三種APM組件：

 

APM = ApplicationPerformance Management,中文即應用性能管理

APM三大模塊：集中式日志系統，集中式度量系統和分布式全鏈接追蹤系統

 

1）Zipkin：由Twitter公司開源，開放源代碼分布式的跟蹤系統，用於收集服務的定時數據，以解決微服務架構中的延遲問題，包括：數據的收集、存儲、查找和展現。

2）Pinpoint：一款對Java編寫的大規模分布式系統的APM工具，由韓國人開源的分布式跟蹤組件。

3）Skywalking：國產的優秀APM組件，是一個對JAVA分布式應用程序集群的業務運行情況進行追蹤、告警和分析的系統。

4）Jaeger： uber開發的受Zipkin與docker啟發，ui方面對比zipkin更加完善。

5.1 全面的調用鏈路數據分析

全面的調用鏈路數據分析，提供代碼級別的可見性以便輕松定位失敗點和瓶頸。

 1.zipkin

zipkin的鏈路監控粒度相對沒有那么細，調用鏈中具體到接口級別，再進一步的調用信息並未涉及。

 2.skywalking

skywalking 支持20+的中間件、框架、類庫，比如：主流的dubbo、Okhttp，還有DB和消息中間件。skywalking鏈路調用分析截取的比較簡單，網關調用user服務，由於支持眾多的中間件，所以skywalking鏈路調用分析比zipkin完備些。

3.pinpoint

pinpoint應該是這三種APM組件中，數據分析最為完備的組件。提供代碼級別的可見性以便輕松定位失敗點和瓶頸，上圖可以看到對於執行的sql語句，都進行了記錄。還可以配置報警規則等，設置每個應用對應的負責人，根據配置的規則報警，支持的中間件和框架也比較完備。

 

5.2 Pinpoint與Zipkin細化比較

5.2.1 pinpoint與zipkin差異性

1. Pinpoint 是一個完整的性能監控解決方案，有從探針、收集器、存儲到 Web 界面等全套體系，而Zipkin只側重收集器和存儲服務，雖然也有用戶界面，但其功能與Pinpoint不可同日而語。反而Zipkin提供有Query接口，更強大的用戶界面和系統集成能力，可以基於該接口二次開發實現。

2. Zipkin 官方提供有基於 Finagle 框架（Scala 語言）的接口，而其他框架的接口由社區貢獻，目前可以支持 Java、Scala、Node、Go、Python、Ruby 和 C# 等主流開發語言和框架；但是 Pinpoint 目前只有官方提供的 Java Agent 探針，其他的都在請求社區支援中。

3. Pinpoint 提供有 Java Agent 探針，通過字節碼注入的方式實現調用攔截和數據收集，可以做到真正的代碼無侵入，只需要在啟動服務器的時候添加一些參數，就可以完成探針的部署，而 Zipkin的Java接口實現 Brave，只提供了基本的操作 API，如果需要與框架或者項目集成的話，就需要手動添加配置文件或增加代碼。

4. Pinpoint 的后端存儲基於 Hbase，而 Zipkin 基於 Cassandra。

5.2.2 pinpoint與zipkin相似性

pinpoint與zipkin都是基於Google Dapper的那篇論文，因此理論基礎大致相同。兩者都是將服務調用拆分成若干有級聯關系的Span，通過SpanId和ParentSpanId來進行調用關系的級聯，最后再將整個調用鏈流經的所有的Span匯聚成一個 Trace，報告給服務端的collector進行收集和存儲。

 

即便在這一點上，Pinpoint 所采用的概念也不完全與那篇論文一致。比如他采用 TransactionId 來取代 TraceId，而真正的 TraceId 是一個結構，里面包含了 TransactionId, SpanId 和 ParentSpanId。而且 Pinpoint 在 Span 下面又增加了一個 SpanEvent 結構，用來記錄一個 Span 內部的調用細節（比如具體的方法調用等等），因此 Pinpoint 默認會比 Zipkin 記錄更多的跟蹤數據。但是理論上並沒有限定 Span 的粒度大小，所以一個服務調用可以是一個 Span，那么每個服務中的方法調用也可以是個 Span，這樣的話，其實 Brave 也可以跟蹤到方法調用級別，只是具體實現並沒有這樣做而已。

互動：

 1.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。

Span數據結構：
type Span struct {
    TraceID    int64  #用於標示一次完整的請求id
    Name       string
    ID         int64  #當前這次調用span_id
    ParentID   int64  #上層服務的調用span_id  最上層服務parent_id為null
    Annotation []Annotation  #用於標記的時間戳
    Debug      bool

2. Trace是什么？

類似於 樹結構的Span集合，表示一次完整的跟蹤，從請求到服務器開始，服務器返回response結束，跟蹤每次rpc調用的耗時，存在唯一標識trace_id。比如：你運行的分布式大數據存儲一次Trace就由你的一次請求組成。 

每種顏色的note標注了一個span，一條鏈路通過TraceId唯一標識，Span標識發起的請求信息。樹節點是整個架構的基本單元，而每一個節點又是對span的引用。節點之間的連線表示的span和它的父span直接的關系。雖然span在日志文件中只是簡單的代表span的開始和結束時間，他們在整個樹形結構中卻是相對獨立的。

部署pinpoint服務

安裝docker:
yum install -y docker-ce-19.03.7-3.el7
systemctl enable docker && systemctl start docker
#查看docker狀態，如果狀態是active（running），說明docker是正常運行狀態
systemctl status docker
修改docker配置文件
cat > /etc/docker/daemon.json <<EOF
{
"registry-mirrors":["https://rsbud4vc.mirror.aliyuncs.com","https://registry.docker-cn.com","https://docker.mirrors.ustc.edu.cn","https://dockerhub.azk8s.cn","http://hub-mirror.c.163.com","http://qtid6917.mirror.aliyuncs.com"], 
"exec-opts":["native.cgroupdriver=systemd"],
 "log-driver":"json-file",
 "log-opts": {
  "max-size": "100m"
  },
 "storage-driver":"overlay2",
 "storage-opts": [
  "overlay2.override_kernel_check=true"
  ]
}
EOF


注：
"registry-mirrors":["https://rsbud4vc.mirror.aliyuncs.com","https://registry.docker-cn.com","https://docker.mirrors.ustc.edu.cn","https://dockerhub.azk8s.cn","http://hub-mirror.c.163.com","http://qtid6917.mirror.aliyuncs.com"]
上面配置的是鏡像加速器
cat > /etc/docker/daemon.json <<EOF
{
"insecure-registries":["192.168.0.56"],
"registry-mirrors":["https://rsbud4vc.mirror.aliyuncs.com","https://registry.docker-cn.com","https://docker.mirrors.ustc.edu.cn","https://dockerhub.azk8s.cn","http://hub-mirror.c.163.com","http://qtid6917.mirror.aliyuncs.com"], 
"exec-opts":["native.cgroupdriver=systemd"],
 "log-driver":"json-file",
 "log-opts": {
  "max-size": "100m"
  },
 "storage-driver":"overlay2",
 "storage-opts": [
  "overlay2.override_kernel_check=true"
  ]
}
EOF

"insecure-registries":["192.168.40.132"]  #配置的是harbor私有鏡像倉庫地址

重啟docker使配置生效 
systemctl daemon-reload && systemctl restart docker && systemctl status docker

開啟機器的bridge模式

#臨時生效
echo 1 > /proc/sys/net/bridge/bridge-nf-call-iptables
echo 1 >/proc/sys/net/bridge/bridge-nf-call-ip6tables
#永久生效
echo """
vm.swappiness = 0
net.bridge.bridge-nf-call-iptables = 1
net.ipv4.ip_forward = 1
net.bridge.bridge-nf-call-ip6tables = 1
""" > /etc/sysctl.conf
sysctl -p

pinpoint service部署

github地址：

ttps://github.com/pinpoint-apm/pinpoint-docker.git

unzip pinpoint-docker-2.0.1.zip
cd pinpoint-docker-2.0.1

修改docker-compose.yml文件的version版本，如2.2，變成自己支持的版本

version: "3.6" 變成 version: "2.2"

#拉取鏡像
yum install docker-compose -y

docker-compose pull 

#啟動服務
docker-compose up -d 

#查看對應的服務是否啟動
docker ps | grep pinpoint 

#找到pinpoint-web，可看到在宿主機綁定的端口是8079，

在瀏覽器訪問ip:8079即可訪問pinpoint的web ui界面

部署pinpoint agent

把microservic-test-dev1.zip上傳到k8s的master1節點，解壓：
unzip microservic-test-dev1.zip

下載地址：https://github.com/pinpoint-apm/pinpoint/releases/download/1.8.5/pinpoint-agent-1.8.5.tar.gz

將agent包一並傳入鏡像中 jar包啟動 通過agent代理 

例如：

FROM java:8-jdk-alpine
RUN  apk add -U tzdata && \
     ln -sf /usr/share/zoneinfo/Asia/Shanghai /etc/localtime
COPY ./target/eureka-service.jar ./
COPY pinpoint /pinpoint
EXPOSE 8888
CMD java -jar -javaagent:/pinpoint/pinpoint-bootstrap-1.8.5.jar -Dpinpoint.agentId=${HOSTNAME} -Dpinpoint.applicationName=ms-eureka -Deureka.instance.hostname=${MY_POD_NAME}.eureka.ms /eureka-service.jar