Config Sync überwachen

Auf dieser Seite wird beschrieben, wie Sie Ihre Config Sync-Ressourcen überwachen können.

Wenn Sie die RootSync- und RepoSync-APIs aktivieren, verwendet Config Sync OpenCensus zum Erstellen und Aufzeichnen von Messwerten und OpenTelemetry zum Exportieren der Messwerte in Prometheus undCloud Monitoring. Sie können OpenTelemety auch verwenden, um Messwerte in ein benutzerdefiniertes Monitoringsystem zu exportieren. Dieser Prozess bietet Ihnen drei Möglichkeiten, Ihre Ressourcen zu überwachen:

  1. Cloud Monitoring
  2. Benutzerdefiniertes Monitoringsystem
  3. Prometheus

Wenn Sie die RootSync API und die RepoSync API nicht aktivieren, können Sie nur Ressourcen mit Prometheus überwachen.

Verfügbare OpenTelemetry-Messwerte

Wenn Sie die RootSync API und die RepoSync API aktiviert haben, erfassen Config Sync und der Resource Group Controller die folgenden Messwerte und stellen sie für OpenTelemetry bereit. In der Spalte Tags sind alle Tags aufgeführt, die für die einzelnen Messwerte gelten. Messwerte mit Tags repräsentieren mehrere Messungen, eine für jede Kombination von Tag-Werten.

Config Sync-Messwerte

Die folgenden Messwerte sind ab Anthos Config Management Version 1.10.1 verfügbar.

Name Typ Tags Beschreibung
api_duration_seconds Vertrieb Vorgang, Status Latenzverteilung von API-Serveraufrufen
apply_duration_seconds Vertrieb Status Latenzverteilung von Synchronisationsressourcen-Ereignissen
apply_operations_total Anzahl Vorgang, Status Die Gesamtzahl der Vorgänge, die ausgeführt wurden, um Ressourcen mit der "Source of Truth" zu synchronisieren
declared_resources Letzter Wert Abgleich Die Anzahl der deklarierten Ressourcen, die von Git geparst wurden
internal_errors_total Anzahl Abgleich, Quelle Gesamtzahl der internen Fehler, die von Config Sync ausgelöst wurden
last_sync_timestamp Letzter Wert Abgleich Der Zeitstempel der letzten Synchronisierung aus Git
parser_duration_seconds Vertrieb Abgleich, Status, Trigger, Quelle Latenzverteilung der parse-apply-watch-Schleife
pipeline_error_observed Letzter Wert Name, Abgleicher, Komponente Der Status der benutzerdefinierten RootSync- und RepoSync-Ressourcen. Der Wert 1 weist auf einen Fehler hin.
reconcile_duration_seconds Vertrieb Status Die Latenzverteilung der Abgleichereignisse, die vom Abgleicher verarbeitet werden
reconciler_errors Letzter Wert Abgleich, Komponente Die Anzahl der Fehler in den Abgleichen von RootSync und RepoSync
remediate_duration_seconds Vertrieb Status Latenzverteilung von Abgleich-Ereignissen
resource_conflicts_total Anzahl Abgleich Die Gesamtzahl der Ressourcenkonflikte aufgrund einer Diskrepanz zwischen den im Cache gespeicherten Ressourcen und Clusterressourcen
resource_fights_total Anzahl Abgleich Die Gesamtzahl der Ressourcen, die zu häufig synchronisiert werden. Bei einem höheren Wert als null wird ein Problem angezeigt. Weitere Informationen finden Sie unter KNV2005: ResourceFightWarning.
rendering_count_total Anzahl Abgleich Die Anzahl der Synchronisierungsausführungen, die das Rendering von Kustomize- oder Helm-Diagrammen für die Ressourcen verwendet haben.
skip_rendering_count_total Anzahl Abgleich Die Anzahl der Synchronisierungsausführungen, die nicht Kustomize- oder Helm-Diagramme auf den Ressourcen verwendet haben.
resource_override_count_total Anzahl Abgleicher, Container, Ressource Die Anzahl der im Ressourcen-Patch angegebenen Ressourcenüberschreibungen
git_sync_depth_override_count_total Anzahl - Die Anzahl der Root/RepoSync-Objekte, bei denen die Überschreibung spec.override.gitSyncDepth festgelegt ist. Git-Depth kann zur Verbesserung der Leistung bei der Synchronisierung aus großen Repositories verwendet werden.
no_ssl_verify_count_total Anzahl - Die Anzahl der Root/RepoSync-Objekte, bei der die Überschreibung .spec.git.noSSLVerify festgelegt ist.

