總覽
當要求傳送至您的應用程式時,App Engine 會自動寫入要求記錄。在處理要求的期間,應用程式也可寫入應用程式記錄。本頁將說明如何從應用程式寫入應用程式記錄檔、如何在Google Cloud 主控台查看記錄,以及如何瞭解 App Engine 在要求期間寫入的要求記錄資料。
如要瞭解如何下載記錄資料,請參閱「記錄匯出總覽」。
要求記錄和應用程式記錄的比較
記錄資料有兩種,分別是要求記錄和應用程式記錄。要求記錄是由 App Engine 針對應用程式處理的各項要求自動寫入的,其中含有專案 ID、HTTP 版本等資訊。如需要求記錄可用屬性的完整清單,請參閱 RequestLog 一文。如需要求記錄欄位的說明,另請參閱要求記錄表。
每筆要求記錄都包含一份與該要求相關聯的應用程式記錄 (AppLog) 清單,該清單是透過 RequestLog.app_logs
屬性傳回。每筆應用程式記錄都包含寫入記錄的時間、記錄訊息與記錄層級。
寫入應用程式記錄檔
您可以參閱 Python.org 上的標準 Python 記錄模組說明文件。Python 記錄模組可讓開發人員記錄下列 5 種嚴重性等級:
- 偵錯
- 資訊
- 警告
- 錯誤
- 重要
以下範例說明如何使用不同的記錄等級:
Google Cloud 控制台中的記錄網址格式
以下範例網址是 Google Cloud 主控台中記錄網址格式的範例:
https://console.cloud.google.com/logs?filters=request_id:000000db00ff00ff827e493472570001737e73686966746361727331000168656164000100
在主控台讀取記錄
如要查看在標準環境中執行的應用程式所寫入的記錄,請使用記錄檔探索工具。
一般來說,App Engine 記錄包含採用 Apache 合併記錄格式的資料,以及一些特殊的 App Engine 欄位,如以下記錄範例所示:
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=
瞭解要求記錄欄位
下表按照顯示順序列出欄位,並提供說明:
欄位順序 | 欄位名稱 | 是否一律會顯示? | 說明 |
---|---|---|---|
1 | 用戶端位址 | 是 | 用戶端 IP 位址,範例:192.0.2.0 |
2 | RFC 1413 識別資訊 | 否 | 用戶端的 RFC 1413 識別資訊,幾乎一律是 - 字元 |
3 | 使用者 | 否 | 只有在應用程式使用 Users API 且使用者已登入時才會顯示。這個值是 Google 帳戶的「暱稱」部分;以 [email protected] 這個 Google 帳戶為例,記錄在此欄位的暱稱就是 test 。 |
4 | 時間戳記 | 是 | 要求時間戳記,範例:[27/Jun/2014:09:11:47 -0700] |
5 | 要求查詢字串 | 是 | 要求的第一行,包括方法、路徑和 HTTP 版本,範例:GET / HTTP/1.1 |
6 | HTTP 狀態碼 | 是 | 傳回的 HTTP 狀態碼,例如:200 |
7 | 回應大小 | 是 | 回應的位元組大小,例如:414 |
8 | 參照網址路徑 | 否 | 如果沒有參照網址,則記錄不會包含路徑,只會包含 - 。參照網址路徑範例:"http://www.example.com/index.html" 。 |
9 | 使用者代理程式 | 是 | 向網路伺服器提供瀏覽器和作業系統識別資訊,範例:Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/35.0.1916.153 Safari/537.36 |
10 | 主機名稱 | 是 | 用戶端用以連接到 App Engine 應用程式的主機名稱,示例:(1-dot-calm-sylph-602.appspot.com ) |
11 | 經過時間 | 是 | App Engine 處理要求所花費的總時間,以毫秒為單位。此時間長度不含在用戶端與執行應用程式執行個體的伺服器之間所花費的時間,範例:ms=195 。 |
12 | CPU 毫秒數 | 是 | 完成要求所需的 CPU 毫秒數。這是 CPU 實際執行應用程式程式碼所花費的毫秒數,以基準 1.2 GHz Intel x86 CPU 為單位。如果實際使用的 CPU 速度比基準值快,CPU 毫秒可能會大於上述定義的實際時鐘時間。範例:cpu_ms=42 |
13 | 結束代碼 | 否 | 只有在執行個體取得要求後關閉的情況下才會顯示,格式為 exit_code=XXX ,其中 XXX 是對應至執行個體關閉理由的 3 位數數字。系統不會記錄結束代碼,因為這類代碼主要是用於協助 Google 找出和修正問題。 |
14 | 預估費用 | 是 | 已淘汰。1000 筆類似要求的預估費用,以美元為單位。範例:cpm_usd=0.000046 |
15 | 佇列名稱 | 否 | 所用工作佇列的名稱,只有在要求使用了工作佇列時才會顯示。範例:queue_name=default |
16 | 工作名稱 | 否 | 工作佇列中針對這項要求執行的工作名稱。只有在要求造成工作排入佇列時才會顯示。範例:task_name=7287390692361099748 |
17 | 待處理的佇列 | 否 | 只有在要求於待處理佇列中停留了一段時間的情況下才會顯示。如果您的記錄中有許多這類佇列,且/或值偏高,可能代表您需要更多執行個體來處理流量。範例:pending_ms=195 |
18 | 載入要求 | 否 | 只有在要求是載入要求時才會顯示。這表示系統必須啟動執行個體。在理想情況下,您的執行個體應盡可能長時間運作、保持在良好狀態,且在系統將其回收並再次啟動前,能夠處理大量的要求;也就是說,您不應在記錄中看到太多這類要求。範例:loading_request=1 。 |
19 | 執行個體 | 是 | 負責處理要求的執行個體的專屬 ID。範例:instance=00c61b117cfeb66f973d7df1b7f4ae1f064d |
20 | 版本 | 是 | 目前在 App Engine 實際工作環境中所用的 App Engine 版本: |
配額與限制
應用程式會受到下列記錄相關配額影響:
- 透過 Logs API 擷取的記錄資料。
- 記錄內容擷取的配額與保留期。
擷取資料的配額
每天透過 Logs API 呼叫擷取的記錄資料中,前 100 MB 的資料為免費。超過 100 MB 的資料每 GB 會產生 $0.12 美元的費用。
記錄內容擷取配額
App Engine 應用程式的記錄功能是由 Google Cloud Observability 提供。如要進一步瞭解記錄費用與限制,請參閱 Google Cloud Observability 定價。如要長期儲存記錄,您可以從 Google Cloud Observability 將記錄匯出至 Cloud Storage、BigQuery 和 Pub/Sub。
開發伺服器與 Logs API
根據預設,記錄只會儲存在開發伺服器的記憶體中,且可在您想測試 Logs API 功能時存取。如果您想將開發伺服器中的記錄保留在您自選的磁碟位置,請在 --logs_path
指令列選項中提供所要的路徑和檔案名稱,如下所示:
python2 [DEVAPPSERVER_ROOT]/google_appengine/dev_appserver.py --logs_path=your-path/your-logfile-name your-app-directory