Config Sync-SLIs verwenden

Auf dieser Seite wird beschrieben, wie Sie die Service Level Indicators (SLIs) von Config Sync verwenden.

Wenn Sie Benachrichtigungen erhalten möchten, wenn Config Sync nicht wie vorgesehen funktioniert, richten Sie Prometheus-Benachrichtigungsregeln auf der Grundlage dieser SLIs ein. Jeder SLI enthält ein Beispiel für das Erstellen einer Benachrichtigungsregel. Weitere Informationen zur Verwendung von Prometheus mit Config Sync finden Sie unter Config Sync mit Messwerten überwachen.

Config Sync-Pods mit falscher Containeranzahl

Wenn die Containeranzahl eines Config Sync-Pods niedriger als erwartet ist, wird Config Sync möglicherweise nicht ausgeführt. Sie können eine Benachrichtigung einrichten, um dieses Problem zu erkennen und den Config Sync-Pod zu überprüfen, um herauszufinden, warum einige Container fehlen. Wir empfehlen, dass Sie das Zeitintervall auf mindestens fünf Minuten festlegen, um unnötige Benachrichtigungen zu vermeiden. Während des Upgrades kann die Containerzahl eines Pods beispielsweise unter das Ziel fallen.

Damit Sie die erwartete Anzahl von Containern besser verstehen, finden Sie in der folgenden Tabelle Details zu den Config Sync-Pods und ihrer erwarteten Containeranzahl:

