Welche Methode verwenden: Logging-Agent oder Clientbibliothek?

In diesem Dokument erfahren Sie, wie Sie mithilfe von Clientbibliotheken oder Logging-Agents programmatisch Anwendungslogs an Cloud Logging senden können. Wenn Sie keine Clientbibliothek oder einen Logging-Agent verwenden können oder nur experimentieren möchten, können Sie Logs mit dem Befehl gcloud logging write oder durch Senden von HTTP-Befehlen an den Cloud Logging API-Endpunkt entries.write schreiben.

Die Cloud Logging API unterstützt sowohl HTTP- als auch gRPC-Aufrufe. Der Ops-Agent und die meisten Logging-Clientbibliotheken rufen die gRPC Logging API auf. Der Legacy-Logging-Agent und die Clientbibliotheken für einige Sprachen rufen die REST Logging API auf.

Wenn Sie die Agents verwenden, können Ihre Anwendungen jedes beliebige Logging-Framework verwenden, um Logs auszugeben. In Containerumgebungen wie Google Kubernetes Engine oder Container-Optimized OS erfassen die Agents beispielsweise automatisch Logs von stdout und stderr. Auf virtuellen Maschinen (VMs) erfassen die Agents Logs von bekannten Dateispeicherorten oder Logging-Diensten wie Windows Event Log, journald oder syslogd.

Agents oder Clientbibliotheken auswählen

Stellen Sie sich bei der Entscheidung, ob Sie einen Agent oder die Clientbibliotheken nutzen, folgende Fragen:

Wird Ihre Anwendung außerhalb von Google Cloud ausgeführt?

Wird Ihre Anwendung nicht in Google Cloud ausgeführt, müssen Sie Logs an die Logging API senden können. In diesem Fall können Sie Logs über Clientbibliotheken direkt von der Anwendung an Logging leiten. Für ephemere Umgebungen, z. B. serverloses Computing, müssen Sie Clientbibliotheken verwenden, um direkte Aufrufe an die Logging API zu senden.

Sie können auch BindPlane by Blue Medora verwenden, um Logs von lokalen Systemen an Logging weiterzuleiten.

Unterstützt der Google Cloud-Dienst, mit dem Ihre Anwendung ausgeführt wird, die automatische Logaufnahme über stdout und stderr?

Einige Google Cloud-Dienste werden vollständig verwaltet. Sie müssen also keine Agents zum Routing von Logs verwenden. Sie können jedes beliebige Logging-Framework in der Sprache Ihrer Wahl verwenden, z. B. Go, Node.js und Python, um Logs an Produkte in Logging weiterzuleiten, die standardmäßig von stdout und stderr unterstützt werden. Ein Vorteil der Aufnahme von Logs über stdout und stderr anstelle von Clientbibliotheken besteht darin, dass die Logaufnahme durch Anwendungsabstürze nicht unterbrochen wird. Informationen zur Aufnahme von strukturierten Logs über stdout und stderr finden Sie im Abschnitt Kann Ihre Anwendung das Logformat flexibel ändern?.

Sie können Logging-Clientbibliotheken verwenden. Beachten Sie jedoch, dass dies eine Abhängigkeit von Logging für lokale Tests bedingen kann – selbst wenn Sie diese nicht unbedingt benötigen. Weiter macht die Verwendung der Clientbibliotheken eventuell auch eine komplexere Codierung erforderlich, um Zwischenspeicher und Wiederholungsversuche explizit zu verarbeiten. Außerdem wird bei jeder Verwendung der Logging-Clientbibliotheken ein neuer Verbindungsstream zur API erstellt. Diese neuen Verbindungen steigern die Komplexität, nutzten zusätzliche Ports und senden separate Anfragen, die nur die Logs der Anwendung enthalten. Das kann verschwenderisch sein, wenn nur wenige Logs vorhanden sind.

Müssen die Anwendungslogs in Ihrer lokalen Umgebung zugänglich sein?

Wenn Sie zum Debuggen und für andere Zwecke auf die Anwendungslogs in Ihrer lokalen Umgebung zugreifen müssen, können Sie die Logging-Module in einigen Sprachen verwenden, um Ausgaben an stdout und stderr zu senden. Logging-Clientbibliotheken für einige Sprachen unterstützen das Routing von Logs an stdout und stderr.

Wenn Sie Ihre Anwendung in Google Cloud-Diensten ausführen, die die automatische Logaufnahme über stdout und stderr nicht unterstützen, können Sie stdout- und stderr-Logs in Dateien auf dem Laufwerk erfassen und den Agent so konfigurieren, dass er diese extrahiert und an Logging sendet. Weitere Informationen finden Sie in der Konfigurationsanleitung für den Ops-Agent oder den Logging-Agent.

