コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。

指標で Config Sync をモニタリングする

このページでは、指標を使用して Config Sync リソースをモニタリングする方法について説明します。Config Sync リソースの健全性とインストール ステータスの概要を確認するには、Config Sync ダッシュボードを使用するか、Google Cloud CLI で Config Sync のステータスを表示します。

RootSync API と RepoSync API を有効にすると、Config Sync は OpenCensus を使用して指標を作成して記録し、OpenTelemetry を使用して指標を Prometheus と Cloud Monitoring にエクスポートします。OpenTelemetry を使用して、カスタム モニタリング システムに指標をエクスポートすることもできます。このプロセスでは、次の 3 つの方法でリソースをモニタリングできます。

  1. Cloud Monitoring
  2. カスタム モニタリング システム
  3. Prometheus

RootSync API と RepoSync API を有効にしない場合は、Prometheus でリソースのモニタリングのみを行うことができます。

利用可能な OpenTelemetry 指標

RootSync API と RepoSync API が有効になっている場合、Config Sync と Resource Group Controller は Opencensus で次の指標を収集し、OpenTelemetry コレクタから使用できるようにします。[タグ] 列には、各指標に適用される Config Sync 固有のタグが一覧表示されます。タグ付きの指標はタグ値の組み合わせごとに 1 つずつ、つまり複数の測定を表します。

Config Sync の指標

以下の指標は、Anthos Config Management バージョン 1.10.1 以降で使用できます。

名前 タイプ タグ 説明
api_duration_seconds 分布 オペレーション、ステータス API サーバー呼び出しのレイテンシの分布
apply_duration_seconds 分布 status アプライヤー リソース同期イベントのレイテンシの分布
apply_operations_total カウント operation、status、controller リソースを信頼できる情報源と同期するために実行されたオペレーションの総数
declared_resources 前回の値 reconciler 解析された、Git 内で宣言されているリソースの数
internal_errors_total カウント reconciler、source Config Sync によってトリガーされた内部エラーの総数
last_sync_timestamp 前回の値 reconciler Git から最後に同期が行われた時刻のタイムスタンプ
parser_duration_seconds 配信 reconciler、status、trigger、source 解析、適用、監視ループのレイテンシの分布
pipeline_error_observed 前回の値 name、reconciler、component RootSync と RepoSync のカスタム リソースのステータス。値が 1 の場合は、失敗であることを示します。
reconcile_duration_seconds 配信 ステータス 調整ツール マネージャーによって処理される調整イベントのレイテンシの分布。
reconciler_errors 前回の値 reconciler、component RootSync および RepoSync 調整ツールで発生したエラーの数
remediate_duration_seconds 分布 status リメディエーター調整イベントのレイテンシの分布
resource_conflicts_total カウント reconciler キャッシュに保存されたリソースとクラスタ リソースの不一致が原因で発生したリソース競合の総数
resource_fights_total カウント reconciler 同期の頻度が高すぎるリソースの総数。結果が 0 より大きい場合は、問題があることを示します。詳細については、KNV2005: ResourceFightWarning をご覧ください。

Anthos Config Management バージョン 1.10.1 と 1.13.1 では、次の指標を使用できます。1.13.1 より前のバージョンを使用している場合、Config Sync はこれらの指標を生成しなくなり、使用できなくなります。

名前 タイプ タグ 説明
rendering_count_total カウント reconciler リソースで Kustomize または Helm チャートのレンダリングを使用して行われた同期の実行回数。
skip_rendering_count_total カウント reconciler リソースで Kustomize または Helm チャートのレンダリングを使用しなかった同期の実行回数。
resource_override_count_total 数 reconciler、container、resource リソースパッチで指定されたリソース オーバーライドの数
git_sync_depth_override_count_total カウント - spec.override.gitSyncDepth オーバーライドが設定されている Root / RepoSync オブジェクトの数。Git 深度を使用して、大規模なリポジトリから同期する際のパフォーマンスを向上させることができます。
no_ssl_verify_count_total カウント - .spec.git.noSSLVerify オーバーライドが設定されている Root / RepoSync オブジェクトの数。

