ワークロード指標

GKE クラスタでワークロード指標を使用している場合は、クラスタを GKE 1.24 にアップグレードする前に、Managed Service for Prometheus に移行します。これは、GKE 1.24 でワークロード指標のサポートが削除されているためです。GKE 1.24 にすでに更新している場合は、クラスタに対してその他の変更を行う前に、ワークロード指標を無効にする必要があります。

GKE 1.20.8-gke.2100 以降と GKE バージョン 1.24 以前には、GKE ワークロードによって公開された Prometheus 形式の指標を収集するためのフルマネージド指標収集パイプライン（CronJob やアプリケーションの Deployment など）が用意されており、これらの指標を Cloud Monitoring に送信できます。

GKE ワークロード指標パイプラインによって収集されたすべての指標は、接頭辞 workload.googleapis.com を付けて Cloud Monitoring に取り込まれます。

GKE ワークロード指標の利点は次のとおりです。

簡単な設定: 単一の kubectl コマンドで PodMonitor カスタムリソースをデプロイし、指標の収集を開始できます。手動でのエージェントのインストールは必要ありません。
柔軟な構成が可能: スクレイピングエンドポイント、頻度、その他のパラメータを調整できます。
フルマネージド: Google がパイプラインを管理するので、ユーザーは自分のアプリケーションに集中できます。
費用の管理: 指標を柔軟にフィルタリングできるため、Cloud Monitoring のコストを簡単に管理できます。
オープン標準: Prometheus Operator の PodMonitor リソースに従ってモデル化された PodMonitor カスタムリソースを使用して、ワークロード指標を構成できます。
低価格設定: より直感的かつ予測可能で手頃な価格設定となっています。
Autopilot のサポート: GKE Standard と GKE Autopilot クラスタの両方に対応しています。

要件

GKE ワークロード指標には GKE コントロールプレーンのバージョン 1.20.8-gke.2100 以降が必要であり、GKE Windows ワークロードをサポートしていません。

ワークロード指標のパイプラインを有効にする場合は、システム指標の収集も有効にする必要があります。

手順 1: ワークロード指標パイプラインを有効にする

既存の GKE クラスタでワークロード指標収集パイプラインを有効にするには、次の手順を行います。

コンソール

Google Cloud コンソールで、GKE クラスタのリストに移動します。

Kubernetes クラスタに移動
クラスタの名前をクリックします。
[Cloud Monitoring] 行にある編集アイコンをクリックします。
表示された [Cloud Monitoring の編集] ダイアログボックスで、[Cloud Monitoring を有効にする] が選択されていることを確認します。
プルダウンメニューで [ワークロード] を選択します。
[OK] をクリックします。
[変更を保存] をクリックします。

gcloud

Google Cloud CLI がインストールされているデバイスでターミナルウィンドウを開きます。たとえば、Cloud Shell を使用してこの操作を行います。
Google Cloud コンソールで、「Cloud Shell をアクティブにする」をクリックします。

Cloud Shell をアクティブにする

Google Cloud コンソールの下部で Cloud Shell セッションが開始し、コマンドラインプロンプトが表示されます。Cloud Shell はシェル環境です。Google Cloud CLI がすでにインストールされており、現在のプロジェクトの値もすでに設定されています。セッションが初期化されるまで数秒かかることがあります。
次のコマンドを実行します。
```
gcloud beta container clusters update [CLUSTER_ID] \
  --zone=[ZONE] \
  --project=[PROJECT_ID] \
  --monitoring=SYSTEM,WORKLOAD
```
gcloud beta container clusters create または gcloud beta container clusters update コマンドの --monitoring フラグに WORKLOAD 値を含めると、ワークロード指標収集パイプラインが有効になります。

注: GKE ワークロード指標は現在プレビュー版であるため、必ず gcloud beta コマンドを使用してください。

ワークロード指標の収集パイプラインを有効にすると、Kubernetes ワークロードによって発行されたアプリケーション指標を収集できる各ノードに指標収集エージェントがデプロイされます。

Cloud Monitoring と GKE のインテグレーションの詳細については、Cloud Operations for GKE の構成をご覧ください。

手順 2: 収集する指標を構成する

1）my-pod-monitor.yaml という名前の PodMonitor カスタムリソースを作成します。


