Anthos Config Management のモニタリング

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

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

Config Sync で複数のリポジトリから同期している場合、Prometheus を使用する以外にも、他の方法でリソースをモニタリングできます。詳細については、マルチリポジトリ モードでの Config Sync のモニタリングをご覧ください。

指標の取得

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

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

  • CoreOS によって提供されている 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. 次のコマンドを使用して 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:
    # If you are using multi-repo mode, change config-management-system to config-management-monitoring
    - 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

調整ツールによる指標のクエリ

マルチリポジトリ モードで Config Sync を使用している場合は、RootSync オブジェクトと RepoSync オブジェクトをモニタリングできます。RootSync オブジェクトと RepoSync オブジェクトは、クラスタ上で Anthos Config Management がどのように機能しているかを理解する有用な指標を提供します。ほとんどの指標は調整ツール名でタグ付けされるため、エラーが発生したことを確認し、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 指標を使用してクラスタの 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"}

Config Sync のマルチ リポジトリ モードでは、Git リポジトリからのインポートとソーシング、およびクラスタとの同期は調整ツールによって処理されます。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"}

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

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
...

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

次のステップ