Cloud Run Functions-Logs aufrufen und schreiben
Laufzeitlogs
Cloud Run Functions bietet standardmäßig einfaches Laufzeit-Logging. Logs, die in stdout
oder stderr
geschrieben wurden, erscheinen automatisch in der Google Cloud Console.
Verwenden Sie für ein erweitertes Logging die Cloud Logging-Clientbibliotheken.
Standardmäßig ist die Lognutzlast ein einfacher Textstring, wie in den folgenden Snippets dargestellt. Der String wird im Feld textPayload
des Logeintrags gespeichert.
Node.js
Den meisten Logeinträgen ist keine Logebene zugeordnet. Dazu gehören:- Logs, die mit
console.log()
,console.info()
,console.warn()
oderconsole.error()
ausgegeben wurden - Logs, die direkt in
stdout
oderstderr
geschrieben wurden
Interne Systemmeldungen haben die Logebene DEBUG
.
Python
- Logs, die in den Standardausgabe- oder Standardfehlerkanal geschrieben wurden, gehören zu keiner bestimmten Logebene.
- Interne Systemmeldungen haben die Logebene
DEBUG
.
Go
- Logs, die in
stdout
oderstderr
geschrieben wurden, gehören zu keiner bestimmten Logebene. - Interne Systemmeldungen haben die Logebene
DEBUG
.
Java
- Logs, die in
stdout
oderstderr
geschrieben wurden, gehören zu keiner bestimmten Logebene. - Interne Systemmeldungen haben die Logebene
DEBUG
.
C#
- Text, der in
stdout
undstderr
geschrieben wurde (z. B. überConsole.WriteLine
bzw.Console.Error.WriteLine
), hat keine Logebene. - ASP.NET Core-Logging-Ebenen werden Cloud Logging-Ebenen so zugeordnet:
LogLevel.Trace
undLogLevel.Debug map
zu Cloud Logging-DEBUG
.LogLevel.Information
ist Cloud Logging-INFO
zugeordnet.LogLevel.Warning
ist Cloud Logging-WARNING
zugeordnet.LogLevel.Error
ist Cloud Logging-ERROR
zugeordnet.LogLevel.Critical
ist Cloud Logging-CRITICAL
zugeordnet.
Ruby
Logeinträgen ist keine Logebene zugeordnet.
PHP
Strukturierte Logs schreiben
Die oben beschriebenen standardmäßigen Textlogs gehören zu keiner bestimmten Logebene.
Wenn Sie Logeinträge oder andere bestimmte Felder in Ihre Logeinträge aufnehmen möchten, können Sie Logs in Form einer einzelnen Zeile mit serialisiertem JSON in stdout
oder stderr
schreiben. Diese Zeile wird von Cloud Run Functions erfasst und geparst und in das Feld jsonPayload
statt in textPayload
eingefügt. Die folgenden Snippets veranschaulichen, wie derartige strukturierte Logs geschrieben werden.
Node.js
Python
Strukturierte Logging-Unterstützung ist ab Python 3.8 verfügbar.
Go
Die Struktur für jeden Logeintrag wird vom Typ Entry
bereitgestellt:
Wenn eine Eintragsstruktur protokolliert wird, wird die Methode String
aufgerufen, um sie in das von Cloud Logging erwartete JSON-Format zu überführen:
Java
Aktivieren Sie das JSON-Logging mit Logback und SLF4J. Dazu aktivieren Sie den Logstash-JSON-Encoder in Ihrer logback.xml
-Konfiguration.
Spezielle JSON-Felder in Nachrichten verarbeiten
Wenn Sie ein strukturiertes Log als JSON-Wörterbuch erstellen, werden bestimmte Felder aus jsonPayload
entfernt und in das entsprechende Feld im erstellten LogEntry
geschrieben, wie in der Dokumentation für bestimmte Felder beschrieben.
Wenn Ihre JSON-Datei beispielsweise das Attribut severity
enthält, wird es aus jsonPayload
entfernt und stattdessen als severity
des Logeintrags angezeigt. Das Attribut message
wird als Hauptanzeigentext des Logeintrags verwendet, sofern vorhanden.
Logs mit Clientbibliotheken schreiben
Cloud Logging-Clientbibliotheken bieten eine alternative Möglichkeit, Logs zu schreiben. Mit diesen Bibliotheken können Sie die Logging-Standardmechanismen Ihrer Programmiersprache verwenden und in verschiedene unterstützte Logging-Frameworks einbinden. Clientbibliotheken vereinfachen auch die Ausfüllung der speziellen JSON-Felder, indem einige Informationen automatisch erfasst und Schnittstellen bereitgestellt werden, um die Felder entsprechend auszufüllen.
Sie können Clientbibliotheken verwenden, um Logs mit der Cloud Logging API synchron oder asynchron zu schreiben. Einige Clientbibliotheken unterstützen auch das Schreiben strukturierter Logs direkt in stdout
oder stderr
. Wenn Sie Logs asynchron schreiben, kann eine unerwartete Funktionsbeendigung zu Logverlusten führen.
Beachten Sie auch, dass das synchrone Logging mit der Logging API die Ausführungszeit der Funktion erhöht, da sie auf den Abschluss von API-Aufrufen wartet.
Laufzeitlogs ansehen
Befehlszeilentool verwenden
Logs für Cloud Run Functions können über die Cloud Logging-UI und die Google Cloud CLI aufgerufen werden.
Wenn Sie Logs mit der gcloud CLI aufrufen möchten, verwenden Sie den Befehl gcloud functions logs read
:
gcloud functions logs read --gen2
Zum Anzeigen der Logs für eine bestimmte Funktion geben Sie den Funktionsnamen als Argument an:
gcloud functions logs read FUNCTION_NAME --gen2
Bei Funktionen in anderen Sprachen können die Logs der gleichen Funktionsausführung durch Verwendung des Anfrageheaders x-cloud-trace-context
korreliert werden.
Informationen zu allen Loganzeigeoptionen finden Sie in der Dokumentation zu gcloud functions logs read
.
Logging-Dashboard verwenden
Sie können Laufzeitlogs für Cloud Run Functions auch in der Google Cloud Console aufrufen.
Logging API verwenden
Laufzeitlogs können auch über die Cloud Logging API geschrieben und abgerufen werden. Die Cloud Logging-Clientbibliotheken bieten eine idiomatische Schnittstelle zur Logging API:
Node.js
Weitere Informationen finden Sie in der Referenz zur Node.js-Clientbibliothek.Python
Weitere Informationen finden Sie in der Referenz zur Python-Clientbibliothek.Go
Weitere Informationen finden Sie in der Referenz zur Go-Clientbibliothek.Java
Weitere Informationen finden Sie in der Referenz zur Java-Clientbibliothek.C#
Ruby
PHP
Weitere Logging-Optionen für Java finden Sie unter Java Logging.
Informationen zu Instanzskalierungs-Logs
Wenn neue Instanzen für Ihre Funktion gestartet werden, enthält Cloud Logging Logeinträge unter dem Lognamen varlog/system
, die Aufschluss darüber geben, warum die jeweilige Instanz erstellt wurde. Der Logeintrag hat folgendes Format:
Starting new instance. Reason: REASON - DESCRIPTION
In der folgenden Tabelle finden Sie eine Aufschlüsselung der Instanzbeschreibungen:
Grund | Beschreibung |
---|---|
CUSTOMER_MIN_INSTANCE |
Vom Kunden konfigurierte Mindestinstanz für die Funktion. |
SCHEDULED |
Die Instanz wurde aufgrund konfigurierter Skalierungsfaktoren (z. B. CPU-Auslastung, Anfragen-Durchsatz usw.) und ihrer Ziele gestartet. |
OVERFLOW |
Instanz gestartet, da für den aktuellen Traffic keine Kapazität vorhanden war. |
Auf Laufzeitlogs reagieren
Sie können auf Cloud Logging-Ereignisse reagieren, indem Sie ihre Logs an eine Cloud Run Function weiterleiten. Weitere Informationen finden Sie auf der Seite Trigger einer zweiten Partei mit Cloud Logging.
Build-Image-Logs aufrufen
Sie können auch die Logs für das Erstellen von Cloud Functions-Images während des Bereitstellungsprozesses aufrufen. Weitere Informationen erhalten Sie über den Link.