apiVersion: monitoring.gke.io/v1alpha1
kind: PodMonitor
metadata:
  # POD_MONITOR_NAME is how you identify your PodMonitor
  name: [POD_MONITOR_NAME]
  # POD_NAMESPACE is the namespace where your workload is running, and the
  # namespace of your PodMonitor object
  namespace: [POD_NAMESPACE]
spec:
  # POD_LABEL_KEY and POD_LABEL_VALUE identify which pods to collect metrics
  # from. For example, POD_LABEL_KEY of app.kubernetes.io/name and
  # POD_LABEL_VALUE of mysql would collect metrics from all pods with the label
  # app.kubernetes.io/name=mysql
  selector:
    matchLabels:
      [POD_LABEL_KEY]: [POD_LABEL_VALUE]
  podMetricsEndpoints:
    # CONTAINER_PORT_NAME is the name of the port of the container to be scraped
    # Use the following command to list all ports exposed by the container:
    # kubectl get pod [POD_NAME] -n [POD_NAMESPACE] -o json | jq '.items[].spec.containers[].ports[]?' | grep -v null
    # If the port for your metrics does not have a name, modify your application's pod spec
    # to add a port name.
  - port: [CONTAINER_PORT_NAME]

2）Google Cloud CLI を使用して認証情報を初期化し、kubectl を設定します。

gcloud container clusters get-credentials [CLUSTER_ID] --zone=[ZONE]

3）PodMonitor カスタムリソースをデプロイします。

kubectl apply -f my-pod-monitor.yaml

料金

Cloud Monitoring では、取り込まれたサンプルの数に基づいて GKE ワークロード指標の取り込みに対して課金されます。詳しくは Cloud Monitoring の料金を確認してください。

費用の管理

費用を管理するには、まず、モニタリングのニーズに最も適したワークロード指標を決めます。GKE ワークロード指標パイプラインではきめ細かな制御が可能なため、詳細な指標の取得とコストの削減で適切なトレードオフを実現できます。

多くのアプリケーションでは、さまざまな Prometheus 指標が公開されています。デフォルトでは、GKE ワークロード指標パイプラインでは、選択された各 Pod から 60 秒ごとにすべての指標が取得されます。

次の方法を使用して指標のコストを削減できます。

スクレイピング頻度の調整: 指標のコストを削減するには、必要に応じてスクレイピング頻度を下げることをおすすめします。たとえば、ビジネスに関連する KPI がゆっくりと変化する場合は、10 分ごとにスクレイピングするだけで十分です。PodMonitor で、interval を設定してスクレイピング頻度を制御します。
指標のフィルタリング: Cloud Monitoring で使用されていない指標を特定し、metricRelabelings を使用してダッシュボード、アラート、SLO に役立つ指標のみが Cloud Monitoring に送信されるようにします。

両方の手法を使用する PodMonitor カスタムリソースの具体的な例を次に示します。

apiVersion: monitoring.gke.io/v1alpha1
kind: PodMonitor
metadata:
  name: prom-example
  namespace: gke-workload-metrics
spec:
  selector:
    matchLabels:
      app: example
  podMetricsEndpoints:
  - port: metrics
    path: /metrics
    scheme: http

    # (1) scrape metrics less frequently than the default (once every 60s)
    interval: 10m

    metricRelabelings:

    - # (2) drop the irrelevant metric named "foo" and all metrics
      # with the prefix "bar_"
      sourceLabels: [__name__]
      regex: foo|bar_.*
      action: drop

    - # (3) keep only metrics with a subset of values for a particular label
      sourceLabels: [region]
      regex: us-.*
      action: keep

取り込まれたサンプル数が最も多い指標を特定するには、monitoring.googleapis.com/collection/attribution/write_sample_count 指標を使用します。

Google Cloud コンソールで [Monitoring] を選択します。

