Welche Methode verwenden: Logging-Agent oder Clientbibliothek?

Dieses Dokument enthält die Informationen, die Sie benötigen, um zu entscheiden, ob Sie Anwendungslogs programmatisch mit Clientbibliotheken oder mit einem Logging-Agent an Cloud Logging senden möchten. Logging-Agents senden Daten, die in eine Datei geschrieben wurden, z. B. stdout oder eine Datei, als Logs an Cloud Logging. Dienste wie die Google Kubernetes Engine, die flexible App Engine-Umgebung und Cloud Run Functions enthalten einen integrierten Logging-Agent. Für Compute Engine können Sie den Ops-Agent installieren. Dieser Agent erfasst Logs von bekannten Dateispeicherorten oder Protokollierungsdiensten wie Windows Event Log, journald oder syslogd.

Wenn Sie keine Clientbibliothek oder keinen Logging-Agent verwenden können oder nur experimentieren möchten, können Sie Logs mit dem Befehl gcloud logging write schreiben oder HTTP-Befehle an den Cloud Logging API-Endpunkt entries.write senden. 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. Clientbibliotheken für einige Sprachen rufen die REST Logging API auf.

Agent 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 Cloudausgeführt?

Wenn Ihre Anwendung nicht auf Google Cloudausgeführt wird, benötigen Sie eine Möglichkeit, Logs an die Logging API zu senden. Wenn Sie Logs von lokalen Systemen an Cloud Logging weiterleiten möchten, empfehlen wir die Verwendung von Bindplane. Damit werden OpenTelemetry Collectors bereitgestellt und verwaltet, um Telemetrie an Google Cloudzu senden. Weitere Informationen finden Sie unter BindPlane.

Alternativ können Sie Logs mithilfe von Clientbibliotheken direkt aus der Anwendung an Cloud Logging weiterleiten. In kurzlebigen Umgebungen wie Serverless Computing müssen Sie Clientbibliotheken verwenden, um direkte Aufrufe an die Logging API zu senden.

Unterstützt der Google Cloud Dienst, auf dem Ihre Anwendung ausgeführt wird,

stdout- und stderr-Inhalte für Ihr Projekt schreiben?

Einige Google Cloud Dienste werden vollständig verwaltet, sodass Sie keine Agents verwenden müssen, um Logs an Ihr Google Cloud Projekt zu senden. Sie können ein beliebiges etabliertes Logging-Framework in der Sprache Ihrer Wahl verwenden, z. B. Go, Node.js und Python, um Logs an Logging in Produkten zu senden, in denen stdout und stderr standardmäßig unterstützt werden. Ein Vorteil der Verwendung von stdout und stderr anstelle von Clientbibliotheken besteht darin, dass Anwendungsabstürze das Senden von Logs an Ihr Projekt nicht verhindern. Informationen zum Senden von strukturierten Logs über stdout und stderr finden Sie im Abschnitt Kann das Logformat Ihrer Anwendung geändert werden?.

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 das automatische Senden von Logs, die in stdout und stderr geschrieben wurden, an IhrGoogle Cloud -Projekt nicht unterstützen, können Sie stdout- und stderr-Logs in Dateien auf der Festplatte erfassen und den Agent so konfigurieren, dass er diese Logs erfasst und an Logging sendet. Weitere Informationen finden Sie im Konfigurationsleitfaden für den Ops-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.

Verwenden Sie Fluentd bereits in Ihrem System?

Wenn Sie Fluentd bereits in Ihrem System ausführen und diesen Daemon verwenden möchten, um Ihre Logs an Logging zu senden, 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 Ops-Agent-Funktionen.

Wenn der Ops-Agent Ihre Anwendungsfälle nicht abdeckt, können Sie die Monitoring-Clientbibliotheken verwenden, um Ihre Messwerte zu 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 strukturierten Logging-Format 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 sie Logs im JSON-Format erkennen und als strukturierte Logs verarbeiten. Wenn Ihre Anwendung ein eigenes Logformat hat, das Sie nicht ändern können, Sie aber möchten, dass die Logs als strukturierte Logs erkannt werden, müssen Sie Logs im Format für strukturiertes Logging (in der Regel JSON) in stdout und stderr schreiben, damit die Agents sie als strukturierte Logs erkennen können. Andernfalls müssen Sie Ihren Agent so konfigurieren, dass er Ihr eigenes Format versteht.

Übersicht über die einzelnen Optionen

• Cloud Logging-Clientbibliotheken

  • Vorteile

    • Sie können Logs direkt an die Cloud Logging API leiten.
    • In einigen Sprachen können Logs mit der Bibliothek in stdout und stderr ausgegeben werden.

  • Nachteile

    • Wenn eine Anwendung abstürzt, können keine Protokolle an Ihr Google Cloud -Projekt gesendet werden.

• Ops-Agent

  • Vorteile

    • Der Ops-Agent kann Logs und Messwerte mit stabilen Open-Source-Technologien senden: Fluent Bit für die Logerfassung und den OpenTelemetry Collector für die Messwerterfassung.
    • Sie können sowohl Logs als auch Messwerte aus vielen gängigen Anwendungen erfassen. Weitere Informationen finden Sie unter Logs von Drittanbieteranwendungen überwachen und erfassen.
    • Sie können Protokolle in Ihrer lokalen Umgebung aufbewahren.
    • Sie können Logs nach dem Absturz einer Anwendung möglicherweise wiederherstellen.
    • Der Ops-Agent wird aktiv weiterentwickelt.

  • Nachteile

    • Fluent Bit unterstützt nur die UTF-8-Codierung. Die Codierungskonvertierung wird nicht unterstützt.

• stdout- und stderr-Logs werden automatisch an Ihr Google Cloud -Projekt gesendet.

  • Vorteile
    • So werden Logs häufig an lokale Umgebungen gesendet.
    • Sie können beliebige Logging-Bibliotheken verwenden.
    • Sie können Logs nach dem Absturz einer Anwendung möglicherweise wiederherstellen.
  • Nachteile
    • In nicht allen Umgebungen werden Logs automatisch an Logging weitergeleitet.