Übersicht
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.
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.
Anwendungslogs schreiben
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:
- Fehlerbehebung
- Info
- Warnung
- Fehler
- Kritisch
Im folgenden Beispiel wird die Verwendung von verschiedenen Protokollierungsstufen veranschaulicht:
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
Logs in der Console lesen
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 | Clientadresse | 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 test@example.com 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-Release-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
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