[Monitoring] に移動
[Monitoring] のナビゲーションパネルで、[Metrics Explorer] をクリックします。
[Metric] フィールドで [monitoring.googleapis.com/collection/attribution/write_sample_count] を選択します。
必要に応じて、GKE ワークロードの指標のみをフィルタリングします。
- [フィルタを追加] をクリックします。
- [Label] フィールドで metric_domain を選択します。
- [Value] に「workload.googleapis.com」と入力します。
- [DONE] をクリックします。
必要に応じて、Kubernetes 名前空間、GKE リージョン、Google Cloud プロジェクト、またはモニタリング対象のリソースタイプによって取り込まれたサンプル数をグループ化します。
- [Group by] をクリックします。
- Kubernetes 名前空間でグループ化するには、[attribution_dimension] と [attribution_id] を選択します。
- GKE リージョンでグループ化するには、[location] を選択します。
- Cloud プロジェクト別にグループ化するには、[resource_container] を選択します。
- モニタリング対象のリソースタイプでグループ化するには、[resource_type] を選択します。
指標のリストの上にある列ヘッダーの [Value] をクリックして、指標のリストを降順で並べ替えます。

以下の手順では、Cloud Monitoring に取り込まれたサンプルレートが最も高い指標について説明しています。GKE ワークロードの指標は取り込みサンプル数に応じて課金されるため、取り込まれるサンプルが最も多い指標に注意してください。これらの指標の取得頻度を減らすことが可能かどうか、あるいは収集を停止できるかどうかを検討してください。

最後に、Cloud Monitoring に取り込まれた GKE 指標のコストを把握して、これらの費用を最適化するために利用できる多くのリソースがあります。Cloud Monitoring の費用を削減するその他の方法については、費用の最適化ガイドをご覧ください。

以前のバージョンの GKE

GKE コントロールプレーンのバージョンが 1.20.8-gke.2100 より前のクラスタでアプリケーション指標を収集するには、Stackdriver Prometheus サイドカーを使用します。

トラブルシューティング

Cloud Monitoring で指標が予期したとおりに表示されない場合は、以降のセクションの手順でトラブルシューティングを行います。

ワークロード指標のトラブルシューティング

Cloud Monitoring でワークロード指標が予期したとおりに表示されない場合は、次の手順で問題を解決できます。

クラスタが最小要件を満たしていることを確認する

GKE クラスタがコントロールプレーンバージョン 1.20.8-gke.2100 以降を実行していることを確認します。そうでない場合は、クラスタのコントロールプレーンをアップグレードしてください。

ワークロード指標が有効であることを確認する

次の手順で、ワークロード指標の収集パイプラインを有効にするように GKE クラスタが構成されていることを確認します。

コンソール

Google Cloud コンソールで、GKE クラスタのリストに移動します。

Kubernetes クラスタに移動
クラスタの名前をクリックします。
クラスタの [詳細] パネルで、Cloud Monitoring のステータスにワークロードが含まれていることを確認します。ここに [ワークロード] が表示されていない場合は、ワークロード指標を有効にします。

gcloud

gcloud CLI がインストールされているデバイスで、ターミナルウィンドウを開きます。たとえば、Cloud Shell を使用してこの操作を行います。
Google Cloud コンソールで、「Cloud Shell をアクティブにする」をクリックします。

Cloud Shell をアクティブにする

Google Cloud コンソールの下部で Cloud Shell セッションが開始し、コマンドラインプロンプトが表示されます。Cloud Shell はシェル環境です。Google Cloud CLI がすでにインストールされており、現在のプロジェクトの値もすでに設定されています。セッションが初期化されるまで数秒かかることがあります。
次のコマンドを実行します。
```
gcloud container clusters describe [CLUSTER_ID] --zone=[ZONE]
```
コマンドの出力で、monitoringConfig: 行を探します。 2～3 行後の enableComponents: セクションに WORKLOADS が含まれていることを確認します。ここに WORKLOADS がない場合は、ワークロード指標を有効にします。

アプリケーションから指標が収集されていることを確認する

Cloud Monitoring でアプリケーションの指標を表示できない場合は、以下の手順で問題を解決できます。この手順ではデモを目的としてサンプルアプリケーションを使用していますが、以下の同じ手順を適用してアプリケーションのトラブルシューティングを行うことができます。

以下に、テストに使用できるサンプルアプリケーションをデプロイする手順を示します。残りの手順では、そのアプリケーションの指標が Cloud Monitoring に表示されない理由について説明します。

prometheus-example-app.yaml という名前のファイルを作成し、次の内容を保存します。

# This example application exposes prometheus metrics on port 1234.
apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app: prom-example
  name: prom-example
  namespace: gke-workload-metrics