Messwerte von Resource Group Controller

Der Resource Group Controller ist eine Komponente in Config Sync, die die verwalteten Ressourcen verfolgt und prüft, ob jede einzelne Ressource bereit oder abgeglichen ist. Die folgenden Messwerte sind ab Anthos Config Management Version 1.10 verfügbar.

Name Typ Tags Beschreibung
reconcile_duration_seconds Vertrieb stallreason Die Verteilung der Zeit, die zum Abgleich einer ResourceGroup-CR benötigt wird
resource_group_total Letzter Wert Die aktuelle Anzahl der ResourceGroup-CRs
resource_count_total Summe Die Gesamtzahl der Ressourcen, die von allen ResourceGroup-CRs im Cluster verfolgt werden
resource_count Letzter Wert resourcegroup Die Gesamtzahl der Ressourcen, die von einer ResourceGroup verfolgt werden
ready_resource_count_total Summe Die Gesamtzahl der Ressourcen, die für alle ResourceGroup-CRs im Cluster bereit sind
ready_resource_count Letzter Wert resourcegroup Die Gesamtzahl der einsatzbereiten Ressourcen in einer ResourceGroup
resource_ns_count Letzter Wert resourcegorup Die Anzahl der Namespaces, die von Ressourcen in einer ResourceGroup verwendet werden
cluster_scoped_resource_count Letzter Wert resourcegroup Die Anzahl der clusterbezogenen Ressourcen in einer ResourceGroup
crd_count Letzter Wert resourcegroup Die Anzahl der CRDs in einer ResourceGroup
kcc_resource_count_total Summe Die Gesamtzahl der Config Connector-Ressourcen für alle ResourceGroup-CRs im Cluster
kcc_resource_count Gauge resourcegroup Die Gesamtzahl der KCC-Ressourcen in einer ResourceGroup
pipeline_error_observed Letzter Wert Name, Abgleicher, Komponente Der Status der benutzerdefinierten RootSync- und RepoSync-Ressourcen. Der Wert 1 weist auf einen Fehler hin.

Config Sync-Messwert-Tags

Messwert-Tags können zum Aggregieren von Messwertdaten verwendet werden. Sie können in der Drop-down-Liste "Gruppieren nach" der Monitoring-Konsole ausgewählt werden.

Benutzerdefinierte Tags

Die benutzerdefinierten Tags werden für jeden Messwert in der obigen Tag-Spalte aufgelistet.

Name Werte Beschreibung
operation erstellen, patchen, aktualisieren, löschen Die Art des ausgeführten Vorgangs
status Erfolg, Fehler Ausführungsstatus eines Vorgangs
reconciler Rootsync, Reposync Der Typ des Abgleichers
source parser, differ, remediator Ursache des internen Fehlers
trigger retry, watchUpdate, managementConflict, resync, reimport Der Trigger eines Abgleichsereignisses
name Der Name des Abgleichers Der Name des Abgleichers
component Parsen, Quelle, Synchronisierung, Rendering, Bereitschaft Der Name der Komponente / Stufe, in der sich die Abgleichung gerade befindet
container Abgleicher, git-sync Der Name des Containers
resource CPU, Arbeitsspeicher Der type der Ressource

Ressourcen-Tags

Benutzerdefinierte Monitoring-Messwerte für Config Sync verwenden den Ressourcentyp K8s_Pod, der die folgenden Tags umfasst

