Service Mesh - Istio服務觀測篇

洞察你的服務:使用Kiali觀測你的微服務應用

微服務架構可視化的重要性:前端

  • 痛點:
    • 服務間依賴關係錯綜複雜
    • 問題排查困難,扯皮甩鍋時有發生
  • 可視化的優點:
    • 梳理服務的交互關係
    • 瞭解應用的行爲與狀態

什麼是 Kialiweb

Kiali屬於Istio的集成組件之一,是一個用於Istio的可觀測性控制檯,具備服務網格配置和驗證功能。它經過監控網絡流量來推斷服務拓撲和報告錯誤,幫助你瞭解服務網格的結構和運行情況。Kiali提供了詳細的度量和基本的Grafana集成,可用於高級查詢。數據庫

  • 官方定義:
    • Istio 的可觀察性控制檯
    • 經過服務拓撲幫助你理解服務網格的結構
    • 提供網格的健康狀態視圖
    • 具備服務網格配置功能
  • 名字含義:源自希臘語,意爲望遠鏡
  • 依賴 Istio 做爲宿主,爲 Istio 開發有較強的綁定關係
  • Kiali 是 Istio 服務觀測的一環

Kiali 的功能:
Service Mesh - Istio服務觀測篇json

Kiali 的架構:
Service Mesh - Istio服務觀測篇後端

從上圖能夠看到 Kiali 是一個先後端分離的架構,咱們可使用官方提供的配置文件啓動 Kiali 的後端組件:瀏覽器

[root@m1 ~]# kubectl apply -f /usr/local/istio-1.8.1/samples/addons/kiali.yaml

確認啓動成功:安全

[root@m1 ~]# kubectl get pods -n istio-system 
NAME                                    READY   STATUS    RESTARTS   AGE
kiali-7476977cf9-nwnsg                  1/1     Running   1          33h
...

而後使用以下命令啓動 kiali 的前端:bash

[root@m1 ~]# istioctl dashboard kiali --address 192.168.243.138
http://localhost:20001/kiali
  • Tips:這裏的 IP 是該虛擬機可被外部訪問的 IP

使用瀏覽器訪問 192.168.243.138:20001 ,基本頁面以下:
Service Mesh - Istio服務觀測篇網絡

在 「Application」 頁面能夠查看不一樣 Namespace 下所部署的應用:
Service Mesh - Istio服務觀測篇架構

在 「Graph」 頁面下能夠查看服務之間的整體拓撲,並提供了多種頁面操做:
Service Mesh - Istio服務觀測篇

在 「Services」 頁面能夠查看指定 Namespace 下的服務信息:
Service Mesh - Istio服務觀測篇

點擊服務的名稱能夠進入該服務的詳情頁:
Service Mesh - Istio服務觀測篇

在 「Workloads」 頁面能夠查看指定 Namespace 下的工做負載信息:
Service Mesh - Istio服務觀測篇

點擊工做負載的名稱能夠進入該工做負載的詳情頁:
Service Mesh - Istio服務觀測篇

在 「Istio Config」 頁面能夠對 Istio 中的資源配置進行查看、編輯及驗證:
Service Mesh - Istio服務觀測篇

  • 綠色表明沒問題,黃色表明有警告,例如使用了過時的配置項,紅色則表明配置有錯誤

例如 detail 的配置有錯誤,咱們能夠點擊進去查看出錯的地方,而且根據提示進行修改,而後點擊 「Save」 保存便可:
Service Mesh - Istio服務觀測篇

在 「Istio Config」 頁面還有個嚮導功能,可讓咱們建立 Istio 的資源。以下:
Service Mesh - Istio服務觀測篇

但目前只提供了少數的幾個資源類型能夠建立:
Service Mesh - Istio服務觀測篇


指標:使用Prometheus收集指標

Prometheus 是一個開源的監控系統和時間序列數據庫。你可使用 Prometheus 來記錄跟蹤 Istio 和服務網格內應用程序運行情況的指標。而後可使用Grafana和Kiali等工具對監控指標進行可視化。

Prometheus 的功能:
Service Mesh - Istio服務觀測篇

Prometheus 的架構:
Service Mesh - Istio服務觀測篇

Prometheus 與 Istio 的集成也比較簡單,咱們可使用官方提供的配置文件啓動 Prometheus Server:

[root@m1 ~]# kubectl apply -f /usr/local/istio-1.8.1/samples/addons/prometheus.yaml

