Config Sync SLI を使用する

このページでは、Config Sync のサービスレベル指標（SLI）を使用する方法について説明します。

Config Sync が意図したとおりに機能していないときに通知を受け取るには、これらの SLI に基づいて Prometheus アラートルールを設定します。各 SLI には、アラートルールの作成方法の例が含まれています。Config Sync で Prometheus を使用する方法については、指標を使用して Config Sync をモニタリングするをご覧ください。

コンテナ数が正しくない Config Sync Pod

Config Sync Pod のコンテナ数が予想より少ない場合、Config Sync が実行されていない可能性があります。この問題を検出するためのアラートを設定し、Config Sync Pod を調べて一部のコンテナが不足している理由を特定できます。アラートを設定する際は、不要なアラートを回避するために、期間を 5 分以上に設定することをおすすめします。たとえば、アップグレード中に Pod のコンテナ数がターゲットを下回ることがあります。

予想されるコンテナ数を把握できるように、次の表に Config Sync Pod と予想されるコンテナ数の詳細を示します。

Pod の Namespace Pod 名の正規表現 Pod の説明 予想されるコンテナ数 コンテナ名
config-management-system config-management-operator-.* config-management-operator Pod は、Anthos Config Management がインストールされているすべてのクラスタで実行され、ConfigManagement オブジェクトを調整します。 1
  • manager
    		•
    config-management-system reconciler-manager-.* reconciler-manager Pod は、Anthos Config Management がインストールされているすべてのクラスタで実行され、RootSync オブジェクトと RepoSync オブジェクトを調整します。 2
  • reconciler-manager
  • otel-agent
    		•
    config-management-system root-reconciler-.* Root Reconciler Pod は、RootSync オブジェクトごとに作成されます。 4 または 51
  • gcenode-askpass-sidecar2
  • git-sync
  • hydration-controller
  • otel-agent
  • reconciler
    		•
    config-management-system ns-reconciler-.* すべての RepoSync オブジェクトに対して Namespace Reconciler Pod が作成されます。 4 または 51
  • gcenode-askpass-sidecar2
  • git-sync
  • hydration-controller
  • otel-agent
  • reconciler
    		•
    config-management-monitoring otel-collector-.* otel-collector Pod は、Anthos Config Management がインストールされているすべてのクラスタで実行され、config-management-system Namespace と resource-group-system Namespace で実行されている Config Sync コンポーネントから指標を収集します。これらの指標を Prometheus と Cloud Monitoring にエクスポートします。 1
  • otel-collector
    		•
    resource-group-system resource-group-controller-manager-.* resource-group-controller-manager Pod は、Anthos Config Management がインストールされているすべてのクラスタで実行され、ResourceGroup オブジェクトを調整します。RootSync オブジェクトまたは RepoSync オブジェクトごとに ResourceGroup オブジェクトが作成され、信頼できる情報源で宣言されたリソースの調整ステータスを追跡します。 2
  • reconciler-manager
  • otel-agent
    		•
    config-management-system admission-webhook-.* admission-wehbook Pod は、Anthos Config Management がインストールされているすべてのクラスタで実行され、Config Sync によって管理されるリソースを他のコントローラが変更または削除できないようにします。Config Sync アドミッション Webhook はデフォルトで無効になっています。 1
  • admission-webhook
    		•

    1 ほとんどの場合、RootSync オブジェクトまたは RepoSync オブジェクトの spec.sourceType が git であり、spec.git.auth が gcenode または gcpserviceaccount である場合、コンテナ数は 5 です。それ以外の場合、コンテナ数は 4 です。ただし、サイドカー コンテナを Pod に挿入する変更用 Webhook がクラスタにある場合（たとえば、Anthos Service Mesh をインストールした場合）、Webhook は Reconciler Pod 内のコンテナの総数を増やします。この数を適宜調整してください。

    2 gcenode-askpass-sidecar は、spec.git.auth が gcenode または gcpserviceaccount の場合にのみインストールされます。

    Prometheus アラートルールの例

    このセクションでは、コンテナ数が正しくない Pod がある場合に通知する例を示します。

    • Root Reconciler Pod のコンテナ数が予想される数を下回ったときに通知を受け取るには、次のアラートルールを作成します。

      alert: RootReconcilerPodMissingContainer
expr: count by (cluster_name, pod_name) (kubernetes_io:container_uptime{namespace_name="config-management-system", pod_name=~"root-reconciler-.*"}) < 4
# Setting the for field to 5m to avoid unnecessary alerts.
for: 5m

    • Namespace Reconciler Pod のコンテナ数が予想される数を下回ったときに通知を受け取るには、次のアラートルールを作成します。

      alert: NamespaceReconcilerPodMissingContainer