Resource Group Controller の指標

Resource Group Controller は Config Sync のコンポーネントです。マネージド リソースを追跡し、各リソースの準備状況や調整状況をチェックします。以下の指標を選択できます。

名前 タイプ タグ 説明
reconcile_duration_seconds 配信 stallreason ResourceGroup CR の調整にかかった時間の分布
resource_group_total 前回の値 ResourceGroup CR の現在の数
resource_count_total 合計 クラスタ内のすべての ResourceGroup CR で追跡されたリソースの総数
resource_count 前回の値 resourcegroup ResourceGroup で追跡されるリソースの総数
ready_resource_count_total 合計 クラスタ内のすべての ResourceGroup CR で利用可能なリソースの総数
ready_resource_count 前回の値 resourcegroup ResourceGroup の準備完了リソースの総数
resource_ns_count 前回の値 resourcegorup ResourceGroup のリソースで使用される名前空間の数
cluster_scoped_resource_count 前回の値 resourcegroup ResourceGroup 内のクラスタ スコープのリソース数
crd_count 前回の値 resourcegroup ResourceGroup の CRD の数
kcc_resource_count_total 合計 クラスタ内のすべての ResourceGroup CR の Config Connector リソースの合計数
kcc_resource_count ゲージ resourcegroup ResourceGroup の KCC リソースの総数
pipeline_error_observed 前回の値 name、reconciler、component RootSync と RepoSync のカスタム リソースのステータス。値が 1 の場合は、失敗であることを示します。

Config Sync の指標ラベル

指標ラベルは、Cloud Monitoring と Prometheus で指標データを集計するために使用できます。これは、Monitoring コンソールの [グループ条件] プルダウン リストから選択できます。

Cloud Monitoring のラベルと Prometheus の指標ラベルの詳細については、指標モデルのコンポーネントと Prometheus データモデルをご覧ください。

指標ラベル

Config Sync と Resource Group Controller の指標では次のラベルが使用されます。

名前 値 説明
operation create、patch、update、delete 実行されたオペレーションのタイプ
status success、error オペレーションの実行ステータス
reconciler rootsync、reposync Reconciler のタイプ
source parser、differ、remediator 内部エラーのソース
trigger try、watchUpdate、managementConflict、resync、reimport 調整イベントのトリガー
name Reconciler の名前 Reconciler の名前
component parsing、source、sync、rendering、readiness 調整の現在のコンポーネント / ステージの名前
container reconciler、git-sync コンテナの名前
resource cpu、memory リソースのタイプ
controller applier、remediator ルートまたは Namespace Reconciler のコントローラの名前

リソースラベル

Prometheus と Cloud Monitoring に送信される Config Sync の指標には、ソース Pod を識別するために次の指標ラベルが設定されています。

名前 説明
k8s.node.name Pod の名前
k8s.pod.namespace Pod の Namespace
k8s.pod.uid Pod の UID
k8s.pod.ip Pod の IP
k8s.node.name Pod をホストするノードの名前
k8s.deployment.name Pod を所有する Deployment の名前

reconciler Pod から Prometheus と Cloud Monitoring に送信される Config Sync の指標には、Reconciler の構成に使用する RootSync または RepoSync を識別する次の指標ラベルも設定されます。

名前 説明
configsync.sync.kind この Reconciler を構成するリソースの種類: RootSync または RepoSync
configsync.sync.name この Reconciler を構成する RootSync または RepoSync の名前
configsync.sync.namespace この Reconciler を構成する RootSync または RepoSync の Namespace

Cloud Monitoring のリソースラベル

Cloud Monitoring のリソースラベルは、ストレージ内の指標をインデックス登録するために使用されます。つまり、カーディナリティがパフォーマンスの重要な要素である指標ラベルと異なり、カーディナリティによる影響はほとんどありません。詳しくは、モニタリング対象リソースタイプをご覧ください。

Config Sync バージョン 1.14.1 から、Cloud Monitoring に送信される Config Sync の指標では、以前のバージョンで使用されている k8s_pod ではなく、k8s_container リソースタイプが使用されます。これにより、ソース Pod を識別するために次のリソースラベルが設定されます。