確認啓動成功:

[root@m1 ~]# kubectl get pods -n istio-system 
NAME                                    READY   STATUS    RESTARTS   AGE
prometheus-7bfddb8dbf-4mnzr             2/2     Running   2          33h
...

而後使用以下命令啓動 Prometheus 的 Web UI :

[root@m1 ~]# istioctl dashboard prometheus --address 192.168.243.138
http://localhost:9090

使用瀏覽器訪問 192.168.243.138:9090,頁面以下:
Service Mesh - Istio服務觀測篇

經過官方提供的配置文件啓動 Prometheus Server 後,它就會自動收集 Istio 的監控指標了。此時咱們就能夠經過 Prometheus 收集指標並查看指標數據了,例如查看 Istio 的請求總數,該指標屬於服務指標
Service Mesh - Istio服務觀測篇

Envoy 代理指標則以 envoy 開頭,能夠輸入前綴進行查詢:
Service Mesh - Istio服務觀測篇

除以上兩類指標外還有控制平面指標,這類指標是 Istio 提供的一系列自我監控指標,這些指標用於監控 Istio 自己的行爲。

在 「Status -> Targets」 頁面能夠查看監控目標的狀態:
Service Mesh - Istio服務觀測篇

Istio 1.5 以後提供的遙測指標:

  • 請求總數(istio_requests_total)
  • 請求時長(istio_request_duration_milliseconds)
  • 請求大小(istio_request_bytes)
  • 響應大小(istio_response_bytes)
  • TCP 發送字節數(istio_tcp_sent_bytes_total)
  • TCP 接受字節數(istio_tcp_received_bytes_total)
  • TCP 鏈接打開數(istio_tcp_connections_opened_total)
  • TCP 鏈接關閉數(istio_tcp_connections_closed_total)

Istio 1.5 以前是經過Mixer來進行指標收集的,以下圖:
Service Mesh - Istio服務觀測篇

  • 首先Envoy須要調用Mixer來上報指標信息,Mixer則會提供一個 metrics 這樣的接口給 Prometheus 去抓取指標數據。由於每次請求進入代理時都須要調用Mixer上報數據,致使了一些性能問題,例如額外的資源佔用以及請求延遲這樣的狀況,因此1.5以後Mixer就被廢棄了

Istio 1.5 以後就直接是 Envoy 和 Prometheus 進行交互,以下圖:
Service Mesh - Istio服務觀測篇

  • 不管是代理級別的指標仍是服務級別的指標,都是經過 Envoy 直接去獲取的,這就省去了一層與Mixer的交互。儘管更改後的版本在性能上有了大幅提高,但仍是存在一些問題。首先由於取消了Mixer這樣的中心化管理,因此致使 Envoy 代理須要本身去上傳指標數據,不是很方便,擴展性變弱了。

可同時解決性能與擴展性問題最可行的一個方法就是將來在 Envoy 上使用 WebAssembly 這樣的技術。WebAssembly in Envoy:
Service Mesh - Istio服務觀測篇

  • 解決靜態化編譯(構建時)的弊端
  • 優點:
    • 無需修改 Envoy
    • 避免遠程調用
    • 隔離性/安全/多樣性
    • 可移植/可維護

關於收集、查詢指標的更多方式能夠參考官方文檔:


監控:使用Grafana查看系統的總體狀態

Grafana 的功能:
Service Mesh - Istio服務觀測篇

  • Grafana 只是一個功能強大的可視化分析平臺,自身並不包含數據源,因此一般須要配合 Prometheus 等數據源使用。讓 Grafana 從Prometheus 中讀取數據進行各類可視化展現,能夠彌補 Prometheus 自帶的可視化界面的不足

Istio 默認提供了一些 Grafana Dashboard:

  • Mesh Dashboard:查看應用(服務)數據
    • 網格數據總覽
    • 服務視圖
    • 工做負載視圖
  • Performance Dashboard:查看 Istio 自身(各組件)數據
    • Istio 系統總覽
    • 各組件負載狀況

關於 Grafana 與 Istio 的集成,官方也提供了相應的配置文件,使用以下命令就能夠啓動 Grafana :

[root@m1 ~]# kubectl apply -f /usr/local/istio-1.8.1/samples/addons/grafana.yaml

確認啓動成功:

[root@m1 ~]# kubectl get pods -n istio-system 
NAME                                    READY   STATUS    RESTARTS   AGE
grafana-784c89f4cf-s26lp                1/1     Running   1          33h
...

