Welche Methode verwenden: Logging-Agent oder Clientbibliothek?

Dieses Dokument enthält die Informationen, die Sie benötigen, um zu entscheiden, zum programmatischen Senden von Anwendungslogs an Cloud Logging mithilfe von Clientbibliotheken oder mithilfe eines Logging-Agent an. Logging-Agents senden Daten, die in eine Datei geschrieben sind, z. B. stdout oder eine Datei als Logs an Cloud Logging. Dienste wie Google Kubernetes Engine, die flexible App Engine-Umgebung und Cloud Functions enthalten ein integriertes Logging-Agent an. Für Compute Engine können Sie den Ops-Agent oder Legacy-Cloud Logging-Agent: Diese Agents erfassen Logs aus bekannten Dateispeicherorten oder -protokollen wie Windows Event Log, journald oder syslogd.

Wenn Sie eine Clientbibliothek oder einen Logging-Agent nicht verwenden können oder nur zu experimentieren, können Sie Protokolle mit der Methode gcloud logging write oder HTTP-Befehle an den Cloud Logging API-Endpunkt senden entries.write. Die Cloud Logging API unterstützt sowohl HTTP- und gRPC-Aufrufe Der Ops-Agent und die meisten Logging-Clients Bibliotheken rufen die gRPC Logging API auf. Das Legacy-Logging Agent- und Clientbibliotheken nennen für einige Sprachen die REST Logging API

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. Logs weiterleiten von lokalen Systemen auf Logging übertragen, empfehlen wir die Verwendung von BindPlane von observIQ. Weitere Informationen zu BindPlane finden Sie unter ObservIQ und BindPlane

Alternativ können Sie Logs direkt von der Anwendung mithilfe von Clientbibliotheken. Bei sitzungsspezifischen Umgebungen wie beim serverlosen Computing, müssen Sie Clientbibliotheken verwenden, um direkte an die Logging API senden.

Unterstützt der Google Cloud-Dienst, auf dem Ihre Anwendung ausgeführt wird,
Du schreibst Inhalte zu stdout und stderr in dein Projekt?

Einige Google Cloud-Dienste sind vollständig verwaltet. Sie benötigen um Logs mit Agents an Ihr Google Cloud-Projekt zu senden. Sie können beliebige namhaften Logging-Framework in in der Sprache Ihrer Wahl (z. B. Go, Node.js und Python), an die Logs gesendet werden Produkte anmelden, in denen stdout und stderr unterstützt werden ist standardmäßig aktiviert. Ein Vorteil von stdout und stderr statt Client-Bibliotheken zu verwenden, ist, dass Anwendungsabstürze nicht dem Senden von Logs an Ihr Projekt. Weitere Informationen zum Senden strukturierte Logs bis stdout und stderr finden Sie im Abschnitt Bietet Ihre Anwendung die Flexibilität, das Logformat ä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.

Beim Ausführen Ihrer Anwendung in Google Cloud-Diensten, die keine Es werden automatisch an stdout und stderr geschriebene Protokolle an Ihr Google Cloud-Projekt können Sie stdout und stderr melden sich auf dem Laufwerk an und konfigurieren den Agent so, extrahieren und an Logging senden. Weitere Informationen finden Sie in der Konfigurationsanleitung für den Ops-Agent. oder den alten 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 Legacy-Logging-Agent basiert auf fluentd.

Wenn fluentd bereits in Ihrem System ausgeführt wird und senden Sie Ihre Logs mit diesem Daemon an Logging und nutzen dann den Google Cloud Logging-Plug-in für fluentd enthalten.

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

Wenn der Ops-Agent nicht auf Ihre Anwendungsfälle eingeht, können Sie den Legacy-Monitoring-Agent oder den Clientbibliotheken überwachen um Messwerte zu sammeln.

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

Diese Frage hilft Ihnen zu entscheiden, ob Ihre Anwendung strukturierte Logs. Logging erkennt strukturierte Logs, wenn Sie die Logs an den Logging API im Format für strukturiertes Logging 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. Agents sind standardmäßig so konfiguriert, dass sie Logs im JSON-Format erkennen und als strukturierte Protokolle behandelt werden. Wenn Ihre Anwendung ein eigenes Logformat hat die nicht geändert werden können, die Protokolle aber als strukturiert erkannt werden sollen. Logs geschrieben werden, müssen Sie sie im strukturierten Logging-Format schreiben, in der Regel JSON in stdout und stderr, damit die Kundenservicemitarbeiter sie als Strukturierte Logs. Andernfalls müssen Sie den Agent so konfigurieren, dass er Ihre Format verwenden.

Ü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 Protokolle an stdout und stderr ausgeben, indem Sie die Bibliothek.

    • Nachteile

      • Das Senden von Logs an Ihr Google Cloud-Projekt funktioniert nach Anwendungsabstürzen nicht mehr.

  • Ops-Agent

    • Vorteile
      • Der Ops-Agent kann Logs und Messwerte senden, indem er stabile Open-Source-Technologien: Fluent Bit zur Protokollerfassung und OpenTelemetry Collector für die Messwerterfassung.
      • Sie können sowohl Logs als auch Messwerte aus vielen gängigen Anwendungen Siehe Überwachen und Erfassen von Logs von Drittanbietern Apps.
      • Sie können Logs 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 Entwicklung.

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

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

    • Vorteile
      • Dieser Vorgang ist eine gängige Methode, Logs an lokale Umgebungen auszugeben.
      • 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.