名前 説明
container_name コンテナの名前
pod_name Pod の名前
namespace_name Pod の Namespace
location ノードをホストするクラスタのリージョンまたはゾーン
cluster_name ノードをホストするクラスタの名前
project クラスタをホストしているプロジェクトの ID

pipeline_error_observ 指標を理解する

pipeline_error_observed 指標は、同期されていないか、目的の状態に調整されていないリソースが含まれている RepoSync または RootSync の CR を迅速に識別するために役立つ指標です。

  • RootSync または RepoSync による同期が正常に完了すると、すべてのコンポーネント（rendering、source、sync、readiness）の指標が値 0 になります。

    すべてのコンポーネントが値 0 で観測されている pipeline_error_observ 指標のスクリーンショット

  • 最新の commit が自動レンダリングに失敗した場合、コンポーネント rendering の指標は値 1 になります。

  • 最新の commit でエラーが発生するか、最新の commit に無効な構成が含まれている場合、コンポーネント source の指標は値 1 になります。

  • リソースをクラスタに適用できない場合、コンポーネント sync を含む指標が値 1 で観測されます。

  • リソースが適用されたものの、目的の状態に到達できない場合、コンポーネント readiness の指標は 1 の値で観測されます。たとえば、Deployment はクラスタに適用されますが、対応する Pod は正常に作成されません。

Cloud Monitoring でリソースをモニタリングする

デフォルトのサービス アカウントがある Google Cloud 環境内で Config Sync が実行されている場合、Config Sync は Cloud Monitoring に自動的に指標をエクスポートします。

Workload Identity が有効になっている場合は、次の手順を行います。

  1. 名前空間 config-management-monitoring の Kubernetes ServiceAccount default を、指標の書き込みロールを持つ Google サービス アカウントにバインドします。

    gcloud iam service-accounts add-iam-policy-binding \
    --role roles/iam.workloadIdentityUser \
    --member "serviceAccount:PROJECT_ID.svc.id.goog[config-management-monitoring/default]" \
    GSA_NAME@PROJECT_ID.iam.gserviceaccount.com

    次のように置き換えます。

    • PROJECT_ID: プロジェクト ID
    • GSA_NAME: モニタリング指標の書き込み（roles/monitoring.metricWriter）IAM ロールを持つ Google サービス アカウント。このロールを持つサービス アカウントがない場合は、サービス アカウントを作成できます。

    この操作を行うには、プロジェクトに対する iam.serviceAccounts.setIamPolicy 権限が必要です。

  2. Google サービス アカウントのメールアドレスを使用して Kubernetes ServiceAccount にアノテーションを付けます。

    kubectl annotate serviceaccount \
    --namespace config-management-monitoring \
    default \
    iam.gke.io/gcp-service-account=GSA_NAME@PROJECT_ID.iam.gserviceaccount.com

これらの指標を表示する例については、デバッグ手順の例のセクションと Cloud Monitoring の OpenCensus 指標に関する記事をご覧ください。

Cloud Monitoring のデバッグ手順の例

次の Cloud Monitoring の例は、RootSync API と RepoSync API を使用している場合に Config Sync に関連する問題を検出して診断するために OpenCensus 指標を使用するパターンを示しています。

指標の形式

Cloud Monitoring では、指標は custom.googleapis.com/opencensus/config_sync/METRIC の形式になります。

この指標名は、次のコンポーネントで構成されています。

  • custom.googleapis.com: すべてのカスタム指標には、この接頭辞が使用されます
  • opencensus: Config Sync は OpenCensus ライブラリを使用するため、この接頭辞が追加されます
  • config_sync/: Config Sync が Cloud Monitoring にエクスポートする指標には、この接頭辞が使用されます
  • METRIC: クエリ対象の指標の名前

リコンサイラで指標をクエリする

RootSync オブジェクトと RepoSync オブジェクトは概要レベルの指標でインストルメント化されています。これは、クラスタ上で Config Sync がどのように機能しているかを理解する際に役立ちます。ほとんどの指標は調整ツール名でタグ付けされるため、エラーが発生したかどうかを確認できます。こうした指標に対して、Cloud Monitoring でアラートを設定することもできます。

