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 秒ごとに取得されます。
マニフェスト ファイルを保持するための一時ディレクトリを作成します。
mkdir acm-monitor cd acm-monitor
curl
コマンドを使用して、CoreOS リポジトリから Promtheus Operator マニフェストをダウンロードします。curl -o bundle.yaml https://raw.githubusercontent.com/coreos/prometheus-operator/master/bundle.yaml
このマニフェストは
default
名前空間を使用するように構成されていますが、これはおすすめしません。次のステップで、monitoring
という名前空間を使用するように構成を変更します。別の名前空間を使用する場合は、残りのステップのmonitoring
の部分をその名前空間で置き換えてください。上記のバンドルに記述された 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
このパッチを適用してマニフェスト内の他のリソースの名前空間を変更する
kustomization.yaml
ファイルを作成します。# kustomization.yaml resources: - bundle.yaml namespace: monitoring patchesStrategicMerge: - patch-crb.yaml
monitoring
名前空間を作成します。名前空間に別の名前を使用できますが、その場合は、前のステップの YAML マニフェストでnamespace
の値も変更します。kubectl create namespace monitoring
次のコマンドを使用して
kustomized
マニフェストを適用します。kubectl apply -k . until kubectl get customresourcedefinitions servicemonitors.monitoring.coreos.com ; \ do date; sleep 1; echo ""; done
クラスタで CRD が使用可能になるまで 2 番目のコマンドはブロックされます。
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
次のコマンドを使用してマニフェストを適用します。
kubectl apply -f acm.yaml until kubectl rollout status statefulset/prometheus-acm -n monitoring; \ do sleep 1; done
Pod が実行されるまで 2 番目のコマンドはブロックされます。
Prometheus サーバーのウェブポートをローカルマシンに転送することでインストールを確認できます。
kubectl -n monitoring port-forward svc/prometheus-acm 9190
http://localhost:9190
で Prometheus のウェブ UI にアクセスできます。一時ディレクトリを削除します。
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 |
ゲージ | 型 | シンカーの調整イベントが発生したときのタイムスタンプ |
クラスタで 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
...
詳細については、ラベルとアノテーションをご覧ください。