Anwendungslogs lesen und schreiben

Überblick

Wenn eine Anfrage an Ihre Anwendung gesendet wird, erstellt App Engine automatisch ein Anfragelog. Während der Bearbeitung der Anfrage kann die Anwendung auch Anwendungslogs schreiben. Auf dieser Seite erfahren Sie, wie Sie Anwendungslogs aus Ihrer Anwendung heraus schreiben, wie Sie in der Google Cloud Console das Logging aufrufen, und was die Anfragelogdaten bedeuten, die die App Engine während der Anfrage schreibt.

Informationen zum Herunterladen von Logdaten finden Sie in der Übersicht über den Logexport.

Wichtig: Bei Verwendung des Entwicklungs-Anwendungsservers werden Logs standardmäßig nicht beibehalten. Weitere Informationen zum Erstellen von Logs finden Sie unter Entwicklungsserver und die Logs API.

Request-Protokolle und Anwendungsprotokolle

Es gibt zwei Kategorien von Logdaten: Anfragelogs und Anwendungslogs. Ein Request-Protokoll wird von App Engine automatisch für jeden Request generiert, den Ihre Anwendung verarbeitet, und enthält Informationen wie die Projekt-ID, die HTTP-Version usw. Eine vollständige Liste der verfügbaren Properties für Request-Protokolle finden Sie unter RequestLog. Eine Beschreibung der Felder von Anfragelogs finden Sie in der Tabelle der Anfragelogs.

Jedes Anfragelog enthält eine Liste der mit dieser Anfrage verknüpften Anwendungslogs (AppLog), die mit dem Attribut RequestLog.app_logs zurückgegeben werden. Jedes Anwendungslog gibt die Uhrzeit an, zu der es erstellt wurde, die Lognachricht und die Logebene.

Hinweis: Ein Anfragelog kann maximal 1.000 Anwendungslogs enthalten. Wenn Sie mehr als 1.000 Anwendungslogs hinzufügen, werden ältere Logs überschrieben.

Anwendungslogs schreiben

Wichtig: Einzelne Logeinträge einer Anwendung sind auf 16 KB begrenzt. Alles, was darüber hinausgeht, wird nicht in das Anwendungslog geschrieben.

Es kann nützlich sein, die Dokumentation für das standardmäßige Python-Logging-Modul unter Python.org zu lesen.

Mit dem Python-Protokollierungsmodul können Entwickler die folgenden 5 Wichtigkeitsstufen protokollieren:

• debug
• Info
• Warnung
• Fehler
• Kritisch

Im folgenden Beispiel wird die Verwendung von verschiedenen Protokollierungsstufen veranschaulicht:

import logging

import webapp2

class MainPage(webapp2.RequestHandler):
    def get(self):
        logging.debug('This is a debug message')
        logging.info('This is an info message')
        logging.warning('This is a warning message')
        logging.error('This is an error message')
        logging.critical('This is a critical message')

        try:
            raise ValueError('This is a sample value error.')
        except ValueError:
            logging.exception('A example exception log.')

        self.response.out.write('Logging example.')

app = webapp2.WSGIApplication([
    ('/', MainPage)
], debug=True)

URL-Logformat in der Google Cloud Console

Die folgende Beispiel-URL veranschaulicht das URL-Logformat in der Google Cloud Console:

https://console.cloud.google.com/logs?filters=request_id:000000db00ff00ff827e493472570001737e73686966746361727331000168656164000100

Hinweis: Die URL enthält filter_type nicht mehr.

Logs in der Console lesen

Hinweis: Die hier beschriebenen Logs werden in der Loganzeige als sichtbar dargestellt.

Zum Ansehen der Logs, die von Anwendungen in der Standardumgebung geschrieben wurden, verwenden Sie den Logs Explorer.

Ein typisches App Engine-Log enthält Daten im kombinierten Logformat von Apache sowie einige spezielle App Engine-Felder wie im folgenden Beispiellog gezeigt:

192.0.2.0 - test [27/Jun/2014:09:11:47 -0700] "GET / HTTP/1.1" 200 414
"http://www.example.com/index.html"
Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/35.0.1916.153 Safari/537.36"
"1-dot-calm-sylph-602.appspot.com" ms=195 cpu_ms=42 cpm_usd=0.000046
loading_request=1 instance=00c61b117cfeb66f973d7df1b7f4ae1f064d app_engine_release=

Grundlegendes zu Anfragelogfeldern

In der folgenden Tabelle werden die Felder in der Reihenfolge ihres Auftretens aufgeführt und beschrieben:

Feldreihenfolge	Feldname	Immer angezeigt?	Beschreibung
1	Client-Adresse	Ja	IP-Adresse des Clients. Beispiel: 192.0.2.0
2	RFC 1413-Identität	Nein	RFC1413-Identität des Clients. Wird fast immer durch das Zeichen - dargestellt.
3	Nutzer	Nein	Wird nur angezeigt, wenn die Anwendung die Users API verwendet und der Nutzer angemeldet ist. Dieser Wert ist der Aliasteil des Google-Kontos. Beispiel: Bei einem Google-Konto mit dem Namen [e-mail] ist der in diesem Feld erfasste Alias test.
4	Zeitstempel	Ja	Zeitstempel der Anfrage. Beispiel: [27/Jun/2014:09:11:47 -0700]
5	Anfrage-Abfragestring	Ja	Erste Zeile der Anfrage, die Methode, Pfad und HTTP-Version enthält. Beispiel: GET / HTTP/1.1
6	HTTP-Statuscode	Ja	Zurückgegebener HTTP-Statuscode. Beispiel: 200
7	Größe der Antwort	Ja	Antwortgröße in Byte. Beispiel: 414
8	Verweispfad	Nein	Wenn es keinen Verweis gibt, enthält das Log keinen Pfad, sondern nur -. Beispiel für einen Verweispfad: "http://www.example.com/index.html".
9	User-Agent	Ja	Identifiziert den Browser und das Betriebssystem für den Webserver. Beispiel: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/35.0.1916.153 Safari/537.36
10	Hostname	Ja	Der Hostname, der vom Client für die Verbindung mit der App Engine-Anwendung verwendet wird. Beispiel: (1-dot-calm-sylph-602.appspot.com).
11	Wanduhrzeit	Ja	Effektive Gesamtzeit in Millisekunden, in der App Engine die Anfrage verarbeitet hat. Dieser Zeitwert beinhaltet nicht die Zeit, die für die Kommunikation zwischen dem Client und dem Server benötigt wurde, auf dem die Instanz Ihrer Anwendung ausgeführt wird. Beispiel: ms=195.
12	CPU-Millisekunden	Ja	CPU-Millisekunden, die zum Ausführen der Anfrage erforderlich waren. Dies ist die Anzahl der Millisekunden, die von der CPU, die den Anwendungscode tatsächlich ausführt, benötigt wurden, ausgedrückt als Vergleich mit einer als Referenz-Intel x86-CPU mit 1,2 GHz. Wenn die tatsächlich verwendete CPU schneller ist als die Referenzversion, kann die Anzahl der CPU-Millisekunden höher sein als die oben definierte tatsächliche Taktzeit. Beispiel: cpu_ms=42.
13	Exit-Code	Nein	Wird nur angezeigt, wenn die Instanz nach dem Abrufen der Anfrage heruntergefahren wurde. Die Anzeige erfolgt im Format exit_code=XXX, wobei XXX eine dreistellige Zahl ist, die für die Ursache des Herunterfahrens der Instanz steht. Die Exit-Codes sind nicht dokumentiert, da sie in erster Linie dazu genutzt werden, Google beim Ermitteln und Beheben von Problemen zu unterstützen.
14	Geschätzte Kosten	Ja	VERWORFEN. Geschätzte Kosten von 1.000 Anfragen wie dieser, in USD. Beispiel: cpm_usd=0.000046
15	Name der Warteschlange	Nein	Der Name der verwendeten Aufgabenwarteschlange. Wird nur angezeigt, wenn die Anfrage eine Aufgabenwarteschlange verwendet hat. Beispiel: queue_name=default
16	Aufgabenname	Nein	Der Name der Aufgabe, die in der Aufgabenwarteschlange für diese Anfrage ausgeführt wurde. Nur vorhanden, wenn die Anfrage dazu geführt hat, dass die Aufgabe in eine Warteschlange aufgenommen wurde. Beispiel: task_name=7287390692361099748
17	Warteschlange für ausstehende Anfragen	Nein	Wird nur angezeigt, wenn sich eine Anfrage für einige Zeit in einer Warteschlange befunden hat. Wenn viele davon in Ihren Logs vorhanden und/oder die Werte hoch sind, kann dies ein Hinweis darauf sein, dass Sie für den anfallenden Traffic mehr Instanzen benötigen. Beispiel: pending_ms=195
18	Ladeanfrage	Nein	Wird nur angezeigt, wenn die Anfrage eine Ladeanfrage ist, durch die eine Instanz gestartet werden musste. Im Idealfall sollten Ihre Instanzen so lange wie möglich aktiv und funktionsfähig sein und eine möglichst große Anzahl von Anfragen verarbeiten, bevor sie anderweitig verwendet und neu gestartet werden müssen. Das bedeutet, dass Sie von diesen Einträgen nicht zu viele in Ihren Logs sehen sollten. Beispiel: loading_request=1
19	Instanz	Ja	Eindeutige Kennung für die Instanz, die die Anfrage verarbeitet. Beispiel: instance=00c61b117cfeb66f973d7df1b7f4ae1f064d
20	Version	Ja	Die aktuelle App Engine-Version, die in der App Engine-Produktionsumgebung verwendet wird: .