Name Beschreibung
project Die ID des Projekts
cluster_name Den Namen des Clusters.
location Der Standort / die Zone des Clusters
namespace_name Der Name des Namespace, aus dem die Messwerte exportiert werden
pod_name Der Name des Pods, aus dem die Messwerte exportiert werden

Informationen zum Messwert "pipeline_error_observing"

Der Messwert pipeline_error_observed ist ein Messwert, mit dem Sie RepoSync- oder RootSync-CRs schnell identifizieren können, die nicht synchron sind oder Ressourcen enthalten, die nicht mit dem gewünschten Status abgeglichen werden. Dieser Messwert ist ab Anthos Config Management Version 1.10 verfügbar.

  • Bei einer erfolgreichen Synchronisierung durch eine RootSync oder RepoSync werden die Messwerte mit allen Komponenten (rendering, source, sync, readiness) mit dem Wert 0 beobachtet.

    Screenshot des Messwerts "pipeline_error_oblived" mit allen für den Wert 0 beobachteten Komponenten

  • Wenn der letzte Commit das automatische Rendering nicht besteht, wird der Messwert mit der Komponente rendering mit dem Wert 1 beobachtet.

  • Wenn der letzte Commit einen Fehler feststellt oder der letzte Commit eine ungültige Konfiguration enthält, wird der Messwert mit der Komponente source mit dem Wert 1 beobachtet.

  • Wenn eine Ressource nicht auf den Cluster angewendet werden kann, wird der Messwert mit der Komponente sync mit dem Wert 1 beobachtet.

  • Wenn eine Ressource angewendet wird, aber nicht den gewünschten Status erreicht, wird der Messwert mit der Komponente readiness mit dem Wert 1 beobachtet. Beispiel: Eine Bereitstellung wird auf den Cluster angewendet, aber die entsprechenden Pods werden nicht erfolgreich erstellt.

Ressourcen mit Cloud Monitoring beobachten

Wenn Config Sync in einer Google Cloud-Umgebung mit einem Standarddienstkonto ausgeführt wird, exportiert Config Sync automatisch Messwerte nach Cloud Monitoring.

Führen Sie die folgenden Schritte aus, wenn Workload Identity aktiviert ist:

  1. Binden Sie das Kubernetes-Dienstkonto default im Namespace config-management-monitoring an ein Google-Dienstkonto mit der Rolle "Messwertautor":

    gcloud iam service-accounts add-iam-policy-binding \
        --role roles/iam.workloadIdentityUser \
        --member "serviceAccount:PROJECT_ID.svc.id.goog[config-management-monitoring/default]" \
        GSA_NAME@PROJECT_ID.iam.gserviceaccount.com
    

    Ersetzen Sie Folgendes:

    • PROJECT_ID: Ihre Projekt-ID
    • GSA_NAME: das Google-Dienstkonto mit der Rolle des Messwert-Autors

    Für diese Aktion ist die Berechtigung iam.serviceAccounts.setIamPolicy für das Projekt erforderlich.

  2. Annotieren Sie dann das Kubernetes-Dienstkonto mit der E-Mail-Adresse des Google-Dienstkontos.

    kubectl annotate serviceaccount \
        --namespace config-management-monitoring \
        default \
        iam.gke.io/gcp-service-account=GSA_NAME@PROJECT_ID.iam.gserviceaccount.com
    

Beispiele zum Aufrufen dieser Messwerte finden Sie im folgenden Abschnitt zur Fehlerbehebung und im Artikel OpenCensus-Messwerte in Cloud Monitoring.

Beispiel für Debugging-Verfahren für Cloud Monitoring

Die folgenden Cloud Monitoring-Beispiele veranschaulichen einige Muster für die Verwendung von OpenCensus-Messwerten, um Probleme im Zusammenhang mit Config Sync zu erkennen und zu diagnostizieren, wenn Sie die RootSync- und RepoSync APIs verwenden.

Messwertformat

In Cloud Monitoring haben Messwerte das folgende Format: custom.googleapis.com/opencensus/config_sync/METRIC.

