Welche Methode verwenden: Logging-Agent oder Clientbibliothek?
Mit Sammlungen den Überblick behalten
Sie können Inhalte basierend auf Ihren Einstellungen speichern und kategorisieren.
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 Cloudausgeführt?
Wird Ihre Anwendung nicht in Google Cloudausgefü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. Damit werden OpenTelemetry-Collectors bereitgestellt und verwaltet, um Telemetrie an Google Cloudzu senden. Weitere Informationen finden Sie unter 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 Agents 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 IhrGoogle 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.
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.
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
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.
[[["Leicht verständlich","easyToUnderstand","thumb-up"],["Mein Problem wurde gelöst","solvedMyProblem","thumb-up"],["Sonstiges","otherUp","thumb-up"]],[["Schwer verständlich","hardToUnderstand","thumb-down"],["Informationen oder Beispielcode falsch","incorrectInformationOrSampleCode","thumb-down"],["Benötigte Informationen/Beispiele nicht gefunden","missingTheInformationSamplesINeed","thumb-down"],["Problem mit der Übersetzung","translationIssue","thumb-down"],["Sonstiges","otherDown","thumb-down"]],["Zuletzt aktualisiert: 2025-09-03 (UTC)."],[],[],null,["# Which should you use: Logging agent or client library?\n\nThis document provides the information that you need to help you decide whether\nto programmatically send application logs to Cloud Logging by using\n[client libraries](/logging/docs/reference/libraries) or by using a\nlogging agent. Logging agents send data written to a file, such as\n`stdout` or a file, as logs to Cloud Logging. Services such as\nGoogle Kubernetes Engine, App Engine flexible environment, and Cloud Run functions, contain an integrated\nlogging agent. For Compute Engine, you can install the\n[Ops Agent or the legacy Cloud Logging agent](/logging/docs/agent).\nThese agents collect logs from known file locations or logging\nservices like the `Windows Event Log`, `journald`, or `syslogd`.\n\nWhen you can't use a client library or a Logging agent, or when\nyou only want to experiment, you can write logs by using the\n[`gcloud logging write`](/sdk/gcloud/reference/logging/write)\ncommand or by sending HTTP commands to the Cloud Logging API endpoint\n[`entries.write`](/logging/docs/reference/v2/rest/v2/entries/write).\nThe [Cloud Logging API](/logging/docs/reference/api-overview) supports both\nHTTP and gRPC calls. The Ops Agent and most Logging client\nlibraries call the gRPC Logging API. The legacy Logging\nagent and client libraries for some languages call the REST\nLogging API.\n| **Note:** There will be no new feature development or support for new operating systems for the legacy Logging agent. We recommend that you use the [Ops Agent](/logging/docs/agent/ops-agent) for new workloads and eventually transition your existing VMs to use the Ops Agent.\n\nChoosing an agent or client libraries\n-------------------------------------\n\nWhen you're deciding between an agent or the client libraries, consider\nthe following questions:\n\nIs your application running outside of Google Cloud?\n\n: If your application isn't running on Google Cloud, you need\n some way to send logs to the Logging API. To route logs from\n on-premises systems to Logging, we recommend that you use\n [Bindplane](https://bindplane.com/google), which deploys and manages\n OpenTelemetry collectors to send telemetry to Google Cloud. For more\n information, see [About Bindplane](/stackdriver/bindplane).\n\n Alternatively, you can route logs to Logging directly from\n the application by using client libraries. For ephemeral environments,\n like Serverless computing, you must use client libraries to make direct\n calls to the Logging API.\n\nDoes the Google Cloud service running your application support\nwriting `stdout` and `stderr` content to your project?\n\n: Some Google Cloud services are fully managed, so you don't need\n to use agents to send logs to your Google Cloud project. You can use any\n established logging framework in\n the language of your choice, such as Go, Node.js, and Python, to send logs to\n Logging in products where `stdout` and `stderr` are supported\n by default. An advantage to relying on `stdout` and `stderr`\n instead of using client libraries is that application crashes don't break\n sending logs to your project. For information about sending\n [structured logs](/logging/docs/structured-logging) through `stdout` and\n `stderr`, see the section, [Does your application have the flexibility to\n change the log format?](#log-format).\n\n You can use Logging client libraries, but keep in mind that\n it might introduce a dependency on Logging for local testing,\n when you don't necessarily need it. Using the client libraries might also\n require more complex coding to explicitly handle buffering and retries.\n Also, each use of the Logging client libraries creates a new\n connection stream to the API. These new connections introduce more\n complexity, use additional ports, and send separate requests with only the\n logs from the application, which could be wasteful if there aren't many\n logs.\n\nDo the application logs need to be accessible in your local environment?\n\n: If you need to access the application logs in your local environment, for\n debugging and other purposes, then you can use the logging modules in some\n languages to output to `stdout` and `stderr`. Logging client\n libraries for some languages support routing logs to `stdout` and `stderr`.\n\n When running your application in Google Cloud services that don't support\n automatically sending logs written to `stdout` and `stderr` to your\n Google Cloud project, you can collect\n `stdout` and `stderr` logs in on-disk files and configure the agent to\n scrape those and send them to Logging. For more information,\n see the configuration guide for the [Ops Agent](/logging/docs/agent/ops-agent/configuration)\n or the legacy [Logging agent](/logging/docs/agent/logging/configuration).\n\nIs the agent-installation process manual or automatic?\n\n: Some services install agents automatically or allow you to install the agents\n yourself. If the service you are using doesn't allow you to install agents,\n then you must use the client libraries to use Logging.\n\nAre you running Fluentd in your system already?\n\n: The legacy Logging agent is based on Fluentd.\n\n If you already have Fluentd running in your system, and you would like to\n use that daemon to send your logs to Logging, then use the\n [Google Cloud Logging plugin for\n fluentd](https://github.com/GoogleCloudPlatform/fluent-plugin-google-cloud).\n\nAre you collecting application metrics for Cloud Monitoring as well?\n\n: In Compute Engine VMs, the Ops Agent can collect logs and most metrics. See\n [Ops Agent features](/stackdriver/docs/solutions/agents/ops-agent#features) for more information.\n\n If the Ops Agent doesn't address your use cases, then you can use the\n [legacy Monitoring agent](/monitoring/agent/monitoring) or the\n [Monitoring client libraries](/monitoring/docs/reference/libraries)\n to collect your metrics.\n\nDoes your application have the flexibility to change the log format?\n\n: This question helps you decide if your application can generate\n [structured logs](/logging/docs/structured-logging).\n Logging recognizes structured logs if you send the logs to the\n Logging API in [the structured-logging format](/logging/docs/reference/v2/rpc/google.logging.v2#google.logging.v2.WriteLogEntriesRequest).\n Client libraries provide the methods for handling this format.\n\n There are two way of writing structured logs: one is to set [specific fields\n in the `LogEntry` envelope](/logging/docs/structured-logging#special-payload-fields),\n and the other is to set the [`jsonPayload` field within the `LogEntry`\n envelope](/logging/docs/structured-logging#use-gcloud).\n The schema for the former is determined by Cloud Logging, while the\n schema for the latter is determined by the user.\n\n You must configure the agent to recognize [structured logs](/logging/docs/structured-logging).\n By default, the agents are configured to detect logs in JSON format and to\n handle them as structured logs. If your application has its own log format\n that you can't change, but you want the logs to be recognized as structured\n logs, then you must write logs in the structured-logging format, usually\n JSON, to `stdout` and `stderr`, so that the agents can recognize them as\n structured logs. Otherwise, you must configure your agent to understand your\n own format.\n\nSummary of each option\n----------------------\n\n- Cloud Logging client libraries\n\n - Advantages\n\n - You can route logs directly to Cloud Logging API.\n - Some languages can output logs to `stdout` and `stderr` by using the library.\n - Disadvantages\n\n - Application crashes break sending logs to your Google Cloud project.\n- Ops Agent\n\n - Advantages\n\n - The Ops Agent can send logs and metrics by using stable open source technologies: Fluent Bit for log collection and the OpenTelemetry Collector for metric collection.\n - You can collect both logs and metrics from many common applications; see [Monitor and collect logs from third-party\n applications](/stackdriver/docs/solutions/agents/ops-agent/third-party).\n - You can retain logs in your local environment.\n - You might be able to recover logs from application crashes.\n - The Ops Agent is under active development.\n - Disadvantages\n\n - Fluent Bit only supports UTF-8 encoding. It doesn't support encoding conversion.\n- Legacy Logging agent\n\n - Advantages\n - The agent uses Fluentd to collect logs, which supports encoding conversion.\n - You can retain logs in your local environment.\n - You might be able to recover logs from application crashes.\n - Disadvantages\n - The agent is currently supported but is not under active development.\n- `stdout` and `stderr` logs automatically sent to your Google Cloud project\n\n - Advantages\n - This process is a common way to emit logs to local environments.\n - You can use arbitrary logging libraries.\n - You might be able to recover logs from application crashes.\n - Disadvantages\n - Not all environments automatically route logs to Logging."]]