expr: count by (cluster_name, pod_name) (kubernetes_io:container_uptime{namespace_name="config-management-system", pod_name=~"ns-reconciler-.*"}) < 4
for: 5m

    • reconciler-manager Pod のコンテナ数が予想される数を下回ったときに通知を受け取るには、次のアラートルールを作成します。

      alert: ReconcilerManagerPodMissingContainer
expr: count by (cluster_name, pod_name) (kubernetes_io:container_uptime{namespace_name="config-management-system", pod_name=~"reconciler-manager-.*"}) < 2
for: 5m

    異常な Config Sync コンテナ

    Config Sync コンテナの再起動回数が特定のしきい値に達した場合、問題が発生しています。たとえば、十分なメモリリソースがない Root Reconciler コンテナは、十分なメモリを取得するまで OOMKilled エラーで再起動します。

    Prometheus アラートルールの例

    Config Sync コンテナが 3 回以上再起動したときに通知を受け取るには、次のアラートルールを作成します。

    alert: TooManyContainerRestarts
expr: kubernetes_io:container_restart_count{namespace_name=~"config-management-system|config-management-monitoring|resource-group-system"} > 3

    永続的なエラーが発生している Config Sync

    Config Sync で永続的なエラーが発生した場合は、問題が発生しています。Config Sync はエラーを検出すると、成功するまで、ソースからクラスタへの構成ファイルの同期を再試行します。ただし、一部のエラーは再試行しても解決できず、介入が必要になります。

    Prometheus アラートルールの例

    Root Reconciler または Namespace Reconciler で 2 時間にわたり永続的なエラーが発生した場合に通知を受け取るには、次のアラートルールを作成します。

    alert: PersistentConfigSyncErrors
expr: sum by (cluster, configsync_sync_kind, configsync_sync_name, configsync_sync_namespace, errorclass) (config_sync_reconciler_errors) > 0
for: 2h

    この例では、次のようになります。

    • configsync_sync_kind ラベルの値は RootSync または RepoSync のいずれかです。
    • configsync_sync_name ラベルは、RootSync オブジェクトまたは RepoSync オブジェクトの名前を示します。
    • configsync_sync_namespace ラベルは、RootSync オブジェクトまたは RepoSync オブジェクトの Namespace を示します。

    • errorclass ラベルには 1xxx、2xxx、9xxx の 3 つの値があります。各ラベルは、異なるタイプのエラーに対応しています。

      • 1xxx エラー: 修正可能な構成エラー
      • 2xxx エラー: 修正できない可能性のあるサーバー側のエラー
      • 9xxx のエラー: 修正できない内部エラー

      errorclass ラベルは、Anthos Config Management バージョン 1.14.0 以降でサポートされています。

    Config Sync が同期ステージから先に進まない

    Config Sync の同期試行は中断できません。ソース内の構成ファイルが大きすぎるか、複雑である場合（ソースに多数の Config Connector リソースが含まれているなど）、これらの構成ファイルとクラスタとの同期が完了するまでに 1 時間以上かかることがあります。ただし、最後に同期が完了してから 2 時間が経過した場合は、なんらかの問題が発生している可能性があります。

    RootSync または RepoSync のステータスを確認することで、現在の同期が進行中かどうかを確認できます。現在の同期の試行がまだ進行中の場合は、すべてのリポジトリの同期を高速化できるようにリポジトリを分割するか、アラートのしきい値を 2 時間以上に増やすことができます。進行中の試行がない場合、Config Sync Reconciler は、ソースからクラスタに構成ファイルが正常に同期されるまで再試行を続けることになるため、失敗します。その場合は、Google Cloud サポートにエスカレーションします。

    Prometheus アラートルールの例

    Root Reconciler または Namespace Reconciler の最後の同期が 2 時間以上前の場合に通知を受けるには、次のいずれかのアラートルールを作成します。

    • Anthos Config Management バージョン 1.14.0 以降を使用している場合は、次のアラートルールを作成します。

      alert: OldLastSyncTimestamp
# The status label indicates whether the last sync succeeded or not.
# Possible values: success, error.
expr: time() - topk by (cluster, configsync_sync_kind, configsync_sync_name, configsync_sync_namespace) (1, config_sync_last_sync_timestamp{status="success"}) > 7200

    • 1.14.0 より前のバージョンを使用している場合は、次のルールを使用します。

      alert: OldLastSyncTimestamp