spec:
  selector:
    matchLabels:
      app: prom-example
  template:
    metadata:
      labels:
        app: prom-example
    spec:
      containers:
      - image: nilebox/prometheus-example-app@sha256:dab60d038c5d6915af5bcbe5f0279a22b95a8c8be254153e22d7cd81b21b84c5
        name: prom-example
        ports:
        - name: metrics-port
          containerPort: 1234
        command:
        - "/main"
        - "--process-metrics"
        - "--go-metrics"

Google Cloud CLI を使用して認証情報を初期化し、kubectl を設定します。
```
gcloud container clusters get-credentials [CLUSTER_ID] --zone=[ZONE]
```
gke-workload-metrics 名前空間を作成します。
```
kubectl create ns gke-workload-metrics
```
サンプルアプリケーションをデプロイします。
```
kubectl apply -f prometheus-example-app.yaml
```

次のコマンドを実行して、サンプルアプリケーションが実行されていることを確認します。

kubectl get pod -n gke-workload-metrics -l app=prom-example

出力は次のようになります。

NAME                            READY   STATUS    RESTARTS   AGE
prom-example-775d8685f4-ljlkd   1/1     Running   0          25m

アプリケーションが想定どおりに指標を公開していることを確認します。

上記のコマンドで返された Pod のいずれかを使用して、指標エンドポイントが正しく動作していることを確認します。

POD_NAME=prom-example-775d8685f4-ljlkd
NAMESPACE=gke-workload-metrics
PORT_NUMBER=1234
METRICS_PATH=/metrics
kubectl get --raw /api/v1/namespaces/$NAMESPACE/pods/$POD_NAME:$PORT_NUMBER/proxy/$METRICS_PATH

上記のサンプルアプリケーションを使用すると、次のような出力が表示されます。

# HELP example_random_numbers A histogram of normally distributed random numbers.
# TYPE example_random_numbers histogram
example_random_numbers_bucket{le="0"} 501
example_random_numbers_bucket{le="0.1"} 1.75933011554e+11
example_random_numbers_bucket{le="0.2"} 3.50117676362e+11
example_random_numbers_bucket{le="0.30000000000000004"} 5.20855682325e+11
example_random_numbers_bucket{le="0.4"} 6.86550977647e+11
example_random_numbers_bucket{le="0.5"} 8.45755380226e+11
example_random_numbers_bucket{le="0.6"} 9.97201199544e+11
...

my-pod-monitor.yaml という名前のファイルを作成し、次の内容を保存します。

# Note that this PodMonitor is in the monitoring.gke.io domain,
# rather than the monitoring.coreos.com domain used with the
# Prometheus Operator.  The PodMonitor supports a subset of the
# fields in the Prometheus Operator's PodMonitor.
apiVersion: monitoring.gke.io/v1alpha1
kind: PodMonitor
metadata:
  name: example
  namespace: gke-workload-metrics
# spec describes how to monitor a set of pods in a cluster.
spec:
  # selector determines which pods are monitored.  Required
  # This example matches pods with the `app: prom-example` label
  selector:
    matchLabels:
      app: prom-example
  podMetricsEndpoints:
    # port is the name of the port of the container to be scraped.
  - port: metrics-port
    # path is the path of the endpoint to be scraped.
    # Default /metrics
    path: /metrics
    # scheme is the scheme of the endpoint to be scraped.
    # Default http
    scheme: http
    # interval is the time interval at which metrics should
    # be scraped. Default 60s
    interval: 20s

次の PodMonitor リソースを作成します。
```
kubectl apply -f my-pod-monitor.yaml
```
PodMonitor リソースを作成すると、GKE ワークロード指標パイプラインでは、適切な Pod を検出して定期的な収集が自動的に開始されます。パイプラインでは収集した指標が Cloud Monitoring に送信されます
PodMonitor でラベルと Namespace が正しく設定されていることを確認します。PodMonitor カスタムリソースの namespace と matchLabels を反映するように、以下の NAMESPACE と SELECTOR の値を更新します。次のコマンドを実行します。
```
NAMESPACE=gke-workload-metrics
SELECTOR=app=prom-example
kubectl get pods --namespace $NAMESPACE --selector $SELECTOR
```
次のような結果が表示されます。
```
NAME                            READY   STATUS    RESTARTS   AGE
prom-example-7cff4db5fc-wp8lw   1/1     Running   0          39m
```
PodMonitor が Ready 状態であることを確認します。

