Diese Seite wurde von der Cloud Translation API übersetzt.

Logs aus Ihren Workflows erfassen

Auf dieser Seite wird beschrieben, wie Sie Logs aus Ihren Workflows in Google Distributed Cloud-Umgebungen (GDC) ohne Internetverbindung erfassen, um Logging und Datenbeobachtbarkeit zu ermöglichen.

In Protokollen werden Bedingungen und Aktionen aufgezeichnet, während Sie Vorgänge über Ihre Dienste in GDC verwalten. Sie können Protokolle, die von Ihren Komponenten erstellt werden, parsen, um Ereignisse und Aktivitäten aufzuzeichnen. Die Logging-Plattform bietet eine benutzerdefinierte API zum Erfassen von Logs auf Projektebene, die von Ihren Workflows über Logging-Ziele generiert werden.

Wenn Sie mit der Erhebung von Logdaten beginnen möchten, stellen Sie eine benutzerdefinierte LoggingTarget-Ressource im Namespace Ihres Projekts auf dem Management API-Server bereit. Nachdem der Log Collector Daten aus Ihren Workflows abgerufen hat, aggregiert die Logging-Plattform Logs aus allen Logquellen, fügt Indexe hinzu und verknüpft Logs mit Labels gemäß der Konfiguration aus der benutzerdefinierten LoggingTarget-Ressource.

Sie können über die Grafana-Benutzeroberfläche auf Ihre erfassten Logs zugreifen. Weitere Informationen finden Sie unter Logs abfragen und ansehen.

Best Practices für die Implementierung von Logging für die Datenbeobachtung finden Sie in den Kubernetes-Community-Richtlinien:

https://github.com/kubernetes/community/blob/master/contributors/devel/sig-instrumentation/logging.md.

Hinweise

Wenn Sie die Berechtigungen benötigen, die Sie zum Verwalten von benutzerdefinierten LoggingTarget-Ressourcen benötigen, bitten Sie Ihren Organisations-IAM-Administrator oder Projekt-IAM-Administrator, Ihnen eine der zugehörigen LoggingTarget-Rollen zuzuweisen.

Je nach erforderlicher Zugriffsebene und Berechtigungen können Sie für diese Ressource in einer Organisation oder einem Projekt die Rolle „Ersteller“, „Bearbeiter“ oder „Betrachter“ erhalten. Weitere Informationen finden Sie unter IAM-Berechtigungen vorbereiten.

Anwendungsoperatoren: Wenn Sie die Berechtigungen benötigen, um benutzerdefinierte LoggingTarget-Ressourcen in einem Projekt auf dem Management-API-Server zu verwalten, bitten Sie Ihren Projekt-IAM-Administrator, Ihnen eine der folgenden Rollen in Ihrem Projekt-Namespace zuzuweisen:
- LoggingTarget Creator: erstellt benutzerdefinierte LoggingTarget-Ressourcen. Fordern Sie die Rolle „LoggingTarget Creator“ (loggingtarget-creator) an.
- LoggingTarget Editor: Bearbeitet oder ändert benutzerdefinierte LoggingTarget-Ressourcen. Fordern Sie die Rolle „LoggingTarget Editor“ (loggingtarget-editor) an.
- LoggingTarget Viewer: zeigt benutzerdefinierte LoggingTarget-Ressourcen an. Fordern Sie die Rolle „LoggingTarget Viewer“ (loggingtarget-viewer) an.
Plattformadministratoren: Bitten Sie Ihren IAM-Administrator der Organisation, Ihnen eine der folgenden Clusterrollen im Namespace platform-obs zuzuweisen, um die Berechtigungen zu erhalten, die Sie zum Verwalten von benutzerdefinierten LoggingTarget-Ressourcen im Namespace platform-obs auf dem Management API-Server benötigen:
- LoggingTarget PA Creator: erstellt benutzerdefinierte LoggingTarget-Ressourcen. Fordern Sie die Clusterrolle „LoggingTarget PA Creator“ (loggingtarget-pa-creator) an.
- LoggingTarget PA Editor: Bearbeitet oder ändert benutzerdefinierte LoggingTarget-Ressourcen. Fordern Sie die Clusterrolle „LoggingTarget PA Editor“ (loggingtarget-pa-editor) an.
- LoggingTarget PA Viewer: Kann benutzerdefinierte LoggingTarget-Ressourcen aufrufen. Fordern Sie die Clusterrolle „LoggingTarget PA Viewer“ (loggingtarget-pa-viewer) an.

Betriebslogs erfassen

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 auf dem Management API-Server bereit, um die System-Logging-Pipeline zum Erfassen von Betriebslogs von bestimmten Diensten auf Projektebene zu konfigurieren.

So erfassen Sie Betriebslogs von einem Dienst:

Konfigurieren Sie die benutzerdefinierte Ressource LoggingTarget auf dem Management API-Server und geben Sie die ausgewählten Pods zum Erfassen Ihrer Betriebslogs, den Projektnamespace und alle zusätzlichen Einstellungen an. Informationen dazu, wie die LoggingTarget aussehen muss, finden Sie unter Benutzerdefinierte LoggingTarget-Ressource konfigurieren.
Stellen Sie die benutzerdefinierte LoggingTarget-Ressource im Namespace Ihres Projekts auf dem Management API-Server bereit:
```
kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f LOGGING_TARGET_NAME
```
Ersetzen Sie Folgendes:
- MANAGEMENT_API_SERVER: Der kubeconfig-Pfad des zonalen Management API-Servers.
- LOGGING_TARGET_NAME: der Name der benutzerdefinierten Ressource LoggingTarget, z. B. my-service-logging-target.yaml.
Die Pipeline beginnt mit dem Erfassen von Logs aus den zusätzlichen Komponenten Ihres Projekts.
Fragen Sie Ihre Logs über die Grafana-Instanz Ihres Projekts ab. Weitere Informationen finden Sie unter Logs abfragen und ansehen.

Verwenden Sie die integrierte Farbcodierungsfunktion von Grafana 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 Logging-Pipeline an, Logs von bestimmten Diensten in Ihrem GDC-Projekt zu erfassen. Sie können die Ziele angeben, für die Sie Logs erfassen, einen Log-Parser, Zugriffsebenen und zusätzliche Einstellungen.

Diese Ressource definiert die folgenden Konfigurationen:

Ziele: Die Kriterien für die Auswahl der Pods und Container, aus denen Sie Logs erfassen möchten. Sie können Clusternamen, Pod-Namenspräfixe und Containernamenspräfixe angeben.
Log-Analysetool: Ein vordefinierter Parser zum Interpretieren von Logeinträgen, Zuordnen von Logausgaben zu Labels und Extrahieren relevanter Felder.
Dienstidentifikation: Der Dienstname, der als Label auf die Logeinträge angewendet wird, um die Identifizierung und Filterung zu erleichtern.
Autorisierung: Die Zugriffsebene für Logeinträge, mit der gesteuert wird, wer die erfassten Logs ansehen kann.

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

Durch die Konfiguration dieser Parameter in der benutzerdefinierten Ressource LoggingTarget können Sie die Erfassung und Organisation von Logs aus Ihren Diensten genau steuern.

So erfassen Sie Betriebslogs von einem Dienst:

Ermitteln Sie das GDC-Projekt, aus dem Sie Logs erfassen möchten.
Geben Sie in Ihrer LoggingTarget-Konfiguration die Pods zum Erfassen Ihrer Betriebslogs, den Projekt-Namespace und alle zusätzlichen Einstellungen an.

Die folgende YAML-Datei zeigt ein Beispiel für eine LoggingTarget-Konfiguration in my-project-namespace, wobei das Präfix des Pod-Namens, aus dem Logs erfasst werden sollen, my-pod-prefix ist, die Zugriffsebene für Logeinträge Anwendungsoperatoren (ao) gewährt wird, der Dienstname my-service-name ist und das Logformat JSON ist:
```
# 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: my-project-namespace
  name: my-service-logging-target
spec:
  selector:
    matchPodNames:
      - my-pod-prefix
  parser: json
  logAccessLevel: ao
  serviceName: my-service-name
```
Weitere Felder und Optionen finden Sie in der vollständigen LoggingTarget-Spezifikation und der API-Referenzdokumentation.
Wenden Sie die LoggingTarget-Konfiguration auf den Management API-Server im selben Namespace wie Ihre Ziel-Pods an:
```
kubectl --kubeconfig KUBECONFIG_PATH apply -f LOGGING_TARGET_NAME.yaml
```
Ersetzen Sie Folgendes:
- KUBECONFIG_PATH: der Pfad zur kubeconfig-Datei für den Management API-Server.
- LOGGING_TARGET_NAME: der Name der LoggingTarget-Definitionsdatei, z. B. my-service-logging-target.
Die Logging-Pipeline beginnt mit dem Erfassen von Logs aus den zusätzlichen Komponenten Ihres Projekts.

Sie können Ihre erfassten Logs über die Grafana-Benutzeroberfläche oder die Log Query API abfragen. Weitere Informationen finden Sie unter Logs abfragen und ansehen.

Wenn Sie Grafana zum Abfragen Ihrer Logs verwenden, können Sie die integrierte Farbcodierungsfunktion für verschiedene Logebenen des Dienstes nutzen. Weitere Informationen zum Festlegen von Log-Level-Werten finden Sie unter https://grafana.com/docs/grafana/latest/explore/logs-integration/.

Vollständige `LoggingTarget`-Spezifikation

Die folgende YAML-Datei zeigt ein Beispiel für die vollständige Spezifikation der benutzerdefinierten Ressource LoggingTarget. Weitere Informationen und eine vollständige Beschreibung der Felder finden Sie in der API-Referenzdokumentation.

# 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: LOGGING_TARGET_NAME
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.
    # Optional
    matchClusters:
    - my-cluster
    - another-cluster

    # The pod name prefixes to collect logs from.
    # The logging 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:
      - my-pod-prefix
      - another-pod-prefix

    # The container name prefixes to collect logs from.
    # The logging 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:
      - my-container-prefix
      - another-container-prefix

  # 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: my-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: Ihr Projekt-Namespace.
LOGGING_TARGET_NAME: der Name der LoggingTarget-Definitionsdatei.