而後使用以下命令啓動 Grafana 的 Web UI :

[root@m1 ~]# istioctl dashboard grafana --address 192.168.243.138
http://localhost:3000

使用瀏覽器訪問 192.168.243.138:3000 ,首頁以下:
Service Mesh - Istio服務觀測篇

如今咱們就能夠使用 Grafana 查看指標生成的 Istio Dashboard了,進入 「Home」,能夠看到 Istio 提供的 Dashboard:
Service Mesh - Istio服務觀測篇

打開 「Istio Mesh Dashboard」 查看網格數據總覽,展現效果以下:
Service Mesh - Istio服務觀測篇

點擊下方的 Service 名稱能夠進入 「Istio Service Dashboard」 查看服務視圖:
Service Mesh - Istio服務觀測篇

「Istio Workload Dashboard」 查看工做負載視圖:
Service Mesh - Istio服務觀測篇

「Istio Performance Dashboard」 查看資源使用總覽:
Service Mesh - Istio服務觀測篇


日誌:如何獲取Envoy的日誌並進行調試

最簡單的一種Istio日誌記錄是Envoy的訪問日誌記錄。訪問日誌(Access logs)提供了一種從單個工做負載實例的角度監視和理解行爲的方法,經過查看Envoy日誌能夠了解流量信息、定位問題。Envoy代理將訪問信息打印到其標準輸出。而後,使用kubectl logs命令能夠打印Envoy容器的標準輸出。

這一小節將演示如何獲取Envoy的訪問日誌。首先,確認 Envoy 日誌配置已開啓(默認是開啓的),可以使用以下命令開啓:

$ istioctl install <flags-you-used-to-install-Istio> --set meshConfig.accessLogFile=/dev/stdout

仍是以Bookinfo應用做爲示例:

[root@m1 ~]# kubectl get pods
NAME                              READY   STATUS    RESTARTS   AGE
details-v1-79c697d759-wpxlj       2/2     Running   2          9h
productpage-v1-65576bb7bf-4bwwr   2/2     Running   2          9h
ratings-v1-7d99676f7f-cfbw4       2/2     Running   2          9h
reviews-v1-987d495c-8n5mv         2/2     Running   2          9h
reviews-v2-6c5bf657cf-rzn4q       2/2     Running   2          9h
reviews-v3-5f7b9f4f77-29454       2/2     Running   2          9h
[root@m1 ~]#

訪問Bookinfo應用的服務後會產生流量輸出,此時可使用以下命令查看 Envoy(istio-proxy)的日誌輸出:

[root@m1 ~]# kubectl logs -l app=productpage -c istio-proxy
...
[2020-12-23T01:34:30.349Z] "GET /details/0 HTTP/1.1" 200 - "-" 0 178 15 14 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4280.88 Safari/537.36" "1e449e4d-0f3f-928b-9add-8b8ace3f5feb" "details:9080" "172.22.152.212:9080" outbound|9080||details.default.svc.cluster.local 172.22.152.206:42074 10.104.2.32:9080 172.22.152.206:56744 - default
[2020-12-23T01:34:30.376Z] "GET /reviews/0 HTTP/1.1" 200 - "-" 0 375 948 948 "-" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4280.88 Safari/537.36" "1e449e4d-0f3f-928b-9add-8b8ace3f5feb" "reviews:9080" "172.22.78.148:9080" outbound|9080||reviews.default.svc.cluster.local 172.22.152.206:52008 10.100.239.139:9080 172.22.152.206:55806 - default

訪問日誌默認的格式是 TEXT 格式,不利於查看日誌項的含義,咱們能夠將日誌格式設置爲JSON,這樣能夠比較方便觀察其日誌項,使用以下命令將accessLogEncoding設置爲JSON:

$ istioctl install <flags-you-used-to-install-Istio> --set meshConfig.accessLogEncoding=JSON

將日誌格式設置爲JSON後,此時輸出的日誌內容以下:

