本頁面說明如何使用 Config Sync 服務層級指標 (SLI)。
如要在 Config Sync 無法正常運作時收到通知，請根據這些 SLI 設定 Prometheus 警報規則。每項 SLI 都包含如何建立快訊規則的範例。如要進一步瞭解如何搭配使用 Prometheus 與 Config Sync，請參閱「使用指標監控 Config Sync」。
容器數量有誤的 Config Sync Pod
如果 Config Sync Pod 的容器數量低於預期，則 Config Sync 可能未執行。您可以設定快訊來偵測這個問題，並檢查 Config Sync Pod，找出部分容器遺失的原因。設定快訊時，建議您將時間間隔設為至少五分鐘，以免收到不必要的快訊。舉例來說，在升級期間，Pod 的容器計數可能會低於目標。
如果您不熟悉預期的容器數量，請參閱「Config Sync Deployments、Pod 和容器」。
Prometheus 快訊規則範例
本節包含的範例會在 Pod 的容器數量不正確時通知您。
如要在根協調器 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如要在命名空間調解程式 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 容器的重新啟動次數達到特定門檻，表示發生問題。舉例來說，如果根協調器容器的記憶體資源不足，就會以 OOMKilled 錯誤重新啟動，直到取得足夠的記憶體為止。
Prometheus 快訊規則範例
如要在 Config Sync 容器重新啟動超過三次時收到通知，請建立下列快訊規則：
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 快訊規則範例
如要在根或命名空間調解器遇到持續性錯誤達兩小時時收到通知，請建立下列警報規則：
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 物件的命名空間。errorclass標籤可有三個值：1xxx、2xxx和9xxx。每個標籤對應不同類型的錯誤：1xxx項錯誤：可修正的設定錯誤2xxx項錯誤：您可能無法修正的伺服器端錯誤9xxx項錯誤：無法修正的內部錯誤
Config Sync 停滯在同步階段
Config Sync 的同步嘗試作業無法中斷。如果來源中的設定過大或過於複雜 (例如來源包含大量 Config Connector 資源)，可能需要超過一小時才能完成這些設定與叢集的同步作業。不過，如果上次成功同步處理已超過兩小時，可能就是有問題。
您可以查看 RootSync 或 RepoSync 狀態，確認目前的同步嘗試是否仍在進行中。如果目前仍在嘗試同步，您可以選擇拆分資料來源，加快每個資料來源的同步速度，或是將警示門檻從兩小時提高到更長的時間。如果沒有正在進行的同步嘗試，表示 Config Sync 調解器已損壞，因為調解器應該會持續重試，直到將設定從來源成功同步至叢集為止。如果發生這種情況，請將問題提交給Google Cloud 支援團隊。
Prometheus 快訊規則範例
如要設定警報規則，在根或命名空間協調器上次成功同步處理的時間超過兩小時時收到通知，請按照下列步驟操作：
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
Config Sync 效能迴歸
升級後，Config Sync 的效能可能會降低。效能回歸可能發生於下列情況：
- 調解 RootSync 或 RepoSync 物件的時間負擔增加
- 調解 ResourceGroup 物件的時間負擔增加
- 從來源將設定同步至叢集的額外時間增加
協調 RootSync 或 RepoSync 物件的時間負擔
reconciler-manager Deployment 會協調 RootSync 和 RepoSync 物件。您可以使用協調 RootSync 或 RepoSync 物件的時間負擔第 90 個百分位數，偵測效能回歸。
Prometheus 快訊規則範例
本節提供 Prometheus 快訊規則範例，當 reconciler-manager 部署作業發生效能回歸時，系統會通知您。
在下列範例中，如果過去 5 小時內，調解 RootSync 或 RepoSync 物件的時間負擔第 90 個百分位數超過 0.1 秒，系統就會在 10 分鐘內傳送通知。您可以建立監控所有叢集或單一叢集的快訊規則。
建立下列規則來監控所有叢集：
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 快訊規則範例
本節包含 Prometheus 快訊規則，可在 resource-group-controller-manager Deployment 發生效能回歸時通知您。
在下列範例中，如果過去 5 小時內，調解 ResourceGroup 物件的時間負荷第 90 百分位數超過 5 秒，系統就會在 10 分鐘內傳送通知。您可以建立監控所有叢集或單一叢集的快訊規則。
建立下列規則來監控所有叢集：
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
從來源將設定同步至叢集的額外時間
根或命名空間調解器會將設定從可靠來源同步至叢集。您可以運用從來源到叢集同步設定的時間負擔第 90 百分位數，偵測效能回歸。
Prometheus 快訊規則範例
本節包含 Prometheus 快訊規則，可在根層級或命名空間協調器 Deployment 發生效能回歸時通知您。
以下範例會傳送通知，指出過去五小時內，所有叢集同步設定的時間負擔第 90 百分位數，在五分鐘內超過一小時。您可以建立監控所有叢集或單一叢集的警示規則。
建立下列規則來監控所有叢集：
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