Config Sync im Multi-Repo-Modus überwachen

Auf dieser Seite werden die zusätzlichen Möglichkeiten beschrieben, mit denen Sie Ihre Ressourcen überwachen können, wenn Sie Config Sync zum Synchronisieren aus mehreren Repositories verwenden.

Wenn Sie den Multi-Repo-Modus aktivieren, verwendet Config Sync OpenCensus, um Messwerte zu erstellen und aufzuzeichnen und es verwendet OpenTelemetry, um die Messwerte nach Prometheus und Cloud Monitoring zu exportieren. 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. Prometheus: Informationen zur Verwendung von Prometheus finden Sie unter Config Sync mit Prometheus überwachen.
  2. Cloud Monitoring: Informationen zur Verwendung von Cloud Monitoring finden Sie im Abschnitt Ressourcen mit Cloud Monitoring überwachen.
  3. Benutzerdefiniertes Monitoringsystem: Informationen zur Verwendung eines benutzerdefinierten Monitoringsystems finden Sie im Abschnitt Benutzerdefinierten OpenTelemetry-Exporter konfigurieren.

Verfügbare Messwerte

Config Sync erfasst die folgenden Messwerte und stellt sie OpenTelemetry zur Verfügung. 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.

Name Typ Tags Beschreibung
api_duration_seconds Verteilung Abgleich, Vorgang, Typ, Status Latenzverteilung von API-Serveraufrufen
apply_duration_seconds Verteilung Abgleich, Status Latenzverteilung von Synchronisationsressourcen-Ereignissen
apply_operations_total Anzahl Abgleich, Vorgang, Typ, 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_apply_timestamp Letzter Wert Abgleich, Status Der Zeitstempel des letzten Synchronisierungsereignisses für App-Ressourcen
last_sync_timestamp Letzter Wert Abgleich Der Zeitstempel der letzten Synchronisierung aus Git
parse_duration_seconds Verteilung Abgleich, Status Latenzverteilung von Parsing-Ereignissen
parse_errors_total Anzahl Abgleich, Fehlercode Gesamtzahl der Fehler beim Parsen
parser_duration_seconds Verteilung Abgleich, Status, Trigger, Quelle Latenzverteilung der parse-apply-watch-Schleife
reconcile_duration_seconds Verteilung 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 Verteilung Abgleich, Typ, Status Latenzverteilung von Abgleich-Ereignissen
resource_conflicts_total Anzahl Abgleich, Typ Die Gesamtzahl der Ressourcenkonflikte aufgrund einer Diskrepanz zwischen den im Cache gespeicherten Ressourcen und Clusterressourcen
resource_fights_total Anzahl Abgleich, Vorgang, Typ 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.
watch_manager_updates_duration_seconds Verteilung Abgleich, Status Die Latenzverteilung von Updates im Watch Manager
watches Anzahl Abgleich, Typ Die Anzahl der Watches in den deklarierten Ressourcen

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.

Wenn Workload Identity aktiviert ist, müssen Sie das Kubernetes-Dienstkonto default im Namespace config-management-monitoring mit dem folgenden Befehl an ein Google-Dienstkonto mit der Rolle "Messwert-Autor" binden:

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

Dabei gilt:

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

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

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

In den folgenden Cloud Monitoring-Beispielen werden einige Muster zum Verwenden von OpenCensus-Messwerten beschrieben, um Probleme im Zusammenhang mit Config Sync zu erkennen und zu diagnostizieren, wenn Sie den Multi-Repo-Modus 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. Geben Sie im Feld Ressourcentyp und Messwert finden Folgendes ein: custom.googleapis.com/opencensus/config_sync/reconciler_errors.

  4. Wählen Sie in der Drop-down-Liste Filter den Eintrag root_reconcilier 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

Im Multi-Repo-Modus wird der Import und die Beschaffung aus einem Git-Repository und die Synchronisierung mit einem Cluster von den Abgleichern ausgeführt. 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 im Feld Ressourcentyp und Messwert suchen Folgendes hinzu: custom.googleapis.com/opencensus/config_sync/reconciler_errors.

  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/parse_duration_seconds
custom.googleapis.com/opencensus/config_sync/apply_duration_seconds
custom.googleapis.com/opencensus/config_sync/remediate_duration_seconds

Benutzerdefinierten OpenTelemetry-Exporter 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.