Config Sync のモニタリング

このページでは、Config Sync リソースをモニタリングする方法について説明します。

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

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

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

利用可能な OpenTelemetry 指標

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

Config Sync の指標

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

名前 タイプ タグ 説明
api_duration_seconds 分布 オペレーション、ステータス API サーバー呼び出しのレイテンシの分布
apply_duration_seconds 分布 status アプライヤー リソース同期イベントのレイテンシの分布
apply_operations_total カウント オペレーション、ステータス リソースを信頼できる情報源と同期するために実行されたオペレーションの総数
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 分布 status 調整ツール マネージャーによって処理される調整イベントのレイテンシの分布。
reconciler_errors 前回の値 reconciler、component RootSync および RepoSync 調整ツールで発生したエラーの数
remediate_duration_seconds 分布 status リメディエーター調整イベントのレイテンシの分布
resource_conflicts_total カウント reconciler キャッシュに保存されたリソースとクラスタ リソースの不一致が原因で発生したリソース競合の総数
resource_fights_total カウント reconciler 同期の頻度が高すぎるリソースの総数。結果が 0 より大きい場合は、問題があることを示します。詳細については、KNV2005: ResourceFightWarning をご覧ください。
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 のコンポーネントです。マネージド リソースを追跡し、各リソースの準備状況や調整状況をチェックします。以下の指標は、Anthos Config Management バージョン 1.10 以降で使用できます。

名前 タイプ タグ 説明
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_obvserved 前回の値 name、reconciler、component RootSync と RepoSync のカスタム リソースのステータス。値が 1 の場合は、失敗であることを示します。

Config Sync 指標タグ

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

カスタムタグ

上記の表のタグ列に、各指標のカスタムタグが表示されています。

名前 説明
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 リソースのタイプ

リソースタグ

Config Sync のカスタム モニタリング指標は、K8s_Pod リソースタイプを使用しています。これには次のタグが付いています。

名前 説明
project プロジェクトの ID
cluster_name クラスタの名前
location クラスタのロケーション / ゾーン
namespace_name 指標のエクスポート元の名前空間の名前
pod_name 指標のエクスポート元の Pod の名前

pipeline_error_observ 指標を理解する

pipeline_error_observed 指標は、同期されていないか、目的の状態に調整されていないリソースが含まれている RepoSync または RootSync の CR を迅速に識別するために役立つ指標です。この指標は、Anthos Config Management バージョン 1.10 以降で使用できます。

  • RootSync または RepoSync による同期が正常に完了すると、すべてのコンポーネント(renderingsourcesyncreadiness)の指標が値 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: 指標書き込みロールを持つ 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 です。調整ツールは、Git リポジトリのマニフェストをクラスタに同期します。RootSync オブジェクトを作成すると、Config Sync によって root-reconciler という調整ツールが作成されます。RepoSync オブジェクトを作成すると、Config Sync によって ns-reconciler-NAMESPACE という調整ツールが作成されます。ここで、NAMESPACE は RepoSync オブジェクトを作成した名前空間です。

次の図は、調整ツールの 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 番目のフィールドで [root-reconciler] を選択します。

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

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

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

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

RootSync API と RepoSync API を有効にしている場合、Git リポジトリからの読み込みとソース作成、およびクラスタとの同期は、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] をクリックします。

これで、Git リポジトリからのソーシングの際に調整ツールで発生したエラーを確認できます。

また、ソースと同期プロセスに関する指標を確認することもできます。それには、次の指標のクエリを実行して、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:
          app: prometheus
          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 でアラートを設定できます。

調整ツールは、マニフェストを Git リポジトリからクラスタへと同期させる 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 from the Git repository.
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
...

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

次のステップ