Kontingente und Limits

Für Ihre Anwendung gelten die folgenden logspezifischen Kontingente:

• Kontingent für über die Logs API abgerufene Logdaten
• Kontingent für die Logaufnahme und -aufbewahrung

Kontingent für abgerufene Daten

Die ersten 100 Megabyte der Logdaten, die pro Tag über die Logs API abgerufen werden, sind kostenlos. Daten über 100 Megabyte führen zu einer Gebühr von 0,12 $/GB.

Kontingent für die Logaufnahme

Das Logging für App Engine-Anwendungen erfolgt durch Google Cloud Observability. Weitere Informationen zu den Logging-Kosten und -Limits finden Sie unter Google Cloud Observability – Preise. Für die langfristige Speicherung von Logs können Sie Logs aus Google Cloud Observability nach Cloud Storage, BigQuery und Pub/Sub exportieren.

Entwicklungsserver und Logs API

Wichtig:

• Befolgen Sie vor dem Ausführen des lokalen Entwicklungsservers die Anleitung zur Einrichtung.. Unabhängig von der Laufzeit- oder Sprachversion Ihrer Anwendung müssen Sie dev_appserver.py mit Python 3 ausführen und die Umgebungsvariable CLOUDSDK_DEVAPPSERVER_PYTHON in Ihrer Shell auf den Pfad Ihres Python 2-Interpreters festlegen.
• Das Tool dev_appserver unterstützt die Entwicklung von Python 3-Anwendungen unter Windows nicht.

Standardmäßig werden Logs nur im Arbeitsspeicher des Entwicklungsservers gespeichert. Sie können darauf zugreifen, wenn Sie das Logs API-Feature testen möchten. Wenn Sie Logs vom Entwicklungsserver an einem selbst gewählten Speicherort auf dem Laufwerk speichern möchten, geben Sie den gewünschten Pfad und den Dateinamen in der Befehlszeilenoption --logs_path folgendermaßen an:

   python2 [DEVAPPSERVER_ROOT]/google_appengine/dev_appserver.py --logs_path=your-path/your-logfile-name your-app-directory