expr: time() - topk by (cluster, configsync_sync_kind, configsync_sync_name, configsync_sync_namespace) (1, config_sync_last_sync_timestamp{status="success", status!="NONE"}) > 7200

      1.14.0 より前のバージョンの Anthos Config Management では、一部の時系列に対して config_sync_last_sync_timestamp 指標の commit ラベルを NONE に設定できるため、別のルールを作成する必要があります。

    Config Sync のパフォーマンス低下

    アップグレード後に Config Sync のパフォーマンスが低下することがあります。パフォーマンスの低下には、次の原因が考えられます。

    • RootSync オブジェクトまたは RepoSync オブジェクトを調整する際のオーバーヘッドの増加
    • ResourceGroup オブジェクトを調整する際のオーバーヘッドの増加
    • ソースからクラスタに構成ファイルを同期する際のオーバーヘッドの増加

    RootSync オブジェクトまたは RepoSync オブジェクトを調整する際のオーバーヘッド

    reconciler-manager Deployment は、RootSync オブジェクトと RepoSync オブジェクトを調整します。RootSync オブジェクトまたは RepoSync オブジェクトの調整にかかる時間のオーバーヘッドの 90 パーセンタイルを使用して、パフォーマンスの低下を検出できます。

    Prometheus アラートルールの例

    このセクションでは、reconciler-manager Deployment にパフォーマンスの低下が発生したときに通知する Prometheus アラートルールの例を紹介します。

    次の例では、過去 5 時間の RootSync オブジェクトまたは RepoSync オブジェクトの調整にかかる時間のオーバーヘッドの 90 パーセンタイルが、10 分間で 0.1 秒を超えた場合に通知を送信します。すべてのクラスタまたは単一クラスタをモニタリングするアラートルールを作成できます。

    • すべてのクラスタをモニタリングするには、次のルールを作成します。

      alert: HighLatencyReconcileRootSyncAndRepoSyncOverall
expr: histogram_quantile(0.9, sum by (le) (rate(config_sync_reconcile_duration_seconds_bucket[5h]))) > 0.1
for: 10m

    • 単一クラスタをモニタリングするには、次のルールを作成します。

      alert: HighLatencyReconcileRootSyncAndRepoSyncClusterLevel
expr: histogram_quantile(0.9, sum by (cluster, le) (rate(config_sync_reconcile_duration_seconds_bucket[5h]))) > 0.1
for: 10m

    ResourceGroup オブジェクトを調整する際のオーバーヘッド

    resource-group-controller-manager Deployment は、ResourceGroup オブジェクトを調整します。ResourceGroup の調整にかかる時間のオーバーヘッドの 90 パーセンタイルを使用して、パフォーマンスの低下を検出できます。

    Prometheus アラートルールの例

    このセクションでは、resource-group-controller-manager Deployment にパフォーマンスの低下が発生したときに通知する Prometheus アラートルールを紹介します。

    次の例では、過去 5 時間に ResourceGroup オブジェクトの調整にかかる時間のオーバーヘッドの 90 パーセンタイルが 10 分間で 5 秒を超えた場合に通知を送信します。すべてのクラスタまたは単一クラスタをモニタリングするアラートルールを作成できます。

    • すべてのクラスタをモニタリングするには、次のルールを作成します。

      alert: HighLatencyReconcileResourceGroupOverall
expr: histogram_quantile(0.9, sum by (le) (rate(config_sync_rg_reconcile_duration_seconds_bucket[5h]))) > 5
for: 10m

    • 単一クラスタをモニタリングするには、次のルールを作成します。

      alert: HighLatencyReconcileResourceGroupClusterLevel
expr: histogram_quantile(0.9, sum by (cluster, le) (rate(config_sync_rg_reconcile_duration_seconds_bucket[5h]))) > 5
for: 10m

    ソースからクラスタに構成ファイルを同期する際のオーバーヘッド

    Root Reconciler または Namespace Reconciler は、信頼できるソースからクラスタに構成ファイルを同期します。ソースからクラスタに構成ファイルを同期する時間のオーバーヘッドの 90 パーセンタイルを使用して、パフォーマンスの低下を検出できます。

    Prometheus アラートルールの例

    このセクションでは、Root Reconciler または Namespace Reconciler の Deployment にパフォーマンスの低下が発生したときに通知する Prometheus アラートルールを説明します。

    次の例では、過去 5 時間のすべてのクラスタで構成ファイルの同期にかかる時間のオーバーヘッドの 90 パーセンタイルが、5 分間で 1 時間を超えた場合に通知を送信します。すべてのクラスタ、または単一のクラスタをモニタリングするアラートルールを作成できます。

    • すべてのクラスタをモニタリングするには、次のルールを作成します。

      alert: HighApplyDurationOverall
expr: histogram_quantile(0.9, sum by (le) (rate(config_sync_apply_duration_seconds_bucket[5h]))) > 3600
for: 5m

    • 単一クラスタをモニタリングするには、次のルールを作成します。

      alert: HighApplyDurationRootSyncRepoSyncLevel
expr: histogram_quantile(0.9, sum by (cluster, configsync_sync_kind,configsync_sync_name, configsync_sync_namespace, le) (rate(config_sync_apply_duration_seconds_bucket[5h]))) > 3600
for: 5m