使用 Config Sync SLI

本页面介绍了如何使用 Config Sync 服务等级指标 (SLI)。

如需在 Config Sync 未按预期工作时收到通知，请根据这些 SLI 设置 Prometheus 提醒规则。每个 SLI 都包含一个示例，说明如何创建提醒规则。如需详细了解如何将 Prometheus 与 Config Sync 搭配使用，请参阅使用指标监控 Config Sync。

容器数量不正确的 Config Sync Pod

如果 Config Sync Pod 的容器数量低于预期，则 Config Sync 可能未在运行。您可以设置提醒来检测此问题，并检查 Config Sync Pod 以了解某些容器缺失的原因。设置提醒时，我们建议您将时间间隔设置为至少 5 分钟，以避免不必要的提醒。例如，在升级期间，Pod 的容器数量可能会低于目标值。

如果您不熟悉预期的容器数量，请参阅 Config Sync Deployment、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 提醒规则示例

如需在根或命名空间协调器遇到持续错误超过 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 对象的命名空间。

  • errorclass 标签可能有三个值：1xxx、2xxx、9xxx。每个标签都对应于一种不同的错误类型：

    • 1xxx 错误：您可以修复的配置错误
    • 2xxx 错误：您可能无法修正的服务器端错误
    • 9xxx 错误：您无法修复的内部错误

Config Sync 卡在同步阶段

Config Sync 中的同步尝试是不可中断的。如果来源中的配置过大或过于复杂（例如，来源包含大量 Config Connector 资源），则可能需要一个多小时才能完成将这些配置同步到集群的操作。不过，如果自上次成功同步以来已过去两小时，则可能存在问题。

您可以通过检查 RootSync 或 RepoSync 状态来检查当前同步尝试是否仍在进行中。如果当前同步尝试仍在进行，您可以选择拆分可靠来源，以便更快地同步每个可靠来源，或者将提醒阈值从两个小时增加到更长时间。如果没有正在进行的同步尝试，则 Config Sync 协调器会中断，因为它应该不断重试，直到成功地将配置从来源同步到集群。如果发生这种情况，请上报到 Google Cloud 支持团队。

Prometheus 提醒规则示例

如需在上一次成功的根或命名空间协调器同步超过 2 小时的时候收到通知，请创建提醒规则：

  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 Deployment 性能下降时通知您。

以下示例会在过去 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 部署会协调 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 性能下降时通知您。

以下示例会在过去 5 小时内在所有集群中同步配置的时间开销的第 90 百分位超过 1 小时且持续 5 分钟时通知您。您可以创建监控所有集群或单个集群的提醒规则。

  • 创建以下规则以监控所有集群：

    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