{"upstream_cluster":"outbound|9080||reviews.default.svc.cluster.local","downstream_remote_address":"172.22.152.206:32852","authority":"reviews:9080","path":"/reviews/0","protocol":"HTTP/1.1","upstream_service_time":"735","upstream_local_address":"172.22.152.206:53320","duration":735,"route_name":"default","downstream_local_address":"10.100.239.139:9080","upstream_transport_failure_reason":null,"user_agent":"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4280.88 Safari/537.36","response_code":200,"response_flags":"-","start_time":"2020-12-23T01:45:58.932Z","method":"GET","request_id":"12bc8456-65b1-9a34-96e6-0fa9f0525f23","upstream_host":"172.22.152.209:9080","x_forwarded_for":null,"requested_server_name":null,"bytes_received":0,"bytes_sent":379}

將JSON格式化後,以下:
Service Mesh - Istio服務觀測篇

日誌信息中有五個重要的字段,也就是所謂的Envoy 流量五元組:
Service Mesh - Istio服務觀測篇

  • Envoy 流量五元組可讓你清晰地知道,流量是從哪裏來,會到哪裏去,因此五元組是 Envoy 日誌中很是重要的概念

調試關鍵字段:response_flags,一些請求的錯誤標誌會被賦值給該字段。常見錯誤標誌有以下幾種:

  • UH:upstream cluster 中沒有健康的 host,503
  • UF:upstream 鏈接失敗,503
  • UO:upstream overflow(熔斷)
  • NR:沒有路由配置,404
  • URX:請求被拒絕由於限流或最大鏈接次數
  • 更多信息可參考:官方文檔

Envoy 的一些日誌配置項:
Service Mesh - Istio服務觀測篇


分佈式追蹤:使用Jeager對應用進行分佈式追蹤

分佈式追蹤概念

  • 分析和監控應用的監控方法
  • 查找故障點、分析性能問題
  • 起源於 Google 的 Dapper
  • 隨着分佈式追蹤技術的發展,衍生出了OpenTracing:API 規範、框架、公共庫的組合
    Service Mesh - Istio服務觀測篇

Istio支持經過 Envoy 代理進行分佈式追蹤。代理會表明其代理的應用程序自動生成跟蹤範圍,只須要應用程序轉發適當的請求上下文。

Istio支持許多跟蹤後端,包括Zipkin、Jaeger、Lightstep和Datadog。本小節將介紹 Istio 集成 Jaeger 實現分佈式追蹤。

什麼是 Jaeger:

  • 開源、端到端的分佈式追蹤系統
  • 針對複雜的分佈式系統,對業務鏈路進行監控和問題排查
    Service Mesh - Istio服務觀測篇

分佈式追蹤的兩個重要術語:

  • Span:
    • 邏輯單元
    • 有操做名、執行時間
    • 嵌套、有序、因果關係
  • Trace:
    • 數據/執行路徑
    • Span 的組合
      Service Mesh - Istio服務觀測篇

Jaeger 的架構:
Service Mesh - Istio服務觀測篇

核心組件:

  • Client libraries:客戶端公共庫,支持不一樣語言
  • Agent:用於從應用抓取Span,併發送給Collector
  • Collector:收集器,從應用層收集Span數據,併發送給存儲系統(DB)
  • Query:至關於查詢引擎,用於提供在頁面上查詢數據的能力
  • Ingester:與Kafka配合使用,至關於Kafka的一個Consumer,消費數據存儲到DB中

接下來咱們把 Jaeger 集成到 Istio。首先,確認 Istio 開啓了追蹤選項,可使用以下命令開啓:

$ istioctl install <flags-you-used-to-install-Istio> --set values.tracing.enabled=true

咱們可使用官方提供的配置文件快速將 Jaeger 集成到 Istio 中:

[root@m1 ~]# kubectl apply -f /usr/local/istio-1.8.1/samples/addons/jaeger.yaml

確認 Jaeger 啓動成功:

[root@m1 ~]# kubectl get pods -n istio-system 
NAME                                    READY   STATUS    RESTARTS   AGE
jaeger-7f78b6fb65-gchw2                 1/1     Running   2          46h
...

而後使用以下命令啓動 Jaeger 的Web UI:

[root@m1 ~]# istioctl dashboard jaeger --address 192.168.243.138
http://localhost:16686

使用瀏覽器訪問 Jaeger 的Web UI:
Service Mesh - Istio服務觀測篇

而後訪問 Bookinfo 應用頁面生成一些 trace 數據後,到 Jaeger 查詢 trace 數據:
Service Mesh - Istio服務觀測篇

點擊任意 Span 能夠查看其詳細 trace 數據:
Service Mesh - Istio服務觀測篇
Service Mesh - Istio服務觀測篇

相關文章
相關標籤/搜索