調整ツールは、Deployment としてデプロイされる Pod です。信頼できる情報源からクラスタにマニフェストを同期します。RootSync オブジェクトを作成すると、RootSync の名前が root-sync の場合、Config Sync によって root-reconciler-ROOT_SYNC_NAME または root-reconciler という Reconciler が作成されます。RepoSync オブジェクトを作成すると、RepoSync の名前が repo-sync の場合、Config Sync によって ns-reconciler-NAMESPACE-REPO_SYNC_NAME-REPO_SYNC_NAME_LENGTH または ns-reconciler-NAMESPACE という Reconciler が作成されます。ここで、NAMESPACE は、RepoSync オブジェクトを作成した Namespace です。

次の図は、Reconciler の Pod がどのように機能するかを示しています。

調整ツールのフロー

たとえば、Cloud Monitoring を使用しているときに調整ツール名でフィルタするには、次のタスクを行います。

  1. Google Cloud Console で [Monitoring] に移動します。

    [Monitoring] に移動

  2. [Monitoring] のナビゲーション パネルで、 [Metrics Explorer] をクリックします。

  3. [指標の選択] プルダウン リストで、custom.googleapis.com/opencensus/config_sync/reconciler_errors を追加します。

  4. [Filter] プルダウン リストで [reconciler] を選択します。フィルタ フィールド ボックスが表示されます。

  5. フィルタ フィールド ボックスの最初のフィールドで [=] を選択し、2 番目のフィールドで Reconciler 名（root-reconciler など）を選択します。

  6. [適用] をクリックします。

これで、RootSync オブジェクトの指標を確認できます。

特定のデータタイプでフィルタする手順については、データのフィルタリングをご覧ください。

コンポーネントとステータスで Config Sync オペレーションをクエリする

RootSync API と RepoSync API を有効にしている場合、信頼できる情報源からの読み込みとソース作成、およびクラスタとの同期は、Reconciler によって処理されます。reconciler_errors 指標にはコンポーネント別のラベルが付いているため、エラーの発生場所を確認できます。

たとえば、Cloud Monitoring を使用している場合にコンポーネントを基準にフィルタするには、次のタスクを行います。

  1. Google Cloud Console で [Monitoring] に移動します。

    [Monitoring] に移動

  2. [Monitoring] のナビゲーション パネルで、 [Metrics Explorer] をクリックします。

  3. [指標の選択] プルダウン リストで、custom.googleapis.com/opencensus/config_sync/reconciler_errors を追加します。

  4. [Filter] プルダウン リストで [component] を選択します。フィルタ フィールド ボックスが表示されます。

  5. フィルタ フィールド ボックスの最初のボックスで [=] を選択し、2 番目のボックスで [source] を選択します。

  6. [Apply]（適用）をクリックします。

これで、信頼できるソースからのソーシングの際に調整ツールで発生したエラーを確認できるようになりました。

また、ソースと同期プロセスに関する指標を確認することもできます。それには、次の指標のクエリを実行して、status タグでフィルタします。

custom.googleapis.com/opencensus/config_sync/parser_duration_seconds
custom.googleapis.com/opencensus/config_sync/apply_duration_seconds
custom.googleapis.com/opencensus/config_sync/remediate_duration_seconds

カスタムの OpenTelemetry エクスポータを構成する

OpenTelemetry 構成に変更を加えることで、別のモニタリング システムに指標を送信できます。サポートされているモニタリング システムのリストについては、OpenTelemetry Collector エクスポータと OpenTelemetry Collector-Contrib エクスポータをご覧ください。

OpenTelemetry モニタリング リソースは、別の config-management-monitoring 名前空間で管理されます。Config Sync で使用するカスタムの OpenTelemetry エクスポータを構成するには、config-management-monitoring 名前空間に otel-collector-custom という名前の ConfigMap を作成する必要があります。ConfigMap に otel-collector-config.yaml キーを含めて、その値を OpenTelemetry Collector のカスタム構成ファイルの内容にする必要があります。構成オプションの詳細については、OpenTelemetry Collector の構成に関するドキュメントをご覧ください。

