微服務監控探索

微服務監控簡介

 

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

 

監控總體架構

 

部署

 

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

 

• 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的配置，其工做流程大體以下：

 

 

 

1. 初始化k8s_api地址以及docker daemon的api地址

2. 以stream的方式請求docker daemon的watch api，當有容器建立或銷燬時返回該event，並觸發更新配置的操做

3. 根據宿主機的ip用k8s_api得到該node上全部podip

4. 根據podip得到該node上全部endpoint的端口

5. 更新packetbeat的配置文件並重啓packetbeat

 

 

topology

 

總體預覽效果以下：

 

 

 

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

 

生成topology的流程大體以下：

1. 初始化完成讀取配置文件等信息，包括es地址、k8s_api地址等等

2. 根據宿主機的ip從k8s_api的/pods查詢該node上全部podIP，返回ip-->podname的字典

3. 接受請求or定時刷新觸發，使用es的search api拉取符合過濾條件（時間週期、協議類型等）的數據，生成拓撲圖必須的節點---nodes[]和邊---links[]的數組，並計算對應的請求數、平均responsetime等統計信息

4. 對節點和邊信息中的ip，若存在ip-->podname的對應關係則轉換爲podname

5. 若某ip沒有對應podname，則轉換爲查詢DNS返回的hostname

6. 利用獲得的nodes[]和links[]渲染模板，生成html

7. 拓撲圖的渲染使用開源JS做圖庫Echarts中的力導向圖

 

Kibana Plugin

 

爲了和更好的結合elk，將topology做爲plugin集成到kibana的visualization裏是一個不錯的選擇。然而kibana官方文檔只介紹了plugin的安裝，並無相關的develop文檔...從收集到的民間文檔來看，開發plugin存在如下坑：

 

1. 因爲不是官方api，用到的api極可能在下個版本被和諧，意味着對每個版本的kibana都要調整

2. plugin安裝的來源限於官方或者github，須要發佈後才能安裝

3. 最關鍵的是，在kibana的官方repo中赫然寫着：             

 

 

鑑於以上，仍是部署了一個kibana的dev模式進行嘗試開發一個Visualization用於展現拓撲結構。 一個Visualization plugin的核心主要由template和controller控制，在模板中的div中指定controller用以操做內部變量和邏輯。拓撲圖的實現基於開源js做圖庫Echarts，其原理是爲每個圖指定一個固定大小的空白div，而後在js中取得該div對象並進行初始化和渲染。所以想法是講初始化和渲染的邏輯放在controller中，以下圖：

然而實際狀況存在如下問題：

 

1. controller須要繼承kibana中的ui/modules，從代碼上看該module屬於angularJS風格，然而在該module中大部分angularJS的內置方法都沒法使用，例如service $document；

2. 該module中沒法使用除了kibana/src之外的模塊，包括echarts和nodejs內置模塊;

3. 該module彷佛不是很兼容異步數據加載和渲染（未驗證）。

 

因爲以上問題，渲染的邏輯只能以/標籤寫在template中，然而template中的標籤是沒法動態修改的（須要經過controller），所以須要另外的部分去修改template從而在每次Visualization讀取template時加載數據的變化，目前的實現是經過一個web server按期將模板渲染出的拓撲圖導出成html，用該html做爲Visualization的template：

 

目前的效果能夠在kibana dashboard中添加拓撲結構圖，然而該圖的統計時間範圍控制、前端參數等等都在web server中控制，而且因爲異步渲染的問題，在dashboard中須要先切換到別的標籤再切換回來才能看到該圖...

 

 

 

參考資料

• https://www.elastic.co/guide/en/beats/packetbeat/current/index.html packetbeat官方文檔

• https://www.timroes.de/2015/12/02/writing-kibana-4-plugins-basics/ kibana plugin民間文檔

 

 

 

網易雲新用戶大禮包：https://www.163yun.com/gift

 

本文來自網易實踐者社區，經做者何丹受權發佈。