Anthos Config Management のモニタリング

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

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

指標の取得

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

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

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

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

      mkdir acm-monitor
      cd acm-monitor
      
    2. curl コマンドを使用して、CoreOS リポジトリから Prometheus 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. 次のコマンドを使用して kustomized マニフェストを適用します。

      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/v1beta1
      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/v1beta1
      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:
          - config-management-system
        endpoints:
        - port: metrics
          interval: 10s
      ---
      apiVersion: monitoring.coreos.com/v1
      kind: ServiceMonitor
      metadata:
        name: cnrm
        namespace: monitoring
        labels:
          prometheus: config-management
      spec:
        endpoints:
        - interval: 10s
          port: metrics
        namespaceSelector:
          matchNames:
          - cnrm-system
        selector:
          matchLabels:
            cnrm.cloud.google.com/monitored: "true"
            cnrm.cloud.google.com/system: "true"
      ---
      apiVersion: monitoring.coreos.com/v1
      kind: PodMonitor
      metadata:
        name: acm-pod
        namespace: monitoring
        labels:
          prometheus: config-management
      spec:
        selector:
          matchLabels:
            monitored: "true"
        namespaceSelector:
          matchNames:
          - gatekeeper-system
        podMetricsEndpoints:
        - 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
      

利用可能な指標

Anthos Config Management は以下の指標を収集し、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 ゲージ シンカーの調整イベントが発生したときのタイムスタンプ
Config Connector を使用している場合は、Prometheus による Config Connector のモニタリングで指標のリストを見つけることができます。

クラスタで Policy Controller が有効になっている場合、次の追加の指標を使用できます(すべて gatekeeper_ で始まります)。

名前 タイプ ラベル 説明
gatekeeper_audit_duration_seconds ヒストグラム 監査サイクル期間の分布
gatekeeper_audit_last_run_time ゲージ 最後の監査ランタイム以降のエポック タイムスタンプ(浮動小数点数で秒単位で指定)
gatekeeper_constraint_template_ingestion_count 反論 ステータス 制約テンプレートの取り込みアクションの総数
gatekeeper_constraint_template_ingestion_duration_seconds ヒストグラム ステータス 制約テンプレートの取り込み時間の分布
gatekeeper_constraint_templates ゲージ ステータス 現在の制約テンプレート数
gatekeeper_constraints ゲージ enforcement_action、ステータス 現在の制約数
gatekeeper_request_count 反論 admission_status API サーバーからのアドミッション リクエスト数
gatekeeper_request_duration_seconds ヒストグラム admission_status アドミッション リクエスト期間の分布
gatekeeper_violations ゲージ enforcement_action 最後の監査サイクルで検出された監査違反の数
gatekeeper_watch_manager_intended_watch_gvk ゲージ 監視対象の一意の GroupVersionKinds Policy Controller の数。これは、同期されたリソースと制約の組み合わせです。 現在は実装されていません。
gatekeeper_watch_manager_watched_gvk ゲージ 実際に監視している一意の GroupVersionKinds Policy Controller の数。これは、gatekeeper_watch_manager_intended_watch_gvk と同じになるように収束することになっています。現在は実装されていません。
gatekeeper_sync ゲージ 種類、ステータス OPA のキャッシュに複製されたリソースの数
gatekeeper_sync_duration_seconds ヒストグラム オブジェクトの同期期間の分布
gatekeeper_sync_last_run_time ゲージ リソースが最後に同期された時刻

デバッグ手順の例

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

ステータスで構成ファイルを照会する

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

gkeconfig_monitor_errors

nomos status でエラーを表示する

Prometheus 指標を使用してクラスタの Anthos Config Management のステータスを監視することに加えて、コマンドラインですべてのクラスタからエラーを出力する nomos status コマンドを使用できます。

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

Anthos Config Management は 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"}

コンフィグ オブジェクトのステータスを確認する

Anthos Config Management では、2 つのカスタム Kubernetes オブジェクト(ClusterConfig と NamespaceConfig)が定義されています。これらのオブジェクトには、コンフィグに最後に適用された変更と発生したエラーに関する情報を含むステータス フィールドが定義されています。たとえば、shipping-dev という名前空間にエラーがある場合、対応する NamespaceConfig のステータスを確認できます。

kubectl get namespaceconfig shipping-dev -o yaml

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

マネージド Kubernetes オブジェクトが Anthos Config Management によって最後に更新された時期を確認したい場合があります。各マネージド オブジェクトには、最後に変更されたときの 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
...

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

次のステップ