次の ConfigMap は、カスタムの Logging エクスポータを使用する ConfigMap の例です。

# otel-collector-custom-cm.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: otel-collector-custom
  namespace: config-management-monitoring
  labels:
    app: opentelemetry
    component: otel-collector
data:
  otel-collector-config.yaml: |
    receivers:
      opencensus:
    exporters:
      logging:
        logLevel: debug
    processors:
      batch:
    extensions:
      health_check:
    service:
      extensions: [health_check]
      pipelines:
        metrics:
          receivers: [opencensus]
          processors: [batch]
          exporters: [logging]

すべてのカスタム構成で、opencensus レシーバと metrics パイプラインを定義する必要があります。残りのフィールドは必要に応じて構成できますが、この例のように batch プロセッサとヘルスチェック拡張機能を含めることをおすすめします。

ConfigMap を作成したら、kubectl を使用してリソースを作成します。

kubectl apply -f otel-collector-custom-cm.yaml

OpenTelemetry Collector Deployment はこの ConfigMap を選択し、自動的に再起動してカスタム構成を適用します。

Prometheus でリソースをモニタリングする

Config Sync のプロセスに関連する指標の収集と表示には Prometheus が使用されています。

Cloud Monitoring を構成して、Prometheus からカスタム指標を pull することもできます。これにより、Prometheus と Monitoring の両方でカスタム指標を見ることができます。詳細については、Prometheus の使用をご覧ください。

指標をスクレイピングする

すべての Prometheus 指標はポート 8675 でスクレイピングできます。指標を取得するには、次のどちらかの方法を使用してクラスタで Prometheus を構成する必要があります。次のいずれかを実行します。

  • Prometheus のドキュメントに沿って操作し、クラスタで指標の取得を構成します。または

  • Prometheus Operator と以下のマニフェストを使用します。この方法を使用すると、Anthos Config Management のすべての指標が 10 秒ごとに取得されます。

    1. マニフェスト ファイルを保持するための一時ディレクトリを作成します。

      mkdir acm-monitor
cd acm-monitor

    2. curl コマンドを使用して、CoreOS リポジトリから Promtheus Operator マニフェストをダウンロードします。

      curl -o bundle.yaml https://raw.githubusercontent.com/coreos/prometheus-operator/master/bundle.yaml

      このマニフェストは default 名前空間を使用するように構成されていますが、これはおすすめしません。次のステップで、monitoring という名前空間を使用するように構成を変更します。別の名前空間を使用する場合は、残りのステップの monitoring の部分をその名前空間で置き換えてください。

    3. 上記のバンドルに記述された ClusterRoleBinding の名前空間を更新するためのファイルを作成します。

      # patch-crb.yaml
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: prometheus-operator
subjects:
- kind: ServiceAccount
  name: prometheus-operator
  namespace: monitoring # we are patching from default namespace

    4. このパッチを適用してマニフェスト内の他のリソースの名前空間を変更する kustomization.yaml ファイルを作成します。

      # kustomization.yaml
resources:
- bundle.yaml

namespace: monitoring

patchesStrategicMerge:
- patch-crb.yaml

    5. monitoring 名前空間が存在しない場合は、作成します。名前空間に別の名前を使用できますが、その場合は、前のステップの YAML マニフェストで namespace の値も変更します。

      kubectl create namespace monitoring

    6. 次のコマンドを使用して Kustomize マニフェストを適用します。

      kubectl apply -k .

until kubectl get customresourcedefinitions servicemonitors.monitoring.coreos.com ; \
do date; sleep 1; echo ""; done

      クラスタで CRD が使用可能になるまで 2 番目のコマンドはブロックされます。

    7. Anthos Config Management から指標を取得する Prometheus サーバーの構成に必要なリソースのマニフェストを作成します。

      # acm.yaml
apiVersion: v1
kind: ServiceAccount
metadata:
  name: prometheus-acm
  namespace: monitoring
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: prometheus-acm
rules:
- apiGroups: [""]
  resources:
  - nodes
  - services
  - endpoints
  - pods
  verbs: ["get", "list", "watch"]