Dieser Messwertname besteht aus folgenden Komponenten:

  • custom.googleapis.com: Alle benutzerdefinierten Messwerte haben dieses Präfix
  • opencensus: Dieses Präfix wird hinzugefügt, da Config Sync die OpenCensus-Bibliothek verwendet
  • config_sync/: Messwerte, die von Config Sync nach Cloud Monitoring exportiert werden, haben dieses Präfix
  • METRIC: der Name des abzufragenden Messwerts

Messwerte nach Abgleich abfragen

RootSync- und RepoSync-Objekte sind mit allgemeinen Messwerten instrumentiert, die Ihnen Einblick in die Funktionsweise von Config Sync im Cluster geben. Fast alle Messwerte sind mit dem Abgleichernamen gekennzeichnet, sodass Sie sehen können, ob Fehler aufgetreten sind, und Sie können in Cloud Monitoring Benachrichtigungen für sie einrichten.

Ein Abgleich ist ein Pod, der als Deployment bereitgestellt wird. Damit werden Manifeste aus einem Git-Repository mit einem Cluster synchronisiert. Wenn Sie ein RootSync-Objekt erstellen, erstellt Config Sync einen Abgleich mit dem Namen root-reconciler. Wenn Sie ein RepoSync-Objekt erstellen, erstellt Config Sync einen Abgleich mit dem Namen ns-reconciler-NAMESPACE, wobei NAMESPACE der Namespace ist, in dem Sie das RepoSync-Objekt erstellt haben.

Das folgende Diagramm zeigt, wie Abgleich-Pods funktionieren:

Abgleichsablauf

Führen Sie die folgenden Aufgaben aus, um beispielsweise bei Verwendung von Cloud Monitoring nach dem Namen der Abgleicher zu filtern:

  1. Wechseln Sie in der Google Cloud Console zu Monitoring:

    Zu Monitoring

  2. Klicken Sie im Navigationsbereich Monitoring auf -Metrics Explorer.

  3. Fügen Sie in der Drop-down-Liste Messwert auswählen Folgendes hinzu: custom.googleapis.com/opencensus/config_sync/reconciler_errors.

  4. Wählen Sie in der Drop-down-Liste Filter den Eintrag root_reconciler aus. Ein Filterfeldfeld wird geöffnet.

  5. Wählen Sie im Feld mit den Filterfeldern im ersten Feld = und im zweiten root-reconciler aus.

  6. Klicken Sie auf Anwenden.

Sie können jetzt Messwerte für Ihre RootSync-Objekte abrufen.

Eine Anleitung zum Filtern nach einem bestimmten Datentyp finden Sie unter Daten filtern.

Config Sync-Vorgänge nach Komponente und Status abfragen

Wenn Sie die RootSync- und RepoSync-APIs aktiviert haben, werden die Importe aus einem Git-Repository importiert und von dort übernommen sowie von einem Abgleich abgeglichen. Der Messwert reconciler_errors ist nach Komponenten gekennzeichnet, damit Sie sehen können, wo Fehler aufgetreten sind.

Führen Sie die folgenden Aufgaben aus, um beispielsweise bei Verwendung von Cloud Monitoring nach Komponenten zu filtern:

  1. Wechseln Sie in der Google Cloud Console zu Monitoring:

    Zu Monitoring

  2. Klicken Sie im Navigationsbereich Monitoring auf -Metrics Explorer.

  3. Fügen Sie in der Drop-down-Liste Messwert auswählen custom.googleapis.com/opencensus/config_sync/reconciler_errors hinzu.

  4. Wählen Sie in der Drop-down-Liste Filter die Option Komponente aus. Ein Filterfeldfeld wird geöffnet.

  5. Wählen Sie im Feld mit den Filterfeldern im ersten Feld = und im zweiten source aus.

  6. Klicken Sie auf Anwenden.

Sie können jetzt Fehler sehen, die beim Beobachten aus einem Git-Repository für Ihre Abgleicher aufgetreten sind.

Sie können auch die Messwerte für den Quell- und Synchronisierungsprozess selbst prüfen, indem Sie die folgenden Messwerte abfragen und nach dem Tag status filtern:

