云原生 - Istio可觀察性之監控(四)

作者：justmine
頭條號：大數據與云原生
微信公眾號：大數據與云原生
創作不易，在滿足創作共用版權協議的基礎上可以轉載，但請以超鏈接形式注明出處。
為了方便閱讀，微信公眾號已按分類排版，后續的文章將在移動端首發，想學習云原生相關知識，請關注我。

一、回顧

云原生 - 體驗Istio的完美入門之旅(一)

云原生 - Why is istio(二)

云原生 - Istio可觀察性之分布式跟蹤(三)

[請持續關注...]

如前所述，業務微服務化后，每個單獨的微服務可能會有很多副本，多個版本，這么多微服務之間的相互調用、管理和治理非常復雜，Istio統一封裝了這塊內容在代理層，最終形成一個分布式的微服務代理集群(服務網格)。管理員通過統一的控制平面來配置整個集群的應用流量、安全規則等，代理會自動從控制中心獲取動態配置，根據用戶的期望來改變行為。

話外音：借著微服務和容器化的東風，傳統的代理搖身一變，成了如今炙手可熱的服務網格。

Istio就是上面service mesh架構的一種實現，通過代理(默認是envoy)全面接管服務間通信，完全支持主流的通信協議HTTP/1.1，HTTP/2，gRPC ，TCP等；同時進一步細分控制中心，包括Pilot、Mixer、Citadel等。

話外音：后面系列會詳細介紹控制中心的各個組件，請持續關注。

整體功能描述如下：

連接(Connect)

控制中心從集群中獲取所有微服務的信息，并分發給代理，這樣代理就能根據用戶的期望來完成服務之間的通信(自動地服務發現、負載均衡、流量控制等)。
保護(Secure)

所有的流量都是通過代理，當代理接收到未加密流量時，可以自動做一次封裝，把它升級成安全的加密流量。
控制(Control)

用戶可以配置各種規則(比如 RBAC 授權、白名單、rate limit 、quota等)，當代理發現服務之間的訪問不符合這些規則，就直接拒絕掉。
觀察(Observe)

所有的流量都經過代理，因此代理對整個集群的訪問情況知道得一清二楚，它把這些數據上報到控制中心，那么管理員就能觀察到整個集群的流量情況。

二、前言

作為服務網格的一個完整解決方案，為了向運維人員提供豐富而深入的控制，同時又不給服務開發人員帶來負擔，Istio被設計為高度模塊化和可擴展的平臺，涉及到眾多的組件，它們分工協作，共同組成了完整的控制平面。為了更好地學習如何運用Istio的連接、安全、控制、可觀察性全面地治理分布式微服務應用，先從戰略上鳥瞰Istio，進一步從戰術上學習Istio將更加容易，故作者決定從可觀察性開始Istio的布道，先體驗，再實踐，最后落地，一步步愛上Istio，愛上云原生，充分利用云資源的優勢，解放應用開發工程師的雙手，使他們僅僅關注業務實現，讓專業的人做專業的事，為企業創造更大的價值。

三、Istio的可觀察性

1. 日志

當流量流入服務網格中的微服務時，Istio可以為每個請求生成完整的記錄，包括源和目標的元數據等。使運維人員能夠將服務行為的審查控制到單個微服務的級別。

2. 監控

Istio基于監控的4 個黃金信號(延遲、流量、錯誤、飽和度)來生成一系列的服務指標，同時還提供了一組默認的服務網格監控大盤。

話外音：Istio還為服務網格控制平面提供了更為詳細的監控指標。

3. 分布式跟蹤

Istio根據采樣率為每個請求生成完整的分布式追蹤軌跡，以便運維人員可以理解服務網格內微服務的依賴關系和調用流程。

可以看出，Istio的可觀察性，致力于解決兩方面的問題：

1、癥狀：什么病？

是Istio的問題？
哪個Istio組件的問題？
[...]

2、原因：為什么得這種病？

怎樣跟蹤、分析、定位？
是異常，還是偶然事件？
[...]

知曉了癥狀(什么)和原因(為什么)，治病應該就信手拈來了吧，如果還不知如何治病，那就去格物致知吧。

話外音：不僅如此，Istio還支持按需降級或關閉某些功能的能力，請持續關注。

四、Why - 為什么需要監控？

在軟件形態上，Service Mesh將業務系統中的非業務功能剝離到獨立的中間件系統中。同時，為了解耦運維，以Sidecar的方式將中間系統注入到業務容器內，在落地過程中難免會面臨穩定性、運維模式變化等諸多的問題與挑戰，如何確保網格的生產穩定和可靠呢？

從設計之初，Istio都致力于建設一個高可用的基礎架構，以防止服務質量降低而影響業務本身。為了跟蹤分布式系統中的每個信號，Istio基于Google網站可靠性工程師小組(SRE)定義的四個監控關鍵指標，全面而詳細地監控業務系統和自身。

黃金四信號：

延遲(Latency)

處理請求的時間，即發送請求和接收響應所需的時間，比如：請求成功與請求失敗的延遲。

在微服務中提倡“快速失敗”，特別要注意那些延遲較大的錯誤請求。這些緩慢的錯誤請求會明顯影響系統的性能，因此追蹤這些錯誤請求的延遲是非常重要的。
流量(Traffic)

也稱吞吐量，用于衡量系統的容量需求，即收到多少請求，比如：請求率(HTTP請求數/秒)。

對于分布式系統，它可以幫助您提前規劃容量以滿足即將到來的需求等。
錯誤(Errors)

衡量系統發生的錯誤情況，比如：請求錯誤率。
飽和度(Saturation)

衡量網絡和服務器等資源的負載，主要強調最能影響服務狀態的受限制資源。

