本文協助您辨識並解決最常需要 Azure 容器應用程式 支援升級的部署失敗情境。 每個情境包含症狀、入口網站與 CLI 診斷步驟，以及解決方案。
在快速參考表中找到你的症狀，並點選配對情境的連結。
症狀快速參照
| 徵狀 | 劇本 |
|---|---|
| 部署因佈建錯誤而失敗，且未建立任何修訂版本 | 影像拉取失敗 |
已建立修訂，但狀態為 Failed 或 Degraded |
容器當機與啟動失敗 |
| 密鑰或環境變數在執行階段為空或遺失 | 秘密存取問題 |
| 金鑰保存庫 參考在部署期間或執行階段失敗 | 金鑰保存庫 參考錯誤 |
| 受控識別呼叫傳回 401 或 403 | 受控識別設定錯誤 |
| Init 容器當機或失敗，應用程式永遠無法啟動 | 初始化時序問題 |
已佈建修訂，但標示為 Degraded |
健康探針故障 |
| 應用程式運作正常，但請求會傳回錯誤或沒有回應 | 入口與流量路由問題 |
| 登錄檔認證失敗（401 或未授權） | 容器登錄驗證 |
查看位置：診斷介面
請使用以下診斷介面來調查部署失敗問題。
| Surface | 它顯示的內容 | 如何存取 |
|---|---|---|
| 診斷並解決問題 | 常見問題的自動偵測器、故障排除類別及引導式分析。 | 在 Azure 入口網站，進入你的容器應用程式，選擇「診斷並解決問題」。 |
| 系統記錄檔 | 平台層級事件：影像拉取狀態、探測結果、身份錯誤、秘密同步結果。 |
az containerapp logs show -g <RESOURCE_GROUP_NAME> -n <CONTAINER_APP_NAME> --type system --tail 50 或 Log Analytics ContainerAppSystemLogs_CL 資料表。 |
| 主控台日誌 | 應用程式 stdout/stderr：堆疊追蹤、啟動訊息、執行時錯誤。 |
az containerapp logs show -g <RESOURCE_GROUP_NAME> -n <CONTAINER_APP_NAME> --tail 100 或入口網站記錄資料流窗格。 |
| HTTP 日誌 | 入口層請求日誌：狀態碼、延遲、路徑、重試、回應細節。 透過環境上的 Azure 監視器診斷設定選擇加入。 | Log Analytics ContainerAppHTTPLogs 資料表。 |
| 修訂細節屬性 |
provisioningState，provisioningError，healthState，runningState，runningStateDetails。 |
az containerapp revision show -g <RESOURCE_GROUP_NAME> -n <CONTAINER_APP_NAME> --revision <REV> -o json 或入口網站修訂窗格。 |
| 部署時間錯誤 | 未建立修訂時，會顯示應用程式層級的 provisioningState 和 provisioningError。 |
az containerapp show -g <RESOURCE_GROUP_NAME> -n <CONTAINER_APP_NAME> -o json |
映像檔提取失敗
映像拉取失敗是部署錯誤最常見的原因之一。 它們通常發生在 Azure 容器應用程式 尚未建立可用版本之前。
癥狀
- 未建立修訂。
-
provisioningState是Failed。 - 錯誤訊息提及
ImagePullBackOff、UNAUTHORIZED或manifest unknown。
查看位置：映像提取診斷
在 Azure 入口網站，前往容器應用程式>修訂（清單為空或顯示輸入失敗），>診斷並解決問題，然後搜尋「image」。
# Check app-level provisioning state and error
az containerapp show -g <RESOURCE_GROUP_NAME> -n <CONTAINER_APP_NAME> \
--query "{provisioning:properties.provisioningState, error:properties.provisioningError, latestRevision:properties.latestRevisionName}" -o json
# List revisions (expect empty or failed)
az containerapp revision list -g <RESOURCE_GROUP_NAME> -n <CONTAINER_APP_NAME> \
--query "[].{name:name, health:properties.healthState, provisioning:properties.provisioningState}" -o table
常見原因與解決方案
| 原因 | 錯誤訊號 | 解決方案 |
|---|---|---|
| 圖片標籤不存在 |
manifest unknown、tag not found |
請確認你的登記清單中確實存在這個標籤： az acr repository show-tags --name <AZURE_CONTAINER_REGISTRY_NAME> --repository <REPOSITORY_NAME> |
| 登錄檔需要驗證 | UNAUTHORIZED: authentication required |
在容器應用程式上設定登錄憑證。 使用系統管理員認證或受控識別進行 ACR 提取。 請參見 容器登錄驗證。 |
| 登錄檔名錯誤 |
name unknown，DNS 解析失敗 |
確認 --image 值使用的是正確的 <REGISTRY>.azurecr.io 主機名稱。 |
| 防火牆或 NSG 封鎖登錄 | 連線超時 | 如果你用的是自訂 VNet，請確保登錄檔有外站存取權。 新增 AzureContainerRegistry 服務標籤或 FQDN 規則。 |
容器當機與啟動失敗
當有修訂但工作負載無法啟動或無法持續運行時，請使用此區段。
癥狀
- 已建立修訂，但
healthState為Unhealthy。 -
runningState是Failed。 - 主控台日誌可能是空的（容器在寫入輸出前退出）。
在哪裡查看：當機與啟動診斷資訊
在 Azure 入口網站中，前往 容器應用程式>修訂，選取失敗的修訂，然後開啟 [事件] 索引標籤。檢查是否有 BackOff 或 CrashLoopBackOff 事件。
# Inspect revision detail
az containerapp revision show -g <RESOURCE_GROUP_NAME> -n <CONTAINER_APP_NAME> --revision <REV> \
--query "{health:properties.healthState, running:properties.runningState, details:properties.runningStateDetails, error:properties.provisioningError}" -o json
# Pull console logs (if any output was written)
az containerapp logs show -g <RESOURCE_GROUP_NAME> -n <CONTAINER_APP_NAME> --tail 100
# Pull system logs for platform-level events
az containerapp logs show -g <RESOURCE_GROUP_NAME> -n <CONTAINER_APP_NAME> --type system --tail 50
常見原因與解決方案
| 原因 | 錯誤訊號 | 解決方案 |
|---|---|---|
| 應用程式啟動時當機 | 主控台記錄中的堆疊追蹤 | 修正應用程式錯誤。 如果記錄是空的，表示當機發生在 stdout 排清之前。 加入早期日誌，或設定執行時關閉輸出緩衝（例如）。 PYTHONUNBUFFERED=1 |
| 無效指令或入口點 |
exec format error、executable file not found |
確認容器的 command 和 args 是否符合映像檔的要求。 檢查 properties.template.containers[].command 的 az containerapp revision show。 |
| 缺少環境變數 |
KeyError、undefined、Null 參考 |
確認所有必要的環境變數都已設定好。 詳見 秘密存取問題。 |
| 資源不足 | OOMKilled |
增加容器的記憶體與 CPU 限制： az containerapp update -g <RESOURCE_GROUP_NAME> -n <CONTAINER_APP_NAME> --cpu 1.0 --memory 2.0Gi。 |
秘密存取問題
使用此區段來排解執行時遺失或空缺的秘密值，這些值會破壞應用程式設定。
癥狀
- 容器啟動後，應用程式失敗，因為預期的設定值為空或缺失。
- 參照機密的環境變數沒有值。
查看位置：祕密參考診斷
在 Azure 入口網站中，前往 容器應用程式>設定>祕密，確認該祕密存在。 接著到 容器應用程式>修訂，選擇版本，並檢查 容器細節>環境變數 以確認參考是否正確。
# List secrets defined on the app
az containerapp secret list -g <RESOURCE_GROUP_NAME> -n <CONTAINER_APP_NAME> -o table
# Show the revision template to verify env var references
az containerapp revision show -g <RESOURCE_GROUP_NAME> -n <CONTAINER_APP_NAME> --revision <REV> \
--query "properties.template.containers[].env" -o json
常見原因與解決方案
| 原因 | 錯誤訊號 | 解決方案 |
|---|---|---|
| 祕密名稱不相符 | Env var value 是空的 | 環境中的 secretRef 變數必須與秘密名稱完全相符（大小寫區分）。 |
| 秘密未定義 | 部署錯誤：引用了未知的密鑰 | 部署前先定義秘密： az containerapp secret set -g <RESOURCE_GROUP_NAME> -n <CONTAINER_APP_NAME> --secrets mysecret=myvalue。 |
| 密鑰已更新，但未重新啟動修訂版本 | 舊值仍保留 | 部署新版本或重新啟動現有版本： az containerapp revision restart -g <RESOURCE_GROUP_NAME> -n <CONTAINER_APP_NAME> --revision <REV>。 僅僅更新秘密不會觸發新的修訂。 |
| 修訂參考祕密時，祕密已遭刪除 | 貨櫃無法啟動 | 部署一個新的版本，移除對已刪除秘密的引用，然後停用舊版本。 |
Important
在 Container Apps 中，祕密的範圍是應用程式，但環境變數參考的範圍是修訂。 更改秘密值不會自動傳到執行中的修訂版本。 您必須建立新的版本或重新啟動現有版本，更新後的值才會生效。
金鑰保存庫 參考作業失敗
當 金鑰保存庫 支援的秘密在部署或應用程式執行時無法解決時，請使用此區段。
癥狀
- 部署失敗或秘密值無法取得。
- 系統日誌提及 金鑰保存庫 存取錯誤。
-
provisioningError提到對 金鑰保存庫 的驗證或授權失敗。
查看位置：金鑰保存庫 存取診斷
在 Azure 入口網站，前往容器應用程式>設定>的秘密（請在 金鑰保存庫 參考中尋找警告圖示）。 接著到容器應用程式>診斷，解決問題並搜尋「金鑰保存庫」。
# List secrets and check for Key Vault reference status
az containerapp secret list -g <RESOURCE_GROUP_NAME> -n <CONTAINER_APP_NAME> -o json
# Verify managed identity is assigned
az containerapp identity show -g <RESOURCE_GROUP_NAME> -n <CONTAINER_APP_NAME>
常見原因與解決方案
| 原因 | 錯誤訊號 | 解決方案 |
|---|---|---|
| 未啟用管理身份 | Managed identity not configured |
啟用系統指派或使用者指派的管理身份： az containerapp identity assign -g <RESOURCE_GROUP_NAME> -n <CONTAINER_APP_NAME> --system-assigned。 |
| 缺少 RBAC 角色 |
Authorization failed、Access denied |
將 金鑰保存庫 上的 金鑰保存庫 Secrets User 角色授與受控識別：az role assignment create --role "金鑰保存庫 Secrets User" --assignee <IDENTITY_PRINCIPAL_ID> --scope <KEYVAULT_RESOURCE_ID>。 |
| 金鑰保存庫 防火牆阻擋存取 | 連線逾時， ForbiddenByFirewall |
將容器應用程式環境的出站 IP 加入 金鑰保存庫 防火牆，或設定私人端點。 如果使用 UDR 搭配 Azure 防火牆，也要加上AzureKeyVault服務標籤和 login.microsoft.com FQDN。 |
| 祕密在 金鑰保存庫 中已停用 | SecretDisabled |
在 金鑰保存庫 中啟用祕密：Azure 入口網站 > 金鑰保存庫 > 祕密 > 選取祕密 > 啟用。 |
| 格式錯誤的 金鑰保存庫 URI |
SecretNotFound、InvalidUri |
驗證 URI 格式： https://<vault>.vault.azure.net/secrets/<secret-name> 或 https://<vault>.vault.azure.net/secrets/<secret-name>/<version>。 |
| RBAC 角色傳播延遲 | 大約 5 分鐘後有效 | RBAC的變化可能需要長達10分鐘才能傳播。 識別權杖快取最多可保留 24 小時。 等一等再試，或是部署新的版本。 |
受控識別設定錯誤
當 Azure 服務認證失敗，即使你的應用程式設定為使用管理身份時，請使用此區塊。
癥狀
- 呼叫 Azure 服務時，應用程式代碼會收到 401（未授權）或 403（禁止）。
- 受控識別權杖擷取失敗。
該從哪裡尋找：身份與授權診斷
在 Azure 入口網站中，前往 容器應用程式>設定>身分識別（確認系統指派為 On，或已列出使用者指派的身分識別）。 接著，檢查目標資源的 IAM / 存取控制窗格是否有角色指派。
# Verify identity configuration
az containerapp identity show -g <RESOURCE_GROUP_NAME> -n <CONTAINER_APP_NAME>
# Check role assignments for the identity's principal ID
az role assignment list --assignee <PRINCIPAL_ID> --all -o table
常見原因與解決方案
| 原因 | 錯誤訊號 | 解決方案 |
|---|---|---|
| 未指派身分 | SDK 擲出 ManagedIdentityCredential 錯誤 |
指派識別：az containerapp identity assign -g <RESOURCE_GROUP_NAME> -n <CONTAINER_APP_NAME> --system-assigned。 |
| 使用錯誤的身份（系統與使用者指派） | 目標資源上出現 403 | 若使用使用者指派身份，請在程式碼中指定客戶端 ID： DefaultAzureCredential(managed_identity_client_id="<CLIENT_ID>")。 |
| 目標資源缺少角色指派 | 403 | 在目標資源上指派必要角色 (例如，在儲存體帳戶上指派 Storage Blob Data Contributor)。 |
| 初始化容器需要身分識別，但目前無法取得 | Init 容器因驗證錯誤失敗 | 在僅供消費且專用的工作負載設定環境中，init 容器 無法 使用受管理身份。 將相依於識別的邏輯移至主要容器，或使用工作負載設定檔取用環境，並在識別上設定 lifecycle: Init。 |
| 角色變更後權杖快取失效 | 403 在修復後仍持續數分鐘 | 識別權杖快取最多可保留 24 小時。 部署新的修訂以強制重新整理權杖。 |
Tip
Container Apps 提供一個內部可存取的 REST 端點，用於取得受管理身份憑證。 與其直接呼叫這個端點，不如使用 Azure Identity SDK（DefaultAzureCredential）來獲得跨環境的一致體驗。
初始化時序問題
當 init 容器導致啟動受阻，或在主容器開始處理流量前失敗時，請使用本節。
癥狀
- 應用程式從未進入運行狀態。
- 初始化容器似乎卡住或失敗。
- 系統日誌顯示初始化容器在執行，但從未完成。
查看位置：初始化容器診斷
在 Azure 入口網站，前往容器應用程式>修訂，選擇修訂版本，並開啟事件分頁。尋找初始化容器事件。
# Check revision running state
az containerapp revision show -g <RESOURCE_GROUP_NAME> -n <CONTAINER_APP_NAME> --revision <REV> \
--query "{running:properties.runningState, details:properties.runningStateDetails}" -o json
# Check init container logs
az containerapp logs show -g <RESOURCE_GROUP_NAME> -n <CONTAINER_APP_NAME> --container <INIT_CONTAINER_NAME> --tail 100
# System logs for platform events
az containerapp logs show -g <RESOURCE_GROUP_NAME> -n <CONTAINER_APP_NAME> --type system --tail 50
常見原因與解決方案
| 原因 | 錯誤訊號 | 解決方案 |
|---|---|---|
| Init 容器依賴尚未可用的服務 | 初始化容器記錄中連線遭拒或逾時 | 在初始化容器中加入重試邏輯或準備度檢查。 不要假設相依服務在初始化時即可使用。 |
| 初始化容器永不結束 | 修訂停留在 Provisioning |
確保初始化容器執行有限指令並以代碼 0 退出。 無限期執行的初始化容器會使主容器無法啟動。 |
| Init 容器需要管理身份 | 初始化容器傳回 401 或 403 | 在僅限取用和專用工作負載設定檔環境中，初始化容器無法使用受控識別。 使用工作負載設定檔取用環境，或將與身分相關的作業移至主要容器。 |
| 初始化容器映像檔拉取失敗 | 症狀和映像拉取失敗一樣 | 套用相同的登錄檔認證與映像標籤檢查。 |
| 操作順序：密鑰尚未同步 | 初始化容器讀取空白祕密 | 金鑰保存庫 的祕密同步會以非同步方式進行。 如果初始化容器依賴於 金鑰保存庫 引用的秘密，該值可能還無法取得。 對於初始化時所需的相依項目，請直接使用密密，或加入重試邏輯。 |
健康探針故障
當修訂版成功部署，但經探測檢查標記為不健康或退化時，請使用此節。
癥狀
- 版本已設定，但執行狀態為
Degraded。 - 系統日誌會顯示
Unhealthy事件及探測器故障細節。 - 這個應用程式在本地運作，但在 ACA 的健康檢查中會失敗。
查看位置：探查健全狀態診斷
在 Azure 入口網站中，前往 Container App>Application>Containers>Health probes（確認探查設定）。 接著到 容器應用程式>修訂，選擇修訂，然後打開事件。
# Check the revision's probe configuration
az containerapp revision show -g <RESOURCE_GROUP_NAME> -n <CONTAINER_APP_NAME> --revision <REV> \
--query "properties.template.containers[].probes" -o json
# System logs for probe failure events
az containerapp logs show -g <RESOURCE_GROUP_NAME> -n <CONTAINER_APP_NAME> --type system --tail 50
常見原因與解決方案
| 原因 | 錯誤訊號 | 解決方案 |
|---|---|---|
| Probe 埠口和 App 埠口不符 | 探測返回「連線遭拒」 | 把探針埠設定成跟你應用程式的監聽埠和入口 targetPort一樣。 |
| 應用程式啟動時間太慢了 | 探針在應用程式準備好前失效，修訂就會開始 Degraded |
增加存留期和整備程度探查上的 initialDelaySeconds。 這在 Java 應用程式中很常見。 |
| 探測路徑傳回非 200 狀態碼 | 探針因 HTTP 錯誤而失敗 | 確保健康檢查端點回傳 200 狀態碼。 對於 HTTP 探測，請確認路徑是否存在且回應正確。 |
| 當應用程式僅在完成初始化後才綁定時的 TCP 探測 | Probe 在應用程式開始聽之前就已經連線了 | 使用具有較高 failureThreshold 的啟動探測，讓應用程式有時間繫結其連接埠。 |
預設探針值
當你啟用入口且未設定探測器時，ACA 會套用以下預設值：
| Property | Startup | 活躍度： | 準備狀況 |
|---|---|---|---|
| Protocol | TCP | TCP | TCP |
| Port | 輸入目標連接埠 | 輸入目標連接埠 | 輸入目標連接埠 |
| 初始延遲 | 1s | 1s | 3 秒 |
| 期間 | 1s | 1s | 5 秒 |
| 失敗閾值 | 240 | 48 | N/A |
輸入和流量路由問題
當應用程式執行中但因入口或修訂流量設定錯誤而請求失敗時，請使用此區段。
癥狀
- 應用程式運作良好，但 HTTP 請求會回傳錯誤（404、502）或無回應。
- 這個應用程式可透過
az containerapp exec運作，但無法透過公開 URL 運作。
查看位置：輸入和流量診斷
在 Azure 入口網站，前往容器應用程式>設定>Ingress。 接著前往 容器應用程式>應用程式>修訂（檢查流量分配）。
# Check ingress configuration and traffic split
az containerapp show -g <RESOURCE_GROUP_NAME> -n <CONTAINER_APP_NAME> \
--query "{ingress:properties.configuration.ingress, latestReady:properties.latestReadyRevisionName}" -o json
# Verify the FQDN
az containerapp show -g <RESOURCE_GROUP_NAME> -n <CONTAINER_APP_NAME> --query "properties.configuration.ingress.fqdn" -o tsv
常見原因與解決方案
| 原因 | 錯誤訊號 | 解決方案 |
|---|---|---|
| Ingress 未啟用 | 沒有分配 FQDN，無法聯絡應用程式 | 啟用輸入：az containerapp ingress enable -g <RESOURCE_GROUP_NAME> -n <CONTAINER_APP_NAME> --type external --target-port 8080 --transport auto。 |
| 目標端口不匹配 | 502 壞門 | 設定 targetPort 成與你的應用程式監聽的埠口相匹配。 |
| 最新版本的流量權重為 0% | 舊修訂提供流量 | 更新流量分割：az containerapp ingress traffic set -g <RESOURCE_GROUP_NAME> -n <CONTAINER_APP_NAME> --revision-weight latest=100。 |
| IP 限制會阻擋用戶端 | 403 | 在 Ingress 設定中檢查 IP 安全限制。 |
| 錯誤的傳輸方式（HTTP 與 TCP） | 連線錯誤 | 確認入口類型是否符合你的應用程式的規範。 |
容器登錄驗證
當 app 無法驗證你的容器登錄檔，導致映像拉取失敗時，請使用這段。
癥狀
- 部署失敗並顯示
UNAUTHORIZED: authentication required。 - 這個錯誤常常掩蓋其他問題（例如圖片標籤不好），因為登錄檔在檢查標籤前就拒絕了請求。
該從哪裡查詢：登錄檔認證診斷
在 Azure 入口網站，前往容器應用程式>設定>容器（檢查登錄檔設定）。 接著到 容器應用程式>診斷，解決問題 並搜尋「登錄檔」。
# Check configured registries
az containerapp show -g <RESOURCE_GROUP_NAME> -n <CONTAINER_APP_NAME> \
--query "properties.configuration.registries" -o json
# Verify ACR credentials work
az acr login --name <AZURE_CONTAINER_REGISTRY_NAME>
docker pull <AZURE_CONTAINER_REGISTRY_NAME>.azurecr.io/<REPOSITORY_NAME>:<TAG>
常見原因與解決方案
| 原因 | 錯誤訊號 | 解決方案 |
|---|---|---|
| 沒有設定登錄檔憑證 | UNAUTHORIZED |
新增登錄憑證： az containerapp registry set -g <RESOURCE_GROUP_NAME> -n <CONTAINER_APP_NAME> --server <AZURE_CONTAINER_REGISTRY_NAME>.azurecr.io --identity system。 |
| ACR 上的管理員憑證被停用 |
UNAUTHORIZED 搭配系統管理員使用者 |
啟用管理員使用者： az acr update -n <AZURE_CONTAINER_REGISTRY_NAME> --admin-enabled true。
慣用：改用受控識別進行 ACR 提取。 |
| 受控識別缺少 AcrPull 角色 | UNAUTHORIZED |
指派 AcrPull 角色：az role assignment create --role AcrPull --assignee <PRINCIPAL_ID> --scope <ACR_RESOURCE_ID>。 |
| 伺服器主機名稱錯誤 | name unknown |
確認登錄伺服器是否符合你的 ACR： <your-acr>.azurecr.io。 |
診斷工作流程摘要
當你不確定什麼失敗時，請使用這段序列：
執行
az containerapp show -g <RESOURCE_GROUP_NAME> -n <CONTAINER_APP_NAME> -o json。 檢查provisioningState、provisioningError和latestRevisionName。執行
az containerapp revision list -g <RESOURCE_GROUP_NAME> -n <CONTAINER_APP_NAME> -o table。 如果清單是空的，則是影像拉取或範本驗證（影像拉取失敗與容器登錄驗證）出了問題。 如果有修訂，繼續第三步。執行
az containerapp revision show -g <RESOURCE_GROUP_NAME> -n <CONTAINER_APP_NAME> --revision <REV> -o json。 檢查healthState、runningState、runningStateDetails、provisioningError。執行
az containerapp logs show -g <RESOURCE_GROUP_NAME> -n <CONTAINER_APP_NAME> --type system --tail 50以查看平台層級事件，如探測失敗、身份錯誤及秘密同步問題。執行
az containerapp logs show -g <RESOURCE_GROUP_NAME> -n <CONTAINER_APP_NAME> --tail 100，以檢視應用程式 stdout/stderr，包括堆疊追蹤、組態錯誤和連線失敗。如果前幾步出現與認證相關的錯誤，請執行
az containerapp identity show -g <RESOURCE_GROUP_NAME> -n <CONTAINER_APP_NAME>以驗證身份設定。
在入口網站中使用「診斷並解決問題」
Container Apps 入口網站包含具有自動化診斷的診斷並解決問題窗格：
- 在 Azure 入口網站中，移至您的容器應用程式。
- 從左側導覽選擇 「診斷與解決問題 」。
- 使用搜尋方塊尋找特定診斷 (例如「映像提取」、「健全狀態探查」或「輸入」)。
- 選擇一個故障排除分類圖塊進行引導分析。
此窗格是引導式診斷的建議起點。 它可能無法涵蓋本文中所有情境，但能自動檢查常見問題。
Log Analytics 查詢以進行更深入的調查
如果 CLI 輸出和入口網站診斷資訊不足以滿足需求，請直接在 Log Analytics 中查詢底層記錄。 以下兩個查詢涵蓋平台層級失敗與入口層級 HTTP 錯誤最常見的起點。
找出系統層級的故障
ContainerAppSystemLogs_CL
| where RevisionName_s == "<REV>"
| where Log_s contains "BackOff" or Log_s contains "Failed" or Log_s contains "Error"
or Reason_s == "Unhealthy"
| project TimeGenerated, Reason_s, Log_s
| order by TimeGenerated desc
| take 50
此查詢顯示影像拉取錯誤、探針失敗、配置錯誤及其他平台事件。
查找 HTTP 錯誤（需啟用 HTTP 日誌）
輸入層會發出 HTTP 記錄，而您會選擇加入這些記錄。 透過 Azure 監視器 在容器應用程式管理環境中的診斷設定啟用這些日誌。 啟用後，表格ContainerAppHTTPLogs會出現在 Log Analytics 中。 表格可能需要幾分鐘才會出現。
ContainerAppHTTPLogs
| where TimeGenerated > ago(1h)
| where StatusCode >= 400
| project TimeGenerated, ContainerAppName, RevisionName, Method, Path,
StatusCode, ResponseCodeDetails, RequestDuration, RequestId
| order by TimeGenerated desc
| take 100
此查詢會過濾入口層 HTTP 日誌，只顯示過去一小時內失敗的請求（狀態碼 400 或以上）。 它會回傳時間戳、應用程式名稱與版本名稱、HTTP 方法與路徑、錯誤狀態碼、 ResponseCodeDetails 一個欄位（表示錯誤是來自你的容器 （via_upstream） 還是平台 （route_not_found， ）、 connection_timeout請求時長，以及一個可用來與應用程式日誌對應的獨特請求 ID。
如需更多查詢，包括緩慢的請求分析、依版本的錯誤率、單一請求追蹤及頂尖失敗端點，請參閱使用 Log Analytics 監控 Azure 容器應用程式 中的日誌。