次のコマンドを実行して、クラスタにインストールしたすべての PodMonitor を確認します。
```
kubectl get podmonitor.monitoring.gke.io --all-namespaces
```
次のような出力が表示されます。
```
NAMESPACE              NAME      AGE
gke-workload-metrics   example   2m36s
```
返された結果から関連する PodMonitor を特定し、次のコマンドを実行します（下記のコマンドの example は PodMonitor の名前に置き換えます）。
```
kubectl describe podmonitor.monitoring.gke.io example --namespace gke-workload-metrics
```
kubectl describe から返された結果を調べて、Ready 条件が True であることを確認します。Ready が False の場合は、準備完了ではない理由を示すイベントを探します。
次に、これらの指標が実際に Cloud Monitoring によって受信されていることを確認します。Google Cloud コンソールの [Cloud Monitoring] セクションで、Metrics Explorer に移動します。
[Metric] フィールドに「example_requests_total」と入力します。
表示されたプルダウンメニューで、[workload.googleapis.com/example_requests_total] を選択します。

次の example_requests_total 指標は、サンプルアプリケーションによって出力される Prometheus 指標の一つです。

プルダウンメニューが表示されない場合や、プルダウンメニューに workload.googleapis.com/example_requests_total が表示されない場合には、数分後にもう一度お試しください。

すべての指標は、収集元の Kubernetes コンテナ（k8s_container）リソースに関連付けられます。Metrics Explorer の [Resource type] フィールドを使用して、k8s_container を選択できます。namespace_name や pod_name などのラベルでグループ化することもできます。

この指標は、Cloud Monitoring 内の任意の場所で使用することも、Cloud Monitoring API を介してクエリすることもできます。たとえば、このダッシュボードを既存のダッシュボードや新しいダッシュボードに追加するには、右上にある [Save Chart] ボタンをクリックして、ダイアログウィンドウで目的のダッシュボードを選択します。

Cloud Monitoring API へ送信されるエラーを確認する

Cloud Monitoring に送信される指標は、カスタム指標の上限内に収める必要があります。エラーは Cloud Monitoring の監査ログに表示されます。

Cloud Logging のログエクスプローラを使用して、このログフィルタでログを確認します（PROJECT_ID は実際のプロジェクト名に置き換えます）。

resource.type="audited_resource"
resource.labels.service="monitoring.googleapis.com"
protoPayload.authenticationInfo.principalEmail=~".*-compute@developer.gserviceaccount.com"
resource.labels.project_id="[PROJECT_ID]"
severity>=ERROR

これにより、クラスタからの書き込みだけでなく、プロジェクトの Cloud Monitoring へのすべての書き込みでのエラーが表示されます。

Cloud Monitoring の取り込み割り当てを確認する

Cloud Monitoring API の割り当てページに移動します
関連するプロジェクトを選択します。
[Time series ingestion requests] セクションを開きます。
[Time series ingestionrequests per minute] の [割り当て超過エラーの数] が 0 であることを確認します（その場合、「割り当て超過エラーの数」グラフに「No data is available for the selected tim」と表示されます）。
ピーク使用率が 100% を超える場合は、Pod の数を少なくすること、指標の数を少なくすること、または monitoring.googleapis.com/ingestion_requests 割り当ての割り当て上限のリクエスト増加することを検討します。

DaemonSet がデプロイされていることを確認する

クラスタにワークロード指標の DaemonSet がデプロイされていることを確認します。期待どおりに動作していることを確認するには、kubectl を使用します。

Google Cloud CLI を使用して認証情報を初期化し、kubectl を設定します。
```
gcloud container clusters get-credentials [CLUSTER_ID] --zone=[ZONE]
```
ワークロード指標の DaemonSet が存在し、正常であることを確認します。次のコマンドを実行します。
```
kubectl get ds -n kube-system workload-metrics
```
コンポーネントが正常にデプロイされると、次のような出力が表示されます。
```
NAME               DESIRED   CURRENT   READY   UP-TO-DATE   AVAILABLE   AGE
workload-metrics   3         3         3       3            3           2m
```
上記のレプリカの数は、クラスタ内の Linux GKE ノードの数と一致している必要があります。たとえば、3 つのノードを持つクラスタの場合、DESIRED = 3 になります。数分後、READY と AVAILABLE の数値が DESIRED の数値と一致するはずです。そうでない場合は、デプロイで問題が発生している可能性があります。