custom.googleapis.com/opencensus/config_sync/parser_duration_seconds
custom.googleapis.com/opencensus/config_sync/apply_duration_seconds
custom.googleapis.com/opencensus/config_sync/remediate_duration_seconds

Benutzerdefinierten OpenTelemetry-Exporteur konfigurieren

Wenn Sie Ihre Messwerte an ein anderes Monitoringsystem senden möchten, können Sie die OpenTelemetry-Konfiguration ändern. Eine Liste der unterstützten Monitoringsysteme finden Sie unter OpenTelemetry Collector Exporter und OpenTelemetry Collector-Contrib Exporters.

OpenTelemetry-Monitoringressourcen werden in einem separaten config-management-monitoring-Namespace verwaltet. Um einen benutzerdefinierten OpenTelemetry-Exporter für Config Sync zu konfigurieren, müssen Sie eine ConfigMap mit dem Namen otel-collector-custom in diesem config-management-monitoring-Namespace erstellen. Die ConfigMap sollte einen otel-collector-config.yaml-Schlüssel enthalten und der Wert sollte der Dateiinhalt der benutzerdefinierten OpenTelemetry-Konfiguration sein. Weitere Informationen zu den Konfigurationsoptionen finden Sie in der Konfigurationsdokumentation zu OpenTelemetry Collector.

Die folgende ConfigMap ist ein Beispiel für eine ConfigMap mit einem benutzerdefinierten Logging-Exporter:

# otel-collector-custom-cm.yaml
apiVersion: v1
kind: ConfigMap
metadata:
  name: otel-collector-custom
  namespace: config-management-monitoring
  labels:
    app: opentelemetry
    component: otel-collector
data:
  otel-collector-config.yaml: |
    receivers:
      opencensus:
    exporters:
      logging:
        logLevel: debug
    processors:
      batch:
    extensions:
      health_check:
    service:
      extensions: [health_check]
      pipelines:
        metrics:
          receivers: [opencensus]
          processors: [batch]
          exporters: [logging]

Alle benutzerdefinierten Konfigurationen müssen einen opencensus-Empfänger und eine metrics-Pipeline definieren. Die restlichen Felder sind optional und konfigurierbar. Wir empfehlen jedoch, wie im Beispiel eine batch-Prozessor- und eine Systemdiagnoseerweiterung anzugeben.

Nachdem Sie die ConfigMap erstellt haben, verwenden Sie kubectl, um die Ressource zu erstellen:

kubectl apply -f otel-collector-custom-cm.yaml

Das OpenTelemetry-Collector-Deployment erfasst diese ConfigMap und startet automatisch neu, um die benutzerdefinierte Konfiguration anzuwenden.

Ressourcen mit Prometheus überwachen

Config Sync nutzt Prometheus, um Messwerte zu internen Prozessen zu erfassen und anzuzeigen.

Sie haben auch die Möglichkeit, Cloud Monitoring so zu konfigurieren, dass benutzerdefinierte Messwerte von Prometheus abgerufen werden. Dann können Sie benutzerdefinierte Messwerte in Prometheus und in Monitoring aufrufen. Weitere Informationen finden Sie unter Prometheus verwenden.

Messwerte abrufen

