微服務監控探索

weixin_30924079發表於2020-04-04

微服務

微服務監控簡介

作為一種靈活性極強的構架風格，微服務在各種開發專案中日益普及。當開發者從微服務架構獲得敏捷時，觀測整個系統的執行情況成為最大的痛點。
從網路流量分析的角度出發，通過生成各個微服務之間訪問關係的拓撲結構來直觀地觀察整個系統的運作狀況。

監控整體架構

部署

目前各元件部署在測試叢集的容器環境中

elasticsearch
kibana
topology

packetbeat

packetbeat是一個實時網路包分析工具，可以用於應用的監控和效能分析。它對7層協議進行解析，根據requests和responses劃分transactions，對每一個transaction產生一個json文件寫入elasticsearch（通常情況下）。

目前packetbeat相容的協議包括：

HTTP
MySQL
PostgreSQL
Redis
Thrift-RPC
MongoDB
DNS

Memcache

安裝

官方提供的安裝方式

sudo apt-get install libpcap0.8curl -L -O https://download.elastic.co/beats/packetbeat/packetbeat_1.1.1_amd64.deb 
sudo dpkg -i packetbeat_1.1.1_amd64.deb

配置

基本的配置包括網路裝置，輸出（本例是es），各協議埠。配置檔案預設為/etc/packetbeat/packetbeat.yml，最基本的配置示例如下：

interfaces: {device: docker0}output:  elasticsearch:    hosts: ['223.252.222.168:42400']protocols:  dns:    ports: [53]  http:    ports: [8000, 8080]  memcache:    ports: [11211]  mongodb:    ports: [27017]  mysql:    ports: [3306]  pgsql:    ports: [5432]  redis:    ports: [6379]  thrift:    ports: [9090]

抓包方式

packetbeat支援三種抓包方式：

pcap 依賴於libpcap，相容各種平臺，但效能並非最高（預設方式）
af_packet 記憶體對映方式，該方式效能優於pcap並且不依賴核心模組，但是僅限於linux
pf_ring 依賴ntop.org的專案，該方式效能最佳，但是依賴於核心模組且限於linux

執行

/etc/init.d/packetbeat start

packetbeat配置動態修改(ctl_pb)

packetbeat的部署以node為單位，因此需要為其配置該node上所有service的服務埠，然而單個node上執行著多個service的示例，並且由於k8s的排程會動態的建立和銷燬，因此需要動態的修改packetbeat的配置。

ctl_pb.py負責在每個node上動態修改packetbeat的配置，其工作流程大致如下：

初始化k8s_api地址以及docker daemon的api地址
以stream的方式請求docker daemon的watch api，當有容器建立或銷燬時返回該event，並觸發更新配置的操作
根據宿主機的ip用k8s_api獲得該node上所有podip
根據podip獲得該node上所有endpoint的埠
更新packetbeat的配置檔案並重啟packetbeat

topology

整體預覽效果如下：

圖中邊的粗細對應請求數的大小，邊的顏色對應延遲的大小

生成topology的流程大致如下：

初始化完成讀取配置檔案等資訊，包括es地址、k8s_api地址等等
根據宿主機的ip從k8s_api的/pods查詢該node上所有podIP，返回ip-->podname的字典
接受請求or定時重新整理觸發，使用es的search api拉取符合過濾條件（時間週期、協議型別等）的資料，生成拓撲圖必須的節點---nodes[]和邊---links[]的陣列，並計算對應的請求數、平均responsetime等統計資訊
對節點和邊資訊中的ip，若存在ip-->podname的對應關係則轉換為podname
若某ip沒有對應podname，則轉換為查詢DNS返回的hostname
利用得到的nodes[]和links[]渲染模板，生成html
拓撲圖的渲染使用開源JS作相簿Echarts中的力導向圖

Kibana Plugin

為了和更好的結合elk，將topology作為plugin整合到kibana的visualization裡是一個不錯的選擇。然而kibana官方文件只介紹了plugin的安裝，並沒有相關的develop文件...從收集到的民間文件來看，開發plugin存在以下坑：

由於不是官方api，用到的api很可能在下個版本被和諧，意味著對每一個版本的kibana都要調整
plugin安裝的來源限於官方或者github，需要釋出後才能安裝
最關鍵的是，在kibana的官方repo中赫然寫著：

鑑於以上，還是部署了一個kibana的dev模式進行嘗試開發一個Visualization用於展示拓撲結構。一個Visualization plugin的核心主要由template和controller控制，在模板中的div中指定controller用以操作內部變數和邏輯。拓撲圖的實現基於開源js作相簿Echarts，其原理是為每一個圖指定一個固定大小的空白div，然後在js中取得該div物件並進行初始化和渲染。因此想法是講初始化和渲染的邏輯放在controller中，如下圖：

然而實際情況存在以下問題：

controller需要繼承kibana中的ui/modules，從程式碼上看該module屬於angularJS風格，然而在該module中大部分angularJS的內建方法都無法使用，例如service $document；
該module中無法使用除了kibana/src以外的模組，包括echarts和nodejs內建模組;
該module似乎不是很相容非同步資料載入和渲染（未驗證）。

由於以上問題，渲染的邏輯只能以/標籤寫在template中，然而template中的標籤是無法動態修改的（需要通過controller），因此需要另外的部分去修改template從而在每次Visualization讀取template時載入資料的變化，目前的實現是通過一個web server定期將模板渲染出的拓撲圖匯出成html，用該html作為Visualization的template：