Betriebslogs aus Ihrem AO-Projekt erfassen

In diesem Abschnitt wird beschrieben, wie Sie Betriebslogs von einem Dienst in einer GDC-Appliance (Google Distributed Cloud) ohne Internetverbindung für die Systemprotokollierung und Datenbeobachtbarkeit erfassen.

Die Logging-Plattform bietet eine benutzerdefinierte Kubernetes API zum Erfassen von Logs auf Projektebene, die von Ihren Diensten über System-Logging-Ziele generiert werden. Sie müssen eine benutzerdefinierte LoggingTarget-Ressource im Namespace Ihres Projekts im Administratorcluster der Organisation bereitstellen. Anhand dieser Ressource beginnt die Logging-Plattform mit dem Erfassen Ihrer Systemprotokolldaten. Sie können auf diese Logs über die Benutzeroberfläche des Systemüberwachungstools oder über die GDC Logging API zugreifen. Folgen Sie dazu der Anleitung unter Logs abfragen und ansehen.

Informationen zu Best Practices für die Implementierung von Logging für Kubernetes-Komponenten finden Sie unter https://github.com/kubernetes/community/blob/master/contributors/devel/sig-instrumentation/logging.md.

Hinweise

Bitten Sie Ihren Projekt-IAM-Administrator, Ihnen eine der folgenden Rollen in Ihrem Projekt-Namespace zuzuweisen, um die Berechtigungen zu erhalten, die Sie zum Erfassen oder Aufrufen von Betriebslogs benötigen:

  • Logging Target Creator: erstellt benutzerdefinierte LoggingTarget-Ressourcen. Fordern Sie die Rolle „Logging Target Creator“ (loggingtarget-creator) an.
  • Logging Target Editor: Bearbeitet oder ändert benutzerdefinierte LoggingTarget-Ressourcen. Fordern Sie die Rolle „Logging Target Editor“ (loggingtarget-editor) an.
  • Logging Target Viewer: zeigt LoggingTarget benutzerdefinierte Ressourcen an. Fordern Sie die Rolle „Logging Target Viewer“ (loggingtarget-viewer) an.

Erfassung von Betriebslogs für einen Dienst konfigurieren

In Betriebslogs werden Bedingungen, Änderungen und Aktionen aufgezeichnet, während Sie laufende Vorgänge in Anwendungen und Diensten auf GDC verwalten. Stellen Sie die benutzerdefinierte Ressource LoggingTarget im Administratorcluster der Organisation bereit, um die Pipeline für Systemlogs zu konfigurieren, damit Betriebslogs von bestimmten Diensten auf Projektebene erfasst werden.

So erfassen Sie Betriebslogs von einem Dienst:

  1. Konfigurieren Sie die benutzerdefinierte Ressource LoggingTarget und geben Sie die ausgewählten Pods zum Erfassen Ihrer Betriebslogs, den Namespace des Projekts und alle zusätzlichen Einstellungen an. Weitere Informationen finden Sie unter Benutzerdefinierte Ressource LoggingTarget konfigurieren.
  2. Stellen Sie die LoggingTarget-CR im Namespace Ihres Projekts im Administratorcluster der Organisation bereit. Die Pipeline beginnt mit dem Erfassen von Logs aus den zusätzlichen Komponenten Ihres Projekts.
  3. Sie können Ihre Logs über dieSystemmonitoring-Instanz Ihres Projekts. Weitere Informationen finden Sie unter Logs abfragen und ansehen.

Verwenden Sie die integrierte Farbcodierungsfunktion für verschiedene Logebenen des Dienstes. Weitere Informationen zum Festlegen von Log-Level-Werten finden Sie unter https://grafana.com/docs/grafana/latest/explore/logs-integration/.

Benutzerdefinierte LoggingTarget-Ressource konfigurieren

Die benutzerdefinierte Ressource LoggingTarget weist die Systemlogging-Pipeline an, Logs von bestimmten Diensten Ihres Projekts zu erfassen und Datenbeobachtbarkeit zu ermöglichen. Sie müssen diese Ressource in dem Namespace bereitstellen, aus dem Sie Logs erfassen möchten.

Die folgende YAML-Datei zeigt ein Beispiel für die Konfiguration von LoggingTarget:

# Configures a log scraping job
apiVersion: logging.gdc.goog/v1
kind: LoggingTarget
metadata:
  # Choose a namespace that matches the namespace of the workload pods
  namespace: PROJECT_NAMESPACE
  name: my-service-logging-target
spec:
  # Choose a matching pattern that identifies the pods for this job
  # Optional
  # Relationship between different selectors: 'AND'
  selector:
    # The clusters to collect logs from.
    # The default configuration is to collect logs from all clusters.
    # The relationship between different clusters is an 'OR' relationship.
    # For example, the value '["admin", "system"]' indicates to consider
    # the admin cluster 'OR' the system cluster.
    # Optional
    matchClusters:
    - CLUSTER_NAME
    - CLUSTER_NAME

    # The pod name prefixes to collect logs from.
    # The Observability platform scrapes all pods with names
    # that start with the specified prefixes.
    # The values must contain '[a-z0-9-]' characters only.
    # The relationship between different list elements is an 'OR' relationship.
    # Optional
    matchPodNames:
      - POD_NAME
      - POD_NAME

    # The container name prefixes to collect logs from.
    # The Observability platform scrapes all containers with names
    # that start with the specified prefixes.
    # The values must contain '[a-z0-9-]' characters only.
    # The relationship between different list elements is an 'OR' relationship.
    # Optional
    matchContainerNames:
      - CONTAINER_NAME
      - CONTAINER_NAME

  # Choose the predefined parser for log entries.
  # Use parsers to map the log output to labels and extract fields.
  # Specify the log format.
  # Optional
  # Options: klog_text, klog_json, klogr, gdch_json, json
  parser: klog_text

  # Specify an access level for log entries.
  # The default value is 'ao'.
  # Optional
  # Options: ao, pa, io
  logAccessLevel: ao

  # Specify a service name to be applied as a label
  # For user workloads consider this field as a workload name
  # Required
  serviceName: SERVICE_NAME

  # The additional static fields to apply to log entries.
  # The field is a key-value pair, where the field name is the key and
  # the field value is the value.
  # Optional
  additionalFields:
    app: workload2
    key: value

Ersetzen Sie Folgendes:

  • PROJECT_NAMESPACE: Der Namespace Ihres Projekts
  • CLUSTER_NAME ist der Name des Clusters.
  • POD_NAME: das Pod-Namenspräfix
  • CONTAINER_NAME: das Präfix des Containernamens
  • SERVICE_NAME: der Name des Dienstes

Die Felder parser, logAccessLevel und additionalFields enthalten Beispielwerte, die Sie ändern können.

Standardmäßig werden alle Betriebslogbucheinträge für die Mandanten-ID des Projektnamespace gespeichert. Um dieses Verhalten zu überschreiben, geben Sie in der benutzerdefinierten Ressource LoggingTarget einen logAccessLevel-Wert an.