Pod-Namespace Regex für Pod-Namen Pod-Beschreibung Erwartete Anzahl von Containern Containernamen
config-management-system config-management-operator-.* Ein config-management-operator-Pod wird auf jedem Cluster mit installiertem Anthos Config Management ausgeführt und gleicht ConfigManagement-Objekte ab. 1
  • manager
    		•
    config-management-system reconciler-manager-.* Ein reconciler-manager-Pod wird auf jedem Cluster mit installierter Anthos Config Management ausgeführt und gleicht RootSync- und RepoSync-Objekte ab. 2
  • reconciler-manager
  • otel-agent
    		•
    config-management-system root-reconciler-.* Für jedes RootSync-Objekt wird ein Root-Abgleichs-Pod erstellt. 4 oder 51
  • gcenode-askpass-sidecar2
  • git-sync
  • hydration-controller
  • otel-agent
  • reconciler
    		•
    config-management-system ns-reconciler-.* Für jedes RepoSync-Objekt wird ein Namespace-Abgleichs-Pod erstellt. 4 oder 51
  • gcenode-askpass-sidecar2
  • git-sync
  • hydration-controller
  • otel-agent
  • reconciler
    		•
    config-management-monitoring otel-collector-.* Ein otel-collector-Pod wird auf jedem Cluster mit installiertem Anthos Config Management ausgeführt. Er erfasst Messwerte aus den Config Sync-Komponenten, die unter den Namespaces config-management-system und resource-group-system ausgeführt werden, und exportiert diese Messwerte nach Prometheus und Cloud Monitoring. 1
  • otel-collector
    		•
    resource-group-system resource-group-controller-manager-.* Ein resource-group-controller-manager-Pod wird auf jedem Cluster mit installiertem Anthos Config Management ausgeführt und gleicht ResourceGroup-Objekte ab. Für jedes RootSync- oder RepoSync-Objekt wird ein ResourceGroup-Objekt erstellt, mit dem der Abgleichsstatus der Ressourcen ermittelt wird, die als „Source of Truth“ deklariert sind. 2
  • reconciler-manager
  • otel-agent
    		•
    config-management-system admission-webhook-.* Ein admission-wehbook-Pod wird auf jedem Cluster mit installiertem Anthos Config Management ausgeführt und verhindert, dass andere Controller die von Config Sync verwalteten Ressourcen ändern oder löschen. Der Zulassungs-Webhook für Config Sync ist standardmäßig deaktiviert. 1
  • admission-webhook
    		•

    1 In den meisten Fällen gilt: Wenn spec.sourceType eines RootSync- oder RepoSync-Objekts git ist und spec.git.auth entweder gcenode oder gcpserviceaccount ist, beträgt die Containeranzahl 5. Andernfalls beträgt die Containeranzahl 4. Wenn Ihr Cluster jedoch Webhooks enthält (z. B., wenn Sie Anthos Service Mesh installiert haben), die Sidecar-Container in Pods einfügen, erhöht der Webhook die Gesamtzahl der Container im Abgleichs-Pod. Sie sollten die Zahl hier entsprechend anpassen.

    2 gcenode-askpass-sidecar wird nur installiert, wenn spec.git.auth entweder gcenode oder gcpserviceaccount ist.

    Beispiele für Prometheus-Benachrichtigungsregeln

    Dieser Abschnitt enthält Beispiele, in denen Sie benachrichtigt werden, wenn Pods mit einer falschen Containeranzahl vorhanden sind.

    • Wenn Sie eine Benachrichtigung erhalten möchten, wenn die Containeranzahl eines Root-Abgleichs-Pods unter der erwarteten Anzahl liegt, erstellen Sie die folgende Benachrichtigungsregel:

      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

    • Wenn Sie eine Benachrichtigung erhalten möchten, wenn die Anzahl der Container eines Namespace-Abgleichs-Pods unter der erwarteten Anzahl liegt, erstellen Sie die folgende Benachrichtigungsregel:

      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

    • Wenn Sie eine Benachrichtigung erhalten möchten, wenn die Anzahl der Container eines Abgleichs-Manager-Pods unter der erwarteten Anzahl liegt, erstellen Sie die folgende Benachrichtigungsregel:

      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

    Fehlerhafte Config Sync-Container

    Wenn die Anzahl der Neustarts eines Config Sync-Containers einen bestimmten Grenzwert erreicht, ist ein Fehler aufgetreten. Ein Root-Abgleichcontainer, der nicht genügend Speicherressourcen hat, wird beispielsweise mit dem Fehler OOMKilled neu gestartet, bis genügend Arbeitsspeicher vorhanden ist.

    Beispiel für eine Prometheus-Benachrichtigungsregel

    Wenn Sie eine Benachrichtigung erhalten möchten, wenn ein Config Sync-Container mehr als dreimal neu gestartet wurde, erstellen Sie die folgende Benachrichtigungsregel:

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

    Bei Config Sync treten dauerhafte Fehler auf

    Wenn in Config Sync dauerhaft Fehler auftreten, ist ein Fehler aufgetreten. Wenn Config Sync Fehler feststellt, wird die Konfiguration von der Quelle mit einem Cluster so lange wiederholt, bis der Vorgang erfolgreich war. Einige Fehler können jedoch nicht durch einen neuen Versuch behoben werden.

    Beispiel für eine Prometheus-Benachrichtigungsregel

    Erstellen Sie die folgende Benachrichtigungsregel, um eine Benachrichtigung zu erhalten, wenn ein Root- oder Namespace-Abgleicher zwei Stunden lang anhaltende Fehler aufweist:

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

    In diesem Fall gilt Folgendes:

    • Das Label configsync_sync_kind kann die folgenden Werte haben: RootSync oder RepoSync.
    • Das Label configsync_sync_name gibt den Namen eines RootSync- oder RepoSync-Objekts an.
    • Das Label configsync_sync_namespace gibt den Namespace eines RootSync- oder RepoSync-Objekts an.

    • Das Label errorclass kann drei Werte haben: 1xxx, 2xxx und 9xxx. Jedes Label entspricht einem anderen Fehlertyp:

      • 1xxx Fehler: Konfigurationsfehler, die Sie beheben können
      • 2xxx Fehler: Serverfehler, die Sie möglicherweise nicht beheben können
      • 9xxx Fehler: Interne Fehler, die nicht behoben werden können

      Das Label errorclass wird in Anthos Config Management ab Version 1.14.0 unterstützt.

    Config Sync hängt in der Synchronisierungsphase fest

    Ein Synchronisierungsversuch in Config Sync ist nicht unterbrechungsfrei. Wenn die Konfigurationen in der Quelle zu groß oder komplex sind (z. B. wenn die Quelle eine große Anzahl von Config Connector-Ressourcen enthält), kann es mehr als eine Stunde dauern, bis die Synchronisierung dieser Konfigurationen mit dem Cluster abgeschlossen ist. Wenn seit der letzten erfolgreichen Synchronisierung jedoch zwei Stunden vergangen sind, ist möglicherweise ein Fehler aufgetreten.

    Mit dem Status „RootSync“ oder „RepoSync“ können Sie prüfen, ob der aktuelle Synchronisierungsversuch noch aktiv ist. Wenn der aktuelle Synchronisierungsversuch noch läuft, können Sie Ihre Repositories aufteilen, damit jedes Repository schneller synchronisiert werden kann, oder den Schwellenwert für Benachrichtigungen von zwei Stunden auf einen längeren Zeitraum erhöhen. Wenn kein Synchronisierungsversuch läuft, funktioniert der Config Sync-Abgleich nicht, da er wiederholt werden soll, bis er die Konfigurationen von der Quelle mit dem Cluster synchronisiert. In diesem Fall an den Google Cloud-Support eskalieren.

    Beispiel für eine Prometheus-Benachrichtigungsregel

    Erstellen Sie eine der folgenden Benachrichtigungsregeln, um benachrichtigt zu werden, wenn die letzte erfolgreiche Synchronisierung eines Root- oder Namespace-Abgleichs vor mehr als zwei Stunden erfolgt ist.

    • Wenn Sie eine Anthos Config Management-Version 1.14.0 oder höher verwenden, erstellen Sie die folgende Benachrichtigungsregel:

      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

    • Wenn Sie eine Version vor 1.14.0 verwenden, verwenden Sie stattdessen die folgende Regel:

      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

      Sie müssen eine andere Regel erstellen, da in Anthos Config Management-Versionen vor 1.14.0 das commit-Label des Messwerts config_sync_last_sync_timestamp für einige Zeitachsen auf NONE gesetzt werden kann.

    Bei Config Sync treten Leistungsabfälle auf

    Config Sync kann nach dem Upgrade Leistungsabfälle feststellen. Die Leistungsabfälle können auf folgende Arten erfolgen:

    • Eine Erhöhung des Zeitaufwands beim Abgleichen eines RootSync- oder RepoSync-Objekts
    • Anstieg des Zeitaufwands beim Abgleichen eines ResourceGroup-Objekts
    • Anstieg des Zeitaufwands beim Synchronisieren von Konfigurationen von der Quelle mit einem Cluster

    Zeitaufwand für den Abgleich eines RootSync- oder RepoSync-Objekts

    Mit dem reconciler-manager-Deployment werden RootSync- und RepoSync-Objekte abgeglichen. Sie können das 90. Perzentil des Zeitaufwands beim Abgleich eines RootSync- oder RepoSync-Objekts verwenden, um Leistungsabfälle zu erkennen.

    Beispiele für Prometheus-Benachrichtigungsregeln

    Dieser Abschnitt enthält Beispiele für Prometheus-Benachrichtigungsregeln, die Sie benachrichtigen, wenn das reconciler-manager-Deployment Leistungsabfälle aufweist.

    In den folgenden Beispielen wird eine Benachrichtigung gesendet, wenn das 90.Perzentil des Zeitaufwands beim Abgleich eines RootSync- oder RepoSync-Objekts in den letzten 5 Stunden für 10 Minuten über 0,1 Sekunden liegt. Sie können Benachrichtigungsregeln erstellen, die alle Cluster oder einen einzelnen Cluster überwachen.

    • Erstellen Sie die folgende Regel, um alle Cluster zu überwachen:

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

    • Erstellen Sie die folgende Regel, um einen einzelnen Cluster zu überwachen:

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

    Zeitaufwand für den Abgleich eines ResourceGroup-Objekts

    Das resource-group-controller-manager-Deployment gleicht ResourceGroup-Objekte ab. Sie können das 90. Perzentil des Zeitaufwands beim Abgleich einer ResourceGroup verwenden, um Leistungsabfälle zu erkennen.

    Beispiele für Prometheus-Benachrichtigungsregeln

    Dieser Abschnitt enthält Prometheus-Benachrichtigungsregeln, die Sie benachrichtigen, wenn das resource-group-controller-manager-Deployment Leistungsabfälle aufweist.

    In den folgenden Beispielen wird eine Benachrichtigung gesendet, wenn das 90. Perzentil des Zeitaufwands beim Abgleichen eines ResourceGroup-Objekts in den letzten 5 Stunden für 10 Minuten über 5 Sekunden liegt. Sie können Benachrichtigungsregeln erstellen, die alle Cluster oder einen einzelnen Cluster überwachen.

    • Erstellen Sie die folgende Regel, um alle Cluster zu überwachen:

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

    • Erstellen Sie die folgende Regel, um einen einzelnen Cluster zu überwachen:

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

    Der Zeitaufwand für die Synchronisierung von Konfigurationen von der Quelle mit einem Cluster

    Ein Root- oder Namespace-Abgleichsanbieter synchronisiert Konfigurationen von der Datenquelle mit einem Cluster. Sie können das 90. Perzentil des Zeitaufwands beim Synchronisieren von Konfigurationen von der Quelle zu einem Cluster verwenden, um Leistungsabfälle zu erkennen.

    Beispiele für Prometheus-Benachrichtigungsregeln

    Dieser Abschnitt enthält Prometheus-Benachrichtigungsregeln, die Sie informieren, wenn das Deployment des Root- oder Namespace-Abgleichs Leistungsabfälle aufweist.

    In den folgenden Beispielen wird eine Benachrichtigung gesendet, wenn das 90. Perzentil des Zeitaufwands beim Synchronisieren von Konfigurationen in allen Clustern der letzten 5 Stunden für 5 Minuten über eine Stunde liegt. Sie können Benachrichtigungsregeln erstellen, die alle Cluster oder einen einzelnen Cluster überwachen.

    • Erstellen Sie die folgende Regel, um alle Cluster zu überwachen:

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

    • Erstellen Sie die folgende Regel, um einen einzelnen Cluster zu überwachen:

      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