Alle Messwerte können per Scraping an Port 8675 abgerufen werden. Bevor Sie Messwerte abrufen können, müssen Sie Ihren Cluster für Prometheus konfigurieren. Sie haben folgende Möglichkeiten:

  • Sie können den Cluster gemäß der Prometheus-Dokumentation für Scraping konfigurieren oder

  • Sie verwenden den Prometheus-Operator zusammen mit den folgenden Manifesten, die alle Anthos Config Management-Messwerte alle 10 Sekunden extrahieren.

    1. Erstellen Sie ein temporäres Verzeichnis für die Manifestdateien.

      mkdir acm-monitor
      cd acm-monitor
      
    2. Laden Sie das Prometheus Operator-Manifest aus dem CoreOS-Repository mit dem Befehl curl herunter:

      curl -o bundle.yaml https://raw.githubusercontent.com/coreos/prometheus-operator/master/bundle.yaml
      

      Dieses Manifest ist für die Verwendung des Namespace default konfiguriert. Dieser wird nicht empfohlen. Im nächsten Schritt wird daher die Konfiguration so geändert, dass stattdessen ein Namespace namens monitoring genutzt wird. Wenn Sie einen anderen Namespace verwenden möchten, ersetzen Sie in den nachfolgenden Schritten monitoring durch den gewünschten Namespace.

    3. Erstellen Sie eine Datei, um den Namespace des ClusterRoleBinding im obigen Bundle zu aktualisieren.

      # 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
      
    4. Erstellen Sie eine Datei kustomization.yaml, die den Patch anwendet und den Namespace für andere Ressourcen im Manifest ändert.

      # kustomization.yaml
      resources:
      - bundle.yaml
      
      namespace: monitoring
      
      patchesStrategicMerge:
      - patch-crb.yaml
      
    5. Erstellen Sie den Namespace monitoring, falls noch keiner vorhanden ist. Sie können dem Namespace einen anderen Namen geben, müssen dann aber auch den Wert für namespace in den YAML-Manifesten aus den vorherigen Schritten ändern.

      kubectl create namespace monitoring
      
    6. Führen Sie den folgenden Befehl aus, um das Manifest anzuwenden:

      kubectl apply -k .
      
      until kubectl get customresourcedefinitions servicemonitors.monitoring.coreos.com ; \
      do date; sleep 1; echo ""; done

      Der zweite Befehl wird blockiert, bis die CRDs im Cluster verfügbar sind.

    7. Erstellen Sie das Manifest für die Ressourcen, die zum Konfigurieren eines Prometheus-Servers erforderlich sind, mit dem Messwerte aus Anthos Config Management entfernt werden.

      # acm.yaml
      apiVersion: v1
      kind: ServiceAccount
      metadata:
        name: prometheus-acm
        namespace: monitoring
      ---
      apiVersion: rbac.authorization.k8s.io/v1
      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/v1
      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 RootSync and RepoSync APIs, change
          # config-management-system to config-management-monitoring
          - config-management-system
        endpoints:
        - port: metrics
          interval: 10s
      ---
      
    8. Führen Sie den folgenden Befehl aus, um das Manifest anzuwenden:

      kubectl apply -f acm.yaml
      
      until kubectl rollout status statefulset/prometheus-acm -n monitoring; \
      do sleep 1; done
      

      Der zweite Befehl wird blockiert, bis die Pods ausgeführt werden.

    9. Sie können die Installation prüfen, indem Sie den Webport des Prometheus-Servers an Ihren lokalen Computer weiterleiten.

      kubectl -n monitoring port-forward svc/prometheus-acm 9190
      

      Sie können jetzt unter http://localhost:9190 auf die Prometheus-Web-UI zugreifen.

    10. Entfernen Sie das temporäre Verzeichnis.

      cd ..
      rm -rf acm-monitor
      

Verfügbare Prometheus-Messwerte

Config Sync erfasst die folgenden Messwerte und stellt sie Prometheus zur Verfügung. In der Spalte Labels werden alle Labels aufgelistet, die für jeden Messwert gelten. Messwerte ohne Labels stellen eine einzelne Messung über die Zeit dar, während Messwerte mit Labels mehrere Messungen darstellen, eine für jede Kombination von Labelwerten.

Wenn diese Tabelle nicht mehr synchronisiert ist, können Sie die Messwerte in der Prometheus-Benutzeroberfläche nach Präfix filtern. Alle Messwerte beginnen mit dem Präfix gkeconfig_.

