要求またはレスポンスに基づいたメトリクスの分類

メッシュ内のサービスによって処理される要求とレスポンスの種類に基づいて、テレメトリを視覚化することが役立ちます。たとえば、書店員は、本のレビューが要求された回数を追跡します。本のレビュー要求には、次の構造があります。

GET /reviews/{review_id}

レビュー要求の数をカウントするには、無制限の要素review_idを考慮する必要があります。GET /reviews/1 の後に GET /reviews/2 が続いた場合、レビューを取得するための2つの要求としてカウントする必要があります。

Istioを使用すると、AttributeGenプラグインを使用して分類ルールを作成できます。このプラグインは、要求を固定数の論理演算にグループ化します。たとえば、Open API Spec operationIdを使用して演算を識別する一般的な方法であるGetReviewsという名前の演算を作成できます。この情報は、値がGetReviewsであるistio_operationId属性として要求処理に挿入されます。この属性を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ポッド内のistio_requests_total）を確認します。

レスポンスによるメトリクスの分類

レスポンスの分類は、リクエストと同様のプロセスで行うことができます。ただし、response_codeディメンションはデフォルトで既に存在することに注意してください。以下の例では、その設定方法が変わります。

例えばattribute_gen_service.yamlというファイルを作成し、以下の内容で保存します。これにより、istio.attributegenプラグインが追加され、statsプラグインで使用される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）を見つけ、新しいまたは変更されたディメンションが存在することを確認します。

トラブルシューティング

期待通りに分類されない場合は、以下の原因と解決策を確認してください。

設定変更を適用したサービスを持つポッドのEnvoyプロキシログを確認します。以下のコマンドを使用して、設定した分類において、サービスがEnvoyプロキシログ（pod-name）にエラーを報告していないことを確認します。

$ kubectl logs pod-name -c istio-proxy | grep -e "Config Error" -e "envoy wasm"

さらに、以下のコマンドの出力を確認して、Envoyプロキシのクラッシュがないことを確認してください。

$ kubectl get pods pod-name

クリーンアップ

yaml設定ファイルを削除します。

$ kubectl -n istio-system delete -f attribute_gen_service.yaml