Mit der Logerfassung in der Google Distributed Cloud (GDC) mit Air Gap können Sie operative Ereignisse aus Ihren Workflows für das Monitoring und die Fehlerbehebung zusammenfassen. Stellen Sie eine benutzerdefinierte LoggingTarget-Ressource im Projekt-Namespace auf dem Management API-Server bereit, um Logs aus Ihren Dienstkomponenten abzurufen, zu indexieren und zu kennzeichnen.
Nachdem Sie die Logerfassung konfiguriert haben, können Sie in der Grafana-Benutzeroberfläche Logs abfragen und ansehen. Empfehlungen zur Instrumentierung finden Sie in den Kubernetes-Logging-Richtlinien.
Hinweis
Bitten Sie Ihren IAM-Administrator für die Organisation oder den IAM-Administrator für das Projekt, Ihnen eine der zugehörigen LoggingTarget-Rollen zuzuweisen, um die Berechtigungen zu erhalten, die Sie zum Verwalten von benutzerdefinierten LoggingTarget-Ressourcen benötigen.
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: Bitten Sie Ihren Projekt-IAM-Administrator, Ihnen eine der folgenden Rollen in Ihrem Projekt-Namespace zuzuweisen, um die Berechtigungen zu erhalten, die Sie zum Verwalten von benutzerdefinierten
LoggingTarget-Ressourcen in einem Projekt auf dem Management API-Server benötigen:- LoggingTarget Creator: Erstellt benutzerdefinierte
LoggingTarget-Ressourcen. Fordern Sie die Rolle „LoggingTarget Creator“ (loggingtarget-creator) an. - LoggingTarget-Bearbeiter: Bearbeitet oder ändert benutzerdefinierte
LoggingTarget-Ressourcen. Fordern Sie die Rolle „LoggingTarget-Bearbeiter“ (loggingtarget-editor) an. - LoggingTarget Viewer: Zeigt benutzerdefinierte
LoggingTarget-Ressourcen an. Fordern Sie die Rolle „LoggingTarget Viewer“ (loggingtarget-viewer) an.
- LoggingTarget Creator: Erstellt benutzerdefinierte
Plattformadministratoren: Bitten Sie den IAM-Administrator Ihrer Organisation, Ihnen eine der folgenden Clusterrollen im Namespace
platform-obszuzuweisen, um die Berechtigungen zu erhalten, die Sie zum Verwalten von benutzerdefiniertenLoggingTarget-Ressourcen im Namespaceplatform-obsauf dem Verwaltungs-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: Zum Aufrufen von benutzerdefinierten
LoggingTarget-Ressourcen. Fordern Sie die Clusterrolle „LoggingTarget PA Viewer“ (loggingtarget-pa-viewer) an.
- LoggingTarget PA Creator: Erstellt benutzerdefinierte
Betriebslogs erfassen
In Betriebsprotokollen werden Bedingungen, Änderungen und Aktionen aufgezeichnet, während Sie laufende Vorgänge in Anwendungen und Diensten in GDC verwalten. Stellen Sie die benutzerdefinierte Ressource LoggingTarget auf dem Management API-Server bereit, um die System-Logging-Pipeline für die Erfassung von Betriebsprotokollen von bestimmten Diensten auf Projektebene zu konfigurieren.
Führen Sie die folgenden Schritte aus, um Betriebslogs von einem Dienst zu erfassen:
- Konfigurieren Sie die benutzerdefinierte Ressource
LoggingTargetauf dem Management API-Server und geben Sie die ausgewählten Pods für die Erfassung Ihrer Betriebsprotokolle, den Projekt-Namespace und alle zusätzlichen Einstellungen an. Informationen dazu, wie dieLoggingTargetaussehen muss, finden Sie unter Benutzerdefinierte RessourceLoggingTargetkonfigurieren. Stellen Sie die benutzerdefinierte
LoggingTarget-Ressource im Projekt-Namespace auf dem Management API-Server bereit:kubectl --kubeconfig MANAGEMENT_API_SERVER apply -f LOGGING_TARGET_NAMEErsetzen Sie Folgendes:
MANAGEMENT_API_SERVER: der kubeconfig-Pfad des zonalen Management API-Servers.LOGGING_TARGET_NAME: der Name der benutzerdefiniertenLoggingTarget-Ressource, 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 alle zusätzlichen 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 Container-Namenspräfixe angeben.
- Log-Analysetool: Ein vordefinierter Parser, der Logeinträge interpretiert, Logausgaben Labels zuordnet und relevante Felder extrahiert.
- 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, die steuert, wer die erfassten Logs ansehen kann.
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 Betriebsprotokolle von einem Dienst:
- Bestimmen Sie das GDC-Projekt, aus dem Sie Logs erfassen möchten.
Geben Sie in Ihrer
LoggingTarget-Konfiguration die Pods für die Erfassung Ihrer Betriebsprotokolle, den Projekt-Namespace und alle zusätzlichen Einstellungen an.Die folgende YAML-Datei zeigt ein Beispiel für eine
LoggingTarget-Konfiguration inmy-project-namespace, wobei das Pod-Namenspräfix, aus dem Logs erfasst werden sollen,my-pod-prefixist, die Zugriffsebene für Logeinträge Anwendungsoperatoren (ao) gewährt wird, der Dienstnamemy-service-nameist 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-nameWeitere Felder und Optionen finden Sie in der vollständigen
LoggingTarget-Spezifikation und in 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.yamlErsetzen Sie Folgendes:
KUBECONFIG_PATH: der Pfad zur kubeconfig-Datei für den Management API-Server.LOGGING_TARGET_NAME: der Name derLoggingTarget-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 die 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 verwenden. Weitere Informationen zum Festlegen von Log-Level-Werten finden Sie unter https://grafana.com/docs/grafana/latest/explore/logs-integration/.
Spezifikation für „LoggingTarget“ vervollständigen
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 derLoggingTarget-Definitionsdatei.