Name Typ Label Beschreibung
gkeconfig_importer_cycle_duration_seconds_bucket Histogramm Status Anzahl der Zyklen, die der Importeur versucht hat, Konfigurationen in den Cluster zu importieren (verteilt auf Buckets nach Dauer jedes Zyklus)
gkeconfig_importer_cycle_duration_seconds_count Histogramm Status Anzahl der Zyklen, die der Importeur versucht hat, Konfigurationen in den Cluster zu importieren (ohne Berücksichtigung der Dauer)
gkeconfig_importer_cycle_duration_seconds_sum Histogramm Status Summe der Dauer aller Zeiträume, die der Importeur versucht hat, Konfigurationen in den Cluster zu importieren
gkeconfig_importer_namespace_configs Gauge Anzahl der Namespace-Konfigurationen im aktuellen Status
gkeconfig_monitor_errors Gauge Komponente Anzahl der Fehler im Konfigurations-Repository, gruppiert nach der Komponente, in der sie aufgetreten sind
gkeconfig_monitor_configs Gauge Status Anzahl der Konfigurationen (Cluster und Namespace), gruppiert nach ihrem Synchronisierungsstatus
gkeconfig_monitor_last_import_timestamp Gauge Zeitstempel des letzten Imports
gkeconfig_monitor_last_sync_timestamp Gauge Zeitstempel der letzten Synchronisierung
gkeconfig_monitor_sync_latency_seconds_bucket Histogramm Anzahl der durchgeführten Import-to-Sync-Messungen (verteilt auf Buckets durch Latenz zwischen beiden)
gkeconfig_monitor_sync_latency_seconds_count Histogramm Anzahl der durchgeführten Import-to-Sync-Messungen (ohne Berücksichtigung der Latenz zwischen beiden)
gkeconfig_monitor_sync_latency_seconds_sum Histogramm Summe der Latenzen aller durchgeführten Import-to-Sync-Messungen
gkeconfig_syncer_api_duration_seconds_bucket Histogramm Vorgang, Typ, Status Anzahl der vom Syncer an den API-Server getätigten Aufrufe (verteilt auf Buckets nach Dauer jedes Aufrufs)
gkeconfig_syncer_api_duration_seconds_count Histogramm Vorgang, Typ, Status Anzahl der Aufrufe des Importeurs an den API-Server (ohne Berücksichtigung der Dauer)
gkeconfig_syncer_api_duration_seconds_sum Histogramm Vorgang, Typ, Status Summe der Dauer aller Aufrufe des Syncers an den API-Server
gkeconfig_syncer_controller_restarts_total Zähler Quelle Gesamtzahl der Neustarts für die Namespace- und Cluster-Konfigurationscontroller
gkeconfig_syncer_operations_total Zähler Vorgang, Typ, Status Gesamtzahl der Vorgänge, um Ressourcen mit Konfigurationen zu synchronisieren
gkeconfig_syncer_reconcile_duration_seconds_bucket Histogramm Typ, Status Anzahl der vom Syncer verarbeiteten Abgleichsereignisse (nach Dauer auf Buckets verteilt)
gkeconfig_syncer_reconcile_duration_seconds_count Histogramm Typ, Status Anzahl der vom Syncer verarbeiteten Abgleichereignisse (ohne Berücksichtigung der Dauer)
gkeconfig_syncer_reconcile_duration_seconds_sum Histogramm Typ, Status Summe der Dauer aller vom Syncer verarbeiteten Abgleichereignisse
gkeconfig_syncer_reconcile_event_timestamps Gauge Typ Zeitstempel, bei denen Syncer-Abgleichsereignisse aufgetreten sind

Beispiel für Debugging-Verfahren für Prometheus

Die folgenden Beispiele veranschaulichen einige Muster für die Verwendung von Prometheus-Messwerten, Objektstatusfeldern und Objektannotationen zum Erkennen und Diagnostizieren von Problemen im Zusammenhang mit Config Sync. Diese Beispiele zeigen, wie Sie mit Monitoring auf hoher Ebene beginnen, ein Problem erkennen und dann Ihre Suche schrittweise verfeinern können, um eine Aufschlüsselung durchzuführen und die Ursache des Problems zu diagnostizieren.

Konfigurationen nach Status abfragen

Der monitor-Prozess bietet allgemeine Messwerte, die nützliche Einblicke in die Gesamtübersicht über die Funktionsweise von Config Sync im Cluster geben. Sie können sehen, ob Fehler aufgetreten sind, und sogar Warnungen für diese einrichten.

