Welche Methode verwenden: Logging-Agent oder Clientbibliothek?

In diesem Dokument finden Sie Informationen, die Ihnen bei der Entscheidung helfen, ob Sie Anwendungsprotokolle programmatisch mithilfe von Clientbibliotheken oder mithilfe eines Logging-Agents an Cloud Logging senden möchten. Logging-Agents senden Daten, die in eine Datei geschrieben wurden, z. B. stdout oder eine Datei, als Protokolle an Cloud Logging. Dienste wie die Google Kubernetes Engine, die flexible App Engine-Umgebung und Cloud Run-Funktionen enthalten einen integrierten Logging-Agenten. Für die Compute Engine können Sie den Ops-Agent oder den alten Cloud Logging-Agent installieren. Diese Agenten erfassen Protokolle aus 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 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 einiger 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 Cloud ausgeführt?

Wird Ihre Anwendung nicht in Google Cloud ausgeführt, müssen Sie Logs an die Logging API senden können. Wenn Sie Logs von lokalen Systemen an Logging weiterleiten möchten, empfehlen wir die Verwendung von BindPlane von observIQ. Weitere Informationen zu BindPlane finden Sie unter observIQ und BindPlane.

Alternativ 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.

Unterstützt der Google Cloud-Dienst, mit dem Ihre Anwendung ausgeführt wird,
stdout- und stderr-Inhalte in Ihr Projekt einfügen?

Einige Google Cloud-Dienste sind vollständig verwaltet. Sie müssen also keine Agenten verwenden, um Protokolle an Ihr Google Cloud-Projekt zu senden. Sie können jedes etablierte Logging-Framework in der Sprache Ihrer Wahl verwenden, z. B. Go, Node.js und Python, um Protokolle an Logging-Produkte 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 das Senden von Protokollen an Ihr Projekt bei Anwendungsabstürzen nicht unterbrochen wird. Informationen zum Senden von strukturierten Protokollen über stdout und stderr finden Sie im Abschnitt Können Sie das Logformat in Ihrer Anwendung 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 das automatische Senden von Logs, die in stdout und stderr geschrieben wurden, an Ihr Google Cloud-Projekt nicht unterstützen, können Sie stdout- und stderr-Logs in Dateien auf dem Laufwerk erfassen und den Agenten so konfigurieren, dass er sie abruft und an Logging sendet. Weitere Informationen finden Sie in der Konfigurationsanleitung für den Ops-Agent oder den bisherigen 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.

Verwenden Sie bereits Fluentd in Ihrem System?

Der Legacy-Logging-Agent basiert auf Fluentd.

Wenn Fluentd bereits in Ihrem System ausgeführt wird und Sie diesen Daemon verwenden möchten, um Ihre Protokolle an Logging zu senden, verwenden Sie das Google Cloud Logging-Plug-in für Fluentd.

Erfassen Sie auch Anwendungsmesswerte für Cloud Monitoring?

In 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 anspricht, können Sie den Legacy-Monitoring-Agent oder die Monitoring-Clientbibliotheken verwenden, um Ihre Messwerte zu erfassen.

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

Diese Frage hilft Ihnen bei der Entscheidung, ob Ihre Anwendung strukturierte Protokolle generieren kann. Logging erkennt strukturierte Logs, wenn Sie die Logs im strukturiertes 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 Protokolle 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, die Logs aber als strukturierte Logs erkannt werden sollen, müssen Sie Logs im Format für strukturiertes Logging, in der Regel JSON, an stdout und stderr schreiben, damit die Agents sie als strukturierte Logs erkennen können. Andernfalls müssen Sie Ihren Bot 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.
      • In einigen Sprachen können Protokolle mithilfe der Bibliothek in stdout und stderr ausgegeben werden.

    • Nachteile

      • Bei Anwendungsabstürzen wird das Senden von Protokollen an Ihr Google Cloud-Projekt unterbrochen.

  • Ops-Agent

    • Vorteile
      • Der Ops-Agent kann Logs und Messwerte mit stabilen Open-Source-Technologien senden: Fluent Bit für die Logerfassung und OpenTelemetry Collector für die Messwerterfassung.
      • Sie können sowohl Protokolle 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 befindet sich in der aktiven Entwicklungsphase.

  • Legacy-Logging-Agent

    • Vorteile
      • Der Agent verwendet Fluentd, um Protokolle zu erfassen.
      • Sie können Protokolle 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 Entwicklungsphase.

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

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