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 リポジトリからクラスタへと同期させるポッドです。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
...

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

次のステップ