gkeconfig_monitor_errors

Messwerte nach Abgleich abfragen

Wenn Sie Config Sync RootSync und RepoSync APIs verwenden, können Sie die RootSync- und RepoSync-Objekte überwachen. Die RootSync- und RepoSync-Objekte sind mit allgemeinen Messwerten instrumentiert, die Ihnen Einblick in die Funktionsweise von Config Sync im Cluster bieten. Fast alle Messwerte sind mit dem Abgleichnamen gekennzeichnet, sodass Sie sehen können, ob Fehler aufgetreten sind, und Sie können in Prometheus Benachrichtigungen für sie einrichten.

Ein Abgleich ist ein Pod, der Manifeste von einem Git-Repository mit einem Cluster synchronisiert. Wenn Sie ein RootSync-Objekt erstellen, erstellt Config Sync einen Abgleich mit dem Namen root-reconciler. Wenn Sie ein RepoSync-Objekt erstellen, erstellt Config Sync einen Abgleich mit dem Namen ns-reconciler-NAMESPACE, wobei NAMESPACE der Namespace ist, in dem Sie das RepoSync-Objekt erstellt haben.

In Prometheus können Sie die folgenden Filter für die Abgleiche verwenden:

# 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 zum Anzeigen von Fehlern verwenden

Zusätzlich zur Verwendung von Prometheus-Messwerten fürs Monitoring des Status von Config Sync in Ihren Clustern können Sie den Befehl nomos status verwenden, mit dem Fehler aus allen Clustern in der Befehlszeile gedruckt werden.

Import- und Synchronisierungsvorgänge nach Status abfragen

Config Sync verwendet einen zweistufigen Prozess, um Konfigurationen aus dem Repository auf einen Cluster anzuwenden. Der Messwert gkeconfig_monitor_errors ist nach Komponenten gekennzeichnet, damit Sie sehen können, wo Fehler aufgetreten sind.

gkeconfig_monitor_errors{component="importer"}
gkeconfig_monitor_errors{component="syncer"}

Sie können auch die Messwerte für die Importeur- und Syncer-Prozesse selbst prüfen.

gkeconfig_importer_cycle_duration_seconds_count{status="error"}
gkeconfig_syncer_reconcile_duration_seconds_count{status="error"}

Wenn Sie die RootSync- und RepoSync-APIs aktiviert haben, werden die Importe aus einem Git-Repository importiert und von dort übernommen sowie von einem Abgleich abgeglichen. Der Messwert reconciler_errors ist nach Komponenten gekennzeichnet, damit Sie sehen können, wo Fehler aufgetreten sind.

In Prometheus können Sie die folgenden Abfragen verwenden:

# 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"}

Sie können auch die Messwerte für den Quell- und Synchronisierungsprozess selbst prüfen:

config_sync_parse_duration_seconds{status="error"}
config_sync_apply_duration_seconds{status="error"}
config_sync_remediate_duration_seconds{status="error"}

Objektstatus einer Konfiguration prüfen

Config Sync definiert zwei benutzerdefinierte Kubernetes-Objekte: ClusterConfig und NamespaceConfig. Diese Objekte definieren ein Statusfeld, das Informationen über die Änderung enthält, die zuletzt auf die Konfiguration angewendet wurde, sowie alle aufgetretenen Fehler. Wenn beispielsweise in einem Namespace mit dem Namen shipping-dev ein Fehler auftritt, können Sie den Status der entsprechenden NamespaceConfig prüfen.

kubectl get namespaceconfig shipping-dev -o yaml

token-Annotation eines Objekts prüfen

Möglicherweise möchten Sie wissen, wann ein verwaltetes Kubernetes-Objekt zuletzt von Config Sync aktualisiert wurde. Jedes verwaltete Objekt wird mit dem Hash des Git-Commits bei der letzten Änderung sowie dem Pfad zu der Konfiguration annotiert, die die Änderung enthielt.

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
...

Weitere Informationen finden Sie unter Labels und Annotationen.

Weitere Informationen