Erfolgt die Agent-Installation manuell oder automatisch?

Einige Dienste installieren Agents automatisch oder ermöglichen es Ihnen, Agents selbst zu installieren. Wenn der von Ihnen verwendete Dienst die Installation von Agents nicht zulässt, müssen Sie die Clientbibliotheken nutzen, um Logging zu verwenden.

Führen Sie Fluentd bereits in Ihrem System aus?

Der alte Logging-Agent basiert auf Fluentd.

Wenn Fluentd bereits in Ihrem System ausgeführt wird und Sie diesen Daemon auch für die Logging-Aufnahme nutzen möchten, verwenden Sie das Google Cloud Logging-Plug-in für fluentd.

Erfassen Sie auch Anwendungsmesswerte für Cloud Monitoring?

Auf Compute Engine-VMs kann der Ops-Agent Logs und die meisten Messwerte erfassen. Weitere Informationen finden Sie unter Features von Ops-Agents.

Spricht der Ops-Agent Ihre Anwendungsfälle nicht an, können Sie den Legacy-Cloud Monitoring-Agent oder die Monitoring-Clientbibliotheken verwenden, um Ihre Messwerte erfassen.

Können Sie das Logformat in Ihrer Anwendung flexibel ändern?

Diese Frage hilft Ihnen zu entscheiden, ob Ihre Anwendung strukturierte Logs generieren kann. Logging erkennt strukturierte Logs, wenn Sie die Logs im Format des strukturierten Loggings an die Logging API senden. Clientbibliotheken bieten die Methoden zur Verarbeitung dieses Formats.

Es gibt zwei Möglichkeiten, strukturierte Logs zu schreiben: Eine definiert bestimmte Felder im LogEntry-Umschlag, die andere bestimmt das jsonPayload-Feld innerhalb des LogEntry-Umschlags. Das Schema für die erste Option wird von Cloud Logging, das Schema für die zweite Option wird vom Nutzer bestimmt.

Sie müssen den Agent so konfigurieren, dass er strukturierte Logs erkennt. Standardmäßig sind die Agents so konfiguriert, dass Logs im JSON-Format erkannt und als strukturierte Logs verarbeitet werden. Wenn Ihre Anwendung ein eigenes Logformat hat, das Sie nicht ändern können, die Logs jedoch als strukturierte Logs erkannt werden sollen, müssen Sie Logs im strukturierten Logging-Format (normalerweise JSON) in stdout und stderr schreiben, damit die Agents sie als strukturierte Logs erkennen können. Andernfalls müssen Sie den Agent so konfigurieren, dass er Ihr eigenes Format versteht.

Übersicht über die einzelnen Optionen

Diagramm der Logging-Muster

  • Cloud Logging-Clientbibliotheken

    • Vorteile

      • Sie können Logs direkt an die Cloud Logging API leiten.
      • Einige Sprachen können mithilfe der Bibliothek Logs an stdout und stderr ausgeben.

    • Nachteile

      • Bei Anwendungsabstürzen bricht die Logaufnahme ab.

  • Ops-Agent

    • Vorteile
      • Der Ops-Agent unterstützt die Aufnahme von Logs und Messwerten mit stabilen Open-Source-Technologien: Fluent Bit für die Logerfassung, OpenTelemetry Collector für die Messwerterfassung.
      • Sie können Logs in Ihrer lokalen Umgebung aufbewahren.
      • Sie können Logs nach dem Absturz einer Anwendung möglicherweise wiederherstellen.

  • Legacy-Logging-Agent

    • Vorteile
      • Der Agent verwendet Fluentd zum Erfassen von Logs.
      • Sie können Logs in Ihrer lokalen Umgebung aufbewahren.
      • Sie können Logs nach dem Absturz einer Anwendung möglicherweise wiederherstellen.
    • Nachteile
      • Der Agent wird derzeit unterstützt, befindet sich aber nicht in der aktiven Entwicklung.

  • Automatische Logaufnahme von stdout und stderr

    • Vorteile
      • Dieser Prozess ist eine gängige Methode zum Senden von Logs an lokale Umgebungen.
      • Sie können beliebige Logging-Bibliotheken verwenden.
      • Sie können Logs nach dem Absturz einer Anwendung möglicherweise wiederherstellen.
    • Nachteile
      • Nicht alle Umgebungen leiten Logs automatisch an Logging weiter.