- apiGroups: [""]
  resources:
  - configmaps
  verbs: ["get"]
- nonResourceURLs: ["/metrics"]
  verbs: ["get"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: prometheus-acm
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: prometheus-acm
subjects:
- kind: ServiceAccount
  name: prometheus-acm
  namespace: monitoring
---
apiVersion: monitoring.coreos.com/v1
kind: Prometheus
metadata:
  name: acm
  namespace: monitoring
  labels:
    prometheus: acm
spec:
  replicas: 2
  serviceAccountName: prometheus-acm
  serviceMonitorSelector:
    matchLabels:
      prometheus: config-management
  podMonitorSelector:
    matchLabels:
      prometheus: config-management
  alerting:
    alertmanagers:
    - namespace: default
      name: alertmanager
      port: web
  resources:
    requests:
      memory: 400Mi
---
apiVersion: v1
kind: Service
metadata:
  name: prometheus-acm
  namespace: monitoring
  labels:
    prometheus: acm
spec:
  type: NodePort
  ports:
  - name: web
    nodePort: 31900
    port: 9190
    protocol: TCP
    targetPort: web
  selector:
    prometheus: acm
---
apiVersion: monitoring.coreos.com/v1
kind: ServiceMonitor
metadata:
  name: acm-service
  namespace: monitoring
  labels:
    prometheus: config-management
spec:
  selector:
    matchLabels:
      monitored: "true"
  namespaceSelector:
    matchNames:
    # If you are using RootSync and RepoSync APIs, change
    # config-management-system to config-management-monitoring
    - config-management-system
  endpoints:
  - port: metrics
    interval: 10s
---

    8. 次のコマンドを使用してマニフェストを適用します。

      kubectl apply -f acm.yaml

until kubectl rollout status statefulset/prometheus-acm -n monitoring; \
do sleep 1; done

      Pod が実行されるまで 2 番目のコマンドはブロックされます。

    9. Prometheus サーバーのウェブポートをローカルマシンに転送することでインストールを確認できます。

      kubectl -n monitoring port-forward svc/prometheus-acm 9190

      http://localhost:9190 で Prometheus のウェブ UI にアクセスできます。

    10. 一時ディレクトリを削除します。

      cd ..
rm -rf acm-monitor

利用可能な Prometheus 指標

Config Sync は以下の指標を収集し、Prometheus を通じて取得できるようにします。[ラベル] 列には、各指標に適用可能なすべてのラベルが一覧表示されます。ラベルのない指標は時間の経過に伴う単一の測定を表す一方、ラベルのある指標はラベル値の組み合わせごとに 1 つずつ、つまり複数の測定を表します。

この表が古くなった場合は、Prometheus のユーザー インターフェースで接頭辞によって指標をフィルタリングできます。該当する指標はすべて接頭辞 gkeconfig_ で始まります。

名前 タイプ ラベル 説明
gkeconfig_importer_cycle_duration_seconds_bucket ヒストグラム ステータス インポーターが構成ファイルをクラスタにインポートしようとしたサイクル数（各サイクルの期間ごとにバケットに分散される）
gkeconfig_importer_cycle_duration_seconds_count ヒストグラム ステータス インポーターが構成ファイルをクラスタにインポートしようとしたサイクル数（期間は無視）
gkeconfig_importer_cycle_duration_seconds_sum ヒストグラム ステータス インポーターが構成ファイルをクラスタにインポートしようとしたすべてのサイクルの期間の合計
gkeconfig_importer_namespace_configs ゲージ 現状の名前空間構成ファイルの数
gkeconfig_monitor_errors ゲージ コンポーネント エラーが発生したコンポーネントごとにグループ化された構成ファイル リポジトリ内のエラーの数
gkeconfig_monitor_configs ゲージ 状態 同期ステータスごとにグループ化された構成ファイル（クラスタと名前空間）の数
gkeconfig_monitor_last_import_timestamp ゲージ 最新のインポートのタイムスタンプ
gkeconfig_monitor_last_sync_timestamp ゲージ 最新の同期のタイムスタンプ
gkeconfig_monitor_sync_latency_seconds_bucket ヒストグラム インポートから同期までの測定数（両者間のレイテンシによってバケットに分散される）
gkeconfig_monitor_sync_latency_seconds_count ヒストグラム インポートから同期までの測定数（両者間のレイテンシは無視）
gkeconfig_monitor_sync_latency_seconds_sum ヒストグラム すべてのインポートから同期までの測定のレイテンシの合計
gkeconfig_syncer_api_duration_seconds_bucket ヒストグラム オペレーション、タイプ、ステータス シンカーが API サーバーに対して行った呼び出し数（各呼び出しの期間ごとにバケットに分散される）
gkeconfig_syncer_api_duration_seconds_count ヒストグラム オペレーション、タイプ、ステータス インポーターが API サーバーに対して行った呼び出し数（期間は無視）
gkeconfig_syncer_api_duration_seconds_sum ヒストグラム オペレーション、タイプ、ステータス シンカーが API サーバーに対して行ったすべての呼び出しの継続期間の合計
gkeconfig_syncer_controller_restarts_total カウンタ ソース 名前空間とクラスタ構成ファイル コントローラの再起動の総数
gkeconfig_syncer_operations_total カウンタ オペレーション、タイプ、ステータス リソースを構成ファイルに同期するために実行されたオペレーションの総数
gkeconfig_syncer_reconcile_duration_seconds_bucket ヒストグラム タイプ、ステータス シンカーが処理した調整イベント数（期間ごとにバケットに分散される）
gkeconfig_syncer_reconcile_duration_seconds_count ヒストグラム タイプ、ステータス シンカーが処理した調整イベントの数（期間は無視）
gkeconfig_syncer_reconcile_duration_seconds_sum ヒストグラム タイプ、ステータス シンカーが処理したすべての調整イベントの継続期間の合計
gkeconfig_syncer_reconcile_event_timestamps ゲージ 型 シンカーの調整イベントが発生したときのタイムスタンプ

Prometheus のデバッグ手順の例

次の例では、Prometheus 指標、オブジェクトのステータス フィールド、オブジェクトのアノテーションを使用して Config Sync 関連の問題を検出し、診断する際のパターンについて説明します。まず、概要レベルのモニタリングで問題を検出し、その後、検索条件を調整して詳細を確認して、問題の根本原因を診断します。

ステータスで構成ファイルをクエリする

monitor プロセスは概要レベルの指標を提供します。これは、クラスタでの Config Sync の全体的な状態を把握する際に役立ちます。これにより、エラーが発生しているかどうかを確認できます。また、エラーに対するアラートも設定できます。

gkeconfig_monitor_errors

リコンサイラで指標をクエリする

Config Sync で RootSync API と RepoSync API を使用している場合は、RootSync オブジェクトと RepoSync オブジェクトをモニタリングできます。RootSync オブジェクトと RepoSync オブジェクトは、クラスタ上で Config Sync がどのように機能しているかを理解する有用な分析情報を提供します。ほとんどの指標はリコンサイラ名でタグ付けされるため、エラーが発生したことを確認し、Prometheus でアラートを設定できます。

調整ツールは、マニフェストを信頼できる情報源からクラスタに同期する Pod です。RootSync オブジェクトを作成すると、Config Sync によって root-reconciler という調整ツールが作成されます。RepoSync オブジェクトを作成すると、Config Sync は ns-reconciler-NAMESPACE という調整ツールを作成します。ここで、NAMESPACE は RepoSync オブジェクトを作成した名前空間です。

Prometheus では、リコンサイラに次のフィルタを使用できます。

# Querying Root reconciler
config_sync_reconciler_errors{root_reconciler="root-reconciler"}

# Querying Namespace reconciler for a namespace called retail
config_sync_reconciler_errors{ns_reconciler_retail="ns-reconciler-retail"}

nomos status を使用してエラーを表示する

Prometheus 指標を使用してクラスタでの Config Sync のステータスをモニタリングするだけでなく、nomos status コマンドを使用すると、コマンドラインでクラスタのエラーを確認できます。

ステータスでインポートと同期オペレーションをクエリする

Config Sync は、リポの構成ファイルを 2 段階でクラスタに適用します。gkeconfig_monitor_errors 指標にはコンポーネント別のラベルが付いているため、エラーの発生場所を確認できます。

gkeconfig_monitor_errors{component="importer"}
gkeconfig_monitor_errors{component="syncer"}

importer プロセスと syncer プロセス自体の指標も確認できます。

gkeconfig_importer_cycle_duration_seconds_count{status="error"}
gkeconfig_syncer_reconcile_duration_seconds_count{status="error"}

RootSync API と RepoSync API を有効にしている場合、Git リポジトリからの読み込みとソース作成、およびクラスタとの同期は、Reconciler によって処理されます。reconciler_errors 指標にはコンポーネント別のラベルが付いているため、エラーの発生場所を確認できます。

Prometheus では、次のクエリを使用できます。

# Check for errors that occurred when sourcing configs.
config_sync_reconciler_errors{component="source"}

# Check for errors that occurred when syncing configs to the cluster.
config_sync_reconciler_errors{component="sync"}

また、ソースと同期プロセスに関する指標を確認することもできます。

config_sync_parse_duration_seconds{status="error"}
config_sync_apply_duration_seconds{status="error"}
config_sync_remediate_duration_seconds{status="error"}

構成ファイルのオブジェクトのステータスを確認する

Config Sync では、2 つのカスタム Kubernetes オブジェクト（ClusterConfig と NamespaceConfig）が定義されています。これらのオブジェクトには、構成ファイルに最後に適用された変更と発生したエラーに関する情報を含むステータス フィールドが定義されています。たとえば、shipping-dev という Namespace にエラーがある場合、対応する NamespaceConfig のステータスを確認できます。

kubectl get namespaceconfig shipping-dev -o yaml

オブジェクトの token アノテーションを確認する

マネージド Kubernetes オブジェクトが Config Sync によって最後に更新された日時を確認できます。各マネージド オブジェクトには、最後に変更されたときの Git commit のハッシュと、その変更を含む構成ファイルのパスがアノテーションとして設定されています。

kubectl get clusterrolebinding namespace-readers

apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  annotations:
    configmanagement.gke.io/source-path: cluster/namespace-reader-clusterrolebinding.yaml
    configmanagement.gke.io/token: bbb6a1e2f3db692b17201da028daff0d38797771
  name: namespace-readers
...

詳細については、ラベルとアノテーションをご覧ください。

Google Cloud Managed Service for Prometheus でリソースをモニタリングする

Google Cloud Managed Service for Prometheus は、Google Cloud の Prometheus 指標向けのフルマネージド マルチクラウド ソリューションです。データ収集では、マネージド データ収集（推奨モード）とセルフデプロイによるデータ収集の 2 つのモードがサポートされています。マネージド データ収集モードで Google Cloud Managed Service for Prometheus を使用して Config Sync のモニタリングを設定するには、次の手順を完了します。

  1. マネージド収集の設定の手順に沿って、クラスタでマネージド Prometheus を有効にします。

  2. 次のサンプル マニフェストを cluster-pod-monitoring-acm-monitoring.yaml として保存します。このマニフェストは、config-management-monitoring Namespace にある otel-collector-* Pod のポート 8675 で Config Sync 指標をスクレイピングするように ClusterPodMonitoring リソースを構成します。ClusterPodMonitoring リソースは、Kubernetes ラベルセレクタを使用して otel-collector-* Pod を検索します。

    apiVersion: monitoring.googleapis.com/v1
kind: ClusterPodMonitoring
metadata:
  name: acm-monitoring
spec:
  selector:
    matchLabels:
      app: opentelemetry
      component: otel-collector
  endpoints:
  - port: 8675
    interval: 10s

  3. マニフェストをクラスタに適用します。

    kubectl apply -f cluster-pod-monitoring-acm-monitoring.yaml

  4. Cloud Monitoring の Managed Service for Prometheus データの手順に沿って、Google Cloud コンソールの Cloud Monitoring の [Metrics Explorer] ページで、Prometheus データがエクスポートされていることを確認します。

次のステップ