基於請求或回應分類指標
根據網格中服務處理的請求和回應類型來視覺化遙測資料會很有用。例如,一家書店追蹤書籍評論被請求的次數。書籍評論請求具有以下結構
GET /reviews/{review_id}
計算評論請求的次數必須考慮到無界元素 review_id
。GET /reviews/1
接著 GET /reviews/2
應該計為兩個取得評論的請求。
Istio 讓您可以使用 AttributeGen 外掛程式建立分類規則,將請求分組為固定數量的邏輯操作。例如,您可以建立一個名為 GetReviews
的操作,這是使用 Open API Spec operationId
識別操作的常見方式。此資訊會以 istio_operationId
屬性的形式注入到請求處理中,其值等於 GetReviews
。您可以使用此屬性作為 Istio 標準指標的維度。同樣地,您可以根據其他操作(如 ListReviews
和 CreateReviews
)追蹤指標。
依請求分類指標
您可以根據請求的類型對其進行分類,例如 ListReview
、GetReview
、CreateReview
。
建立一個檔案,例如
attribute_gen_service.yaml
,並將其儲存為以下內容。這會新增istio.attributegen
外掛程式。它還會建立一個屬性istio_operationId
,並為要計為指標的類別填入值。此配置是服務特定的,因為請求路徑通常是服務特定的。
apiVersion: extensions.istio.io/v1alpha1 kind: WasmPlugin metadata: name: istio-attributegen-filter spec: selector: matchLabels: app: reviews url: https://storage.googleapis.com/istio-build/proxy/attributegen-359dcd3a19f109c50e97517fe6b1e2676e870c4d.wasm imagePullPolicy: Always phase: AUTHN pluginConfig: attributes: - output_attribute: "istio_operationId" match: - value: "ListReviews" condition: "request.url_path == '/reviews' && request.method == 'GET'" - value: "GetReview" condition: "request.url_path.matches('^/reviews/[[:alnum:]]*$') && request.method == 'GET'" - value: "CreateReview" condition: "request.url_path == '/reviews/' && request.method == 'POST'" --- apiVersion: telemetry.istio.io/v1 kind: Telemetry metadata: name: custom-tags spec: metrics: - overrides: - match: metric: REQUEST_COUNT mode: CLIENT_AND_SERVER tagOverrides: request_operation: value: istio_operationId providers: - name: prometheus
使用以下命令套用您的變更
$ kubectl -n istio-system apply -f attribute_gen_service.yaml
變更生效後,請訪問 Prometheus 並尋找新的或已變更的維度,例如
reviews
pod 中的istio_requests_total
。
依回應分類指標
您可以使用類似的程序來分類回應,就像請求一樣。請注意,預設情況下已存在 response_code
維度。以下範例將變更其填入方式。
建立一個檔案,例如
attribute_gen_service.yaml
,並將其儲存為以下內容。這會新增istio.attributegen
外掛程式,並產生由統計外掛程式使用的istio_responseClass
屬性。此範例對各種回應進行分類,例如將
200
範圍內的所有回應代碼分組為2xx
維度。apiVersion: extensions.istio.io/v1alpha1 kind: WasmPlugin metadata: name: istio-attributegen-filter spec: selector: matchLabels: app: productpage url: https://storage.googleapis.com/istio-build/proxy/attributegen-359dcd3a19f109c50e97517fe6b1e2676e870c4d.wasm imagePullPolicy: Always phase: AUTHN pluginConfig: attributes: - output_attribute: istio_responseClass match: - value: 2xx condition: response.code >= 200 && response.code <= 299 - value: 3xx condition: response.code >= 300 && response.code <= 399 - value: "404" condition: response.code == 404 - value: "429" condition: response.code == 429 - value: "503" condition: response.code == 503 - value: 5xx condition: response.code >= 500 && response.code <= 599 - value: 4xx condition: response.code >= 400 && response.code <= 499 --- apiVersion: telemetry.istio.io/v1 kind: Telemetry metadata: name: custom-tags spec: metrics: - overrides: - match: metric: REQUEST_COUNT mode: CLIENT_AND_SERVER tagOverrides: response_code: value: istio_responseClass providers: - name: prometheus
使用以下命令套用您的變更
$ kubectl -n istio-system apply -f attribute_gen_service.yaml
驗證結果
透過將流量傳送到您的應用程式來產生指標。
訪問 Prometheus 並尋找新的或已變更的維度,例如
2xx
。或者,使用以下命令驗證 Istio 是否為您的新維度產生資料$ kubectl exec pod-name -c istio-proxy -- curl -sS 'localhost:15000/stats/prometheus' | grep istio_
在輸出中,找到指標(例如
istio_requests_total
),並驗證是否存在新的或已變更的維度。
疑難排解
如果分類未如預期發生,請檢查以下潛在原因和解決方案。
檢閱您套用組態變更的服務所在 pod 的 Envoy Proxy 日誌。檢查 pod (pod-name
) 上 Envoy Proxy 日誌中是否有服務回報的錯誤,您可以在此處使用以下命令設定分類:
$ kubectl logs pod-name -c istio-proxy | grep -e "Config Error" -e "envoy wasm"
此外,請檢查以下命令的輸出中是否有重新啟動的跡象,以確保沒有 Envoy Proxy 當機。
$ kubectl get pods pod-name
清除
移除 yaml 組態檔案。
$ kubectl -n istio-system delete -f attribute_gen_service.yaml