每個資源都有一個限制，之后性能將降低或變得不可用。了解分布式系統的哪些部分可能首先變得飽和，以便在性能下降之前調整容量。

黃金四信號幾乎深度覆蓋了所有想知道到底怎么回事的相關信息，既是監控系統發現問題的關鍵，也是保障高可用基礎性框架的關鍵。

話外音：分布式系統不同于單體應用，監控信號是異常檢測的關鍵，是預警的重要積木。

五、What - Istio的監控？

為了監控應用服務行為，Istio為服務網格中所有出入的服務流量都生成了指標，例如總請求數、錯誤率和請求響應時間等。

為了監控服務網格本身，Istio組件可以導出自身內部行為的詳細統計指標，以提供對服務網格控制平面功能和健康情況的洞察能力。

話外音：Istio指標收集可以由運維人員配置來驅動，即運維人員決定如何以及何時收集指標，以及收集的詳細程度，靈活地調整指標收集策略來滿足個性化的監控需求。

代理級別指標

Istio指標收集從sidecar代理(Envoy)開始，它為通過代理的所有流量(入站和出站)生成一組豐富的指標，同時允許運維人員為每個工作負載實例(微服務)配置如何生成和收集哪些指標。

Envoy統計信息收集詳細說明：https://www.envoyproxy.io/docs/envoy/latest/intro/arch_overview/observability/statistics.html?highlight=statistics

服務級別指標

除了代理級別指標之外，Istio還提供了一組用于監控服務通信的指標。這些指標涵蓋了四個基本的服務監控需求：延遲、流量、錯誤、飽和度，同時Istio也提供了一組默認的儀表盤，用于監控基于這些指標的服務行為。

默認的Istio指標由Istio提供的配置集定義并默認導出到Prometheus。運維人員可以自由地修改這些指標的形態和內容，更改它們的收集機制，以滿足各自的監控需求。

備注：運維人員也可以選擇關閉服務級別指標的生成和收集。

控制面板指標

每一個Istio的組件(Pilot、Galley、Mixer等)都提供了對自身監控指標的集合。這些指標容許監控Istio自己的行為。

六、How - Istio監控是如何工作的？

1、部署監控大盤

root@just:~# istioctl manifest apply --set values.grafana.enabled=true
[...]
? Finished applying manifest for component Grafana.
[...]
root@just:~# kubectl -n istio-system get svc grafana -o yaml
apiVersion: v1
kind: Service
[...]
  name: grafana
  namespace: istio-system
spec:
  [...]
  type: NodePort
  ports:
  [...]
    nodePort: 3000
  [...]

話外音：測試環境使用NodePort聯網，僅供參考。

瀏覽器訪問：http://[主機IP]:3000/dashboard/db/istio-mesh-dashboard。

微服務應用BookInfo監控大盤

為了更好的閱讀體驗，上面僅截取了部分監控，可以看出監控的四個黃金信號吧，同時，為了使指標統計更精確，有的指標還通過P50、P90、P99維度分別展示，消除長尾噪音。除了業務監控，Istio也提供了自身平臺的監控大盤，如下：

可以看出Istio的默認監控大盤非常全面，該監控的都監控起來了，到目前為止，大家已經從整體上了解和體驗Istio的監控體系。

2、擴展新指標

為了支持個性化監控需求，Istio支持自定義指標來擴展監控體系，下面將添加一個新指標(將每個請求計數兩次)，并發送到Prometheus。

備注：Istio也支持自定義Mixer Adapter來支持其他監控后端。

2.1 定義指標

創建名為doublerequestcount的新指標，告訴Mixer如何根據Envoy報告的屬性為請求創建指標維度和生成值，即對于doublerequestcount的每個instance，指示Mixer為它提供值2。

備注：Istio將為每個請求生成一個Instance。

# Configuration for metric instances
apiVersion: config.istio.io/v1alpha2
kind: instance
metadata:
  name: doublerequestcount # metric name
  namespace: istio-system
spec:
  compiledTemplate: metric
  params:
    value: "2" # count each request twice
    # 表示指標的維度，為prometheus指標的{}部分。
    # 參考: {destination="",instance="",job="",message="",reporter="",source=""}`
    dimensions:
      reporter: conditional((context.reporter.kind | "inbound") == "outbound", "client", "server")
      source: source.workload.name | "unknown"
      destination: destination.workload.name | "unknown"
      message: '"twice the fun!"'
    monitored_resource_type: '"UNSPECIFIED"'

2.2 定義指標處理器

創建能夠處理生成的instances的handlers，即告訴Prometheus適配器如何將收到的指標轉換為Prometheus格式的指標。

# Configuration for a Prometheus handler
apiVersion: config.istio.io/v1alpha2
kind: handler
metadata:
  name: doublehandler
  namespace: istio-system
spec:
  compiledAdapter: prometheus
  params:
    metrics:
      # Prometheus metric name
    - name: double_request_count 
      # Mixer instance name (完全限定名稱)
      instance_name: doublerequestcount.instance.istio-system 
      kind: COUNTER
      # 此處標簽為doublerequestcount instance配置的dimensions。
      label_names:
      - reporter
      - source
      - destination
      - message

在指標名稱之前，Prometheus適配器會添加了istio_前綴，因此該指標在Prometheus中最終名稱為 istio_double_request_count。

2.3 關聯指標到處理器

根據一組rules向handlers分配instances，如下將網格中的所有請求生成的指標都發送到doublehandler處理器，也可以使用match條件，篩選指標。

# Rule to send metric instances to a Prometheus handler
apiVersion: config.istio.io/v1alpha2
kind: rule
metadata:
  name: doubleprom
  namespace: istio-system
spec:
  actions:
  - handler: doublehandler
    instances: [ doublerequestcount ]