本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。 # 應用程式狀態檢查 應用程式狀態檢查可協助您監控在 Amazon EC2 上執行之應用程式的效能和運作狀態。透過應用程式狀態檢查，您可以透過可設定的路徑和連接埠監控應用程式，以偵測和回應應用程式運作狀態受損。例如，您可以使用應用程式狀態檢查來確認您的 Web 伺服器正在接聽其預期的連接埠，並接受新的連線。 應用程式狀態檢查會在可設定的路徑和連接埠監控應用程式的 HTTP 和 HTTPS 回應。它們每 60 秒執行一次並與 Amazon EC2 Auto Scaling 整合，因此您可以自動替換應用程式受損的執行個體。 **Topics** + [應用程式狀態檢查的運作方式](#how-application-status-checks-work) + [開始使用應用程式狀態檢查](#get-started-application-status-checks) + [組態選項](#asc-configuration-options) + [預設設定](#asc-default-settings) + [Amazon EC2 Auto Scaling 整合](#asc-auto-scaling-integration) + [處理部署、就地修補和替換](#asc-handling-deployment-and-patching) + [測試新的應用程式狀態檢查](#asc-testing-a-new-check) + [進階聯網](#asc-advanced-networking) + [疑難排解](#asc-troubleshooting) + [監控應用程式狀態檢查](#asc-monitoring) + [安全與許可](#asc-security-and-permissions) + [定價](#asc-pricing) + [配額](#asc-quotas) ## 應用程式狀態檢查的運作方式 應用程式狀態檢查會每 60 秒將 HTTP 或 HTTPS 請求傳送至在執行個體上網路連接埠接聽的端點。 會將回應碼與您設定的狀態碼比對器 AWS 進行比較。檢查在連續多次失敗的請求後會標記為受損，而在連續多次成功的請求後會再次正常運作。兩個計數都預設為 2 且可設定。如需詳細資訊，請參閱[評估閾值](#asc-config-evaluation)。 **注意** 應用程式狀態檢查會透過 HTTP/2 傳送運作狀態檢查請求。 HTTPS 通訊協定檢查不會驗證伺服器憑證。 在重新啟動期間，應用程式狀態檢查會報告失敗，直到執行個體再次可用為止，因為應用程式在作業系統重新啟動時無法回應運作狀態檢查請求。 ### 網路架構 應用程式狀態檢查源自 Amazon EC2 應用程式狀態檢查服務。若要到達您的執行個體， 會在您的 VPC 中 AWS 建立受管彈性網路界面 (ENI)。 會為每個具有相關聯執行個體的來源子網路和安全群組組合 AWS 建立一個 ENI。當應用程式狀態檢查首次需要該組合時， 會 AWS 建立受管 ENI，並在不需要剩餘的應用程式狀態檢查時將其移除。受管 ENI 不會計入您的執行個體 ENI 限制，但會計入每個 VPC 的 ENIs全域限制。 應用程式狀態檢查會從 VPC 中的私有優勢點到達您的執行個體。範圍說明檢查的來源，而不是執行個體 IP 地址的屬性。 會在 VPC 內的子網路中 AWS 建立受管 ENI，並透過私有網路路徑到達執行個體。 運作狀態檢查流量來自與目標執行個體 （或本機區域目標的父可用區域） 位於相同可用區域中的 AWS受管 Amazon EC2 執行個體、透過 AWS 內部網路傳輸，且不周遊公有網際網路。如需詳細資訊，請參閱 [Amazon Web Services 網站上的 Amazon VPC FAQs](https://aws.amazon.com/vpc/faqs/)。 ### AWS 受管和客戶受管網路路徑 應用程式狀態檢查支援兩種加入模式，可判斷誰會選取運作狀態檢查 ENI 的來源子網路和安全群組，以及目標執行個體的目的地子網路和安全群組。 AWS 受管網路路徑 AWS 會選取運作狀態檢查 ENI 的來源子網路和安全群組，以及目標執行個體的目的地子網路和安全群組。 客戶管理的網路路徑 您可以指定運作狀態檢查 ENI 的來源子網路和安全群組，以及目標執行個體的目的地子網路和安全群組。 當您需要控制哪些子網路和安全群組運作狀態檢查流量源自時，例如當您的 VPC 具有嚴格的網路分割、防火牆規則或合規要求，以限制哪些來源可以到達您的應用程式端點時，請使用客戶受管網路路徑。 您可以在建立命令中包含或省略 `--health-check-paths` 參數，以選擇 模式。如果您省略 `--health-check-paths` 參數， 會 AWS 選取來源和目的地子網路和安全群組 (AWS 受管網路路徑）。如果您包含 `--health-check-paths` 參數，您可以管理它們 （客戶管理的網路路徑）。 ### IP 版本 每個應用程式狀態檢查都與單一 IP 版本 (IPv4 或 IPv6) 相關聯。若要透過 IPv4 和 IPv6 監控執行個體，請建立兩個單獨的應用程式狀態檢查，並將兩者與執行個體建立關聯。 針對 IPv4 和 IPv6，檢查從 VPC 內到達您的執行個體。 ### 檢查狀態值 每個個別檢查都會報告下列其中一個狀態： + `passed`：檢查已成功完成 + `failed`：檢查失敗。回應包含應用程式傳回的 HTTP 狀態碼。如需解釋和修復指引，請參閱 [疑難排解](#asc-troubleshooting)。 + `initializing`：檢查尚未完成其第一次評估 + `insufficient-data`：檢查未收到足夠的資料來判斷結果 + `not-applicable`：檢查未與執行個體建立關聯 執行個體報告的整體應用程式狀態會彙總所有個別檢查結果。整體狀態為下列其中一項： + `ok`：通過的所有檢查 + `impaired`：一或多個檢查失敗 + `initializing`：一或多個檢查尚未完成其第一次評估 + `insufficient-data`：一或多個檢查報告資料不足 + `not-applicable`：所有相關聯的應用程式狀態檢查都會從彙總中排除 + `suppressed`：執行個體的應用程式狀態檢查評估遭到隱藏 ### 聚合 您可以將每個應用程式狀態檢查標記為包含在執行個體的整體狀態中或從中排除。根據預設，檢查為 `included`。 `included` 檢查有助於執行個體的整體狀態，而 Amazon EC2 Auto Scaling 會使用它。 `excluded` 檢查會報告其個別狀態，但不影響執行個體的整體狀態，且 Amazon EC2 Auto Scaling 不會使用它。使用此設定在生產環境中驗證新的檢查，而不會影響整體狀態或觸發 Amazon EC2 Auto Scaling 替換。這是將檢查新增至現有生產工作負載時的建議工作流程；請參閱 [測試新的應用程式狀態檢查](#asc-testing-a-new-check)。 ## 開始使用應用程式狀態檢查 **先決條件** 建立應用程式狀態檢查之前，請確定您有下列項目： + 包含您要監控之執行個體的 VPC。 + 每個執行個體上的應用程式端點，可在您將設定的連接埠和 HTTP 路徑上回應 HTTP 或 HTTPS 請求。 + 每個目的地執行個體上的安全群組，允許檢查連接埠上來自應用程式狀態檢查所用來源安全群組的傳入流量。請參閱 [安全與許可](#asc-security-and-permissions)。 **步驟 1：設定您的 應用程式** 設定應用程式端點以回應連接埠上的 HTTP 或 HTTPS 請求，以及您在建立檢查時指定的 HTTP 路徑。傳回狀態碼比對器中包含的回應碼，以指出應用程式運作狀態良好。 確定目的地執行個體的安全群組允許來自應用程式狀態檢查所用來源安全群組之檢查連接埠的傳入流量。對於受管網路路徑， 會在建立檢查時 AWS 提供來源安全群組。對於客戶管理的網路路徑，您可以在建立檢查時指定來源安全群組。 **步驟 2：建立檢查定義** 使用 AWS CLI 建立應用程式狀態檢查。 ------ #### [ AWS CLI ] 若要使用 AWS 受管網路路徑，請省略 `--health-check-paths` 參數，並讓 AWS 選取來源和目的地子網路和安全群組。 ``` aws ec2 create-application-status-check \ --protocol https \ --port 443 \ --path "/health" \ --status-code-matcher "200" ``` 若要使用客戶管理的網路路徑，請包含 `--health-check-paths` 參數。每個運作狀態檢查路徑都包含來源 （運作狀態檢查 ENI 的子網路和安全群組） 和一或多個目的地 （目標執行個體的子網路和安全群組）。 ``` aws ec2 create-application-status-check \ --protocol https \ --port 443 \ --path "/health" \ --status-code-matcher "200" \ --health-check-paths '[{"Source":{"SubnetId":"subnet-111","SecurityGroupId":"sg-aaa"},"Destinations":[{"SubnetId":"subnet-222","SecurityGroupId":"sg-bbb"}]}]' ``` ------ **步驟 3：將檢查與執行個體建立關聯** 將檢查與您要監控的執行個體建立關聯，無論是依執行個體 ID 或依標籤。 ------ #### [ AWS CLI ] 依執行個體 ID： ``` aws ec2 associate-application-status-check \ --application-status-check-id asc-1234567890abcdef0 \ --instance-ids i-0123456789abcdef0 ``` 依標籤： ``` aws ec2 associate-application-status-check \ --application-status-check-id asc-1234567890abcdef0 \ --target-tag-associations Key=Environment,Value=production ``` 若要與 Auto Scaling 群組中的所有執行個體建立關聯，請使用`aws:autoscaling:groupName`系統標籤： ``` aws ec2 associate-application-status-check \ --application-status-check-id asc-1234567890abcdef0 \ --target-tag-associations Key=aws:autoscaling:groupName,Value={{my-asg}} ``` ------ 關聯和取消關聯操作會傳回每個執行個體的成功和失敗結果。如果某些執行個體無法建立關聯 （例如，因為檢查已建立關聯），這些執行個體會出現在失敗的結果中，並說明原因。 **步驟 4：檢視結果** 檢視每個執行個體應用程式的運作狀態。 ------ #### [ AWS CLI ] ``` aws ec2 describe-application-status \ --instance-ids i-0123456789abcdef0 ``` 回應包含整體應用程式狀態，以及針對每個相關聯的檢查、檢查狀態，以及針對失敗的檢查，包含應用程式傳回的 HTTP 狀態碼。 回應範例： ``` { "ApplicationStatuses": [ { "InstanceId": "i-0123456789abcdef0", "ApplicationStatus": { "Status": "ok", "Details": [ { "ApplicationStatusCheckId": "asc-1234567890abcdef0", "Status": "passed", "Reason": { "Code": "ResponseCodeMatched", "StatusCode": 200, "Protocol": "HTTP" } } ] } } ] } ``` 若要檢視檢查定義 （非每個執行個體狀態），請使用 [describe-application-status-checks](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-application-status-checks.html)。此命令會傳回應用程式狀態檢查的組態，包括通訊協定、連接埠、HTTP 路徑和狀態碼比對器設定。 ------ ## 組態選項 應用程式狀態檢查接受數個組態參數。本節說明 行為無法從參數名稱自我顯現的參數。如需參數和驗證規則的完整清單，請參閱《*Amazon EC2 API 參考*》中的 [CreateApplicationStatusCheck](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_CreateApplicationStatusCheck.html) 和 [AssociateApplicationStatusCheck](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_AssociateApplicationStatusCheck.html)。 ### 評估閾值 `FailureThreshold` 檢查標記為受損之前連續失敗的請求數量。預設：2。 `SuccessThreshold` 檢查再次標記為正常之前連續成功的請求數量。預設：2。 `Timeout` 在請求記錄為失敗之前等待回應的秒數。強制執行為強制逾時；如果您的應用程式未在此視窗中回應，無論最終回應為何，請求都會記錄為失敗。預設：6. 有效範圍：1-30。 ### 啟動寬限期 `InitializationGracePeriodSeconds` 執行個體啟動後， AWS 開始評估檢查前要等待的秒數。使用此參數讓應用程式有時間在檢查開始之前開始接聽。如果寬限期太短，Amazon EC2 Auto Scaling 可能會在應用程式就緒之前取代新的執行個體。預設：300。有效範圍：1 到 600。 ### IP 範圍 `IpScope` 應用程式狀態檢查使用`private`範圍；檢查從您的 VPC 內執行。對於 IPv4，這對應到執行個體的私有 IP 地址。對於 IPv6， AWS 不會將地址分類為公有或私有；檢查會接受任何 IPv6 地址，並從 VPC 中評估該地址。 ### 裝置索引 `DeviceIndex` 執行個體上 AWS 評估運作狀態檢查的網路裝置的索引。當您執行個體的主要網路裝置不是您想要檢查的裝置時，請變更此選項。預設：0. 彙總、IP 版本和運作狀態檢查路徑 （來源和目的地子網路和安全群組） 涵蓋在此頁面稍早的部分。 ## 預設設定 透過 AWS 受管網路路徑，應用程式狀態檢查會使用下列預設值。 | 設定 | 預設 | | --- | --- | | 檢查間隔 | 60 秒 （固定；無法設定） | | Failure threshold | 連續 2 次失敗 | | 成功閾值 | 連續 2 次成功 | | Timeout (逾時) | 6 秒 | | 狀態碼比對器 | 200 | | HTTP 路徑 | / | | IP 版本 | ipv4 | | IP 範圍 | private | | 裝置索引 | 0 | | 初始化寬限期 | 300 秒 | | 聚合 | 包含 | | 來源子網路和安全群組 | 管理者 AWS | ## Amazon EC2 Auto Scaling 整合 只要檢查包含在彙總中`impaired`，Amazon EC2 Auto Scaling 會自動終止和取代其整體應用程式狀態報告為 的執行個體。除了將應用程式狀態檢查與群組中的執行個體建立關聯之外，不需要 Auto Scaling 群組組態。 Amazon EC2 Auto Scaling 會使用執行個體的整體狀態，而非個別檢查狀態。標記的檢查`excluded`不會驅動 Amazon EC2 Auto Scaling 動作。`suppressed` 狀態中的檢查不會驅動 Amazon EC2 Auto Scaling 動作。 在檢查上使用 `InitializationGracePeriodSeconds` 參數，在應用程式狀態檢查開始之前，允許新的執行個體有時間啟動。如果寬限期太短，Amazon EC2 Auto Scaling 可能會終止新的執行個體，並在其應用程式準備好提供流量之前予以取代。 如需 Amazon EC2 Auto Scaling 如何使用運作狀態檢查的詳細資訊，請參閱《Amazon EC2 Auto Scaling 使用者指南》中的 [ Auto Scaling 群組中的執行個體運作狀態檢查](https://docs.aws.amazon.com/autoscaling/ec2/userguide/ec2-auto-scaling-health-checks.html)和[搭配 Auto Scaling 群組使用應用程式狀態檢查](https://docs.aws.amazon.com/autoscaling/ec2/userguide/use-application-status-checks-auto-scaling-group.html)。 *Amazon EC2 Auto Scaling * ## 處理部署、就地修補和替換 部署、就地修補和其他維護操作可能會暫時停止或重新啟動您的應用程式。在此期間，應用程式狀態檢查會報告失敗，因為應用程式無法回應運作狀態檢查請求。如果您的執行個體位於具有包含在彙總中應用程式狀態檢查的 Auto Scaling 群組中，即使預期中斷，Amazon EC2 Auto Scaling 仍可能會終止並取代這些執行個體。 ### 選項 A：隱藏檢查 對您知道持續時間的週框維護時段使用抑制。抑制會在執行個體層級強制執行。您可以指定持續時間，或將其省略以隱藏檢查，直到您停用禁止為止。 ------ #### [ AWS CLI ] ``` aws ec2 enable-application-status-check-suppression \ --instance-ids i-0123456789abcdef0 \ --duration-seconds 3600 ``` 回應會傳回每個執行個體的抑制開始和結束時間。部分成功是可能的；有些執行個體可能無法抑制，並出現於回應中並說明原因。 若要在禁止時段到期之前繼續檢查： ``` aws ec2 disable-application-status-check-suppression \ --instance-ids i-0123456789abcdef0 ``` ------ 抑制時，執行個體的整體應用程式狀態會報告 `suppressed`。Amazon EC2 Auto Scaling 不會對`suppressed`執行個體採取行動。 ### 選項 B：從彙總中排除檢查 如果您希望檢查繼續評估和報告其個別狀態，但不會影響整體狀態或觸發 Amazon EC2 Auto Scaling 動作，請將檢查的彙總設定設為 `excluded`。這適用於更長期的情況，例如推出新的檢查版本或驗證變更而不危及取代，以及您希望遙測繼續而不會對操作造成影響的情況。 如需詳細資訊，請參閱[聚合](#asc-aggregation)。 ### 選項 C：取消與檢查的關聯 將取消關聯用於更長期或無限期的移除。 ``` aws ec2 disassociate-application-status-check \ --application-status-check-id asc-1234567890abcdef0 \ --instance-ids i-0123456789abcdef0 ``` 如果您依標籤建立關聯，請從執行個體中移除標籤以取消關聯。取消關聯後，執行個體的整體應用程式狀態會報告 `not-applicable`。 ### 部署指引 部署是最常見的需要抑制的維護案例。當您的部署工具具有部署前掛鉤和部署後掛鉤時，請使用抑制，以便在部署開始之前隱藏檢查，並在部署完成後停用抑制。 一般模式為： 1. 在預先部署掛鉤中，呼叫執行個體的 [enable-application-status-check-suppression](https://docs.aws.amazon.com/cli/latest/reference/ec2/enable-application-status-check-suppression.html)，持續時間涵蓋預期的部署時段。 1. 執行部署。 1. 在部署後掛鉤中，呼叫執行個體的 [disable-application-status-check-suppression](https://docs.aws.amazon.com/cli/latest/reference/ec2/disable-application-status-check-suppression.html)。 如果您的部署工具沒有掛鉤，請從叫用部署的 CI/CD 管道進行磁碟機抑制。 ## 測試新的應用程式狀態檢查 您可以在生產環境中驗證新的應用程式狀態檢查，然後再開始造成執行個體層級監控。當您建立檢查`excluded`時，將彙總設定設為 ，然後確認它報告預期的狀態和 HTTP 回應代碼。當您準備好時，請將設定變更為 ，`included`讓檢查有助於執行個體的整體狀態，並與 Amazon EC2 Auto Scaling 整合。 1. 建立將彙總設定設為 的檢查`excluded`。 ``` aws ec2 create-application-status-check \ --protocol https \ --port 443 \ --path "/health" \ --status-code-matcher "200" \ --aggregation excluded ``` 1. 將檢查與測試執行個體或生產機群的子集建立關聯。 1. 等待至少兩個檢查間隔 （約兩分鐘），以允許檢查完成初始評估。 1. 使用 [describe-application-status](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-application-status.html) 來驗證檢查是否報告預期狀態和 HTTP 回應碼。 ``` aws ec2 describe-application-status \ --instance-ids i-0123456789abcdef0 ``` 1. 如果檢查如預期報告，請將彙總設定更新為 `included` ，讓檢查有助於執行個體的整體狀態，並驅動 Amazon EC2 Auto Scaling 動作。 ``` aws ec2 modify-application-status-check \ --application-status-check-id asc-1234567890abcdef0 \ --aggregation included ``` ## 進階聯網 應用程式狀態檢查來自您指定 （或為您 AWS 選取） 之來源子網路和安全群組中的受管 ENI。對於需要比單一來源組態更高可用性的工作負載，或在 Local Zones 或 Outposts 中執行的工作負載，請考慮下列模式。 ### 本機區域 對於在 AWS Local Zones 中執行的執行個體，受管彈性網路界面 (ENI) 位於父 AWS 區域，而非 Local Zone。父區域與本地區域執行個體之間的運作狀態檢查流量周遊本地區域服務連結，這可能會產生額外的資料傳輸費用。 ## 疑難排解 當應用程式狀態檢查報告受損，但您預期應用程式運作狀態良好時，請確認下列各項： 1. *執行個體連線能力。*確認執行個體的執行個體和系統狀態檢查為 `ok`。 1. *安全群組傳入規則。*目的地執行個體的安全群組必須允許來自應用程式狀態檢查所用來源安全群組之檢查連接埠的傳入流量。對於 AWS 受管網路路徑， AWS 會提供來源安全群組；對於客戶受管網路路徑，請使用您指定為來源的安全群組。 1. *主機防火牆。*執行個體上的任何主機層級防火牆 (iptable、Windows Firewall、第三方主機防火牆） 必須允許檢查連接埠上的傳入流量。 1. *應用程式端點。*應用程式必須接聽您設定的連接埠和路徑。使用來自執行個體的本機請求進行確認 (`curl http://localhost:PORT/PATH`)。 1. *通訊協定不相符。*如果檢查設定為 HTTPS，但端點僅提供 HTTP （反之亦然），則所有呼叫都會失敗。 1. *狀態碼比對程式。*確認應用程式的實際回應碼包含在您設定的狀態碼比對程式中。 1. *網路路徑。*如果您已設定客戶管理的網路路徑，請確認來源子網路和安全群組已連線至目的地子網路。使用 [VPC Reachability Analyzer](https://docs.aws.amazon.com/vpc/latest/reachability/what-is-reachability-analyzer.html) 追蹤網路路徑。 1. *可用的 ENI quota.在* AWS 您的帳戶中為每個來源子網路和安全群組組合建立受管彈性網路界面 (ENI)。確認您的帳戶在其 VPC 配額中具有可用的 ENI。如果您的帳戶已達到每個 VPC 配額ENIs，則 AWS 無法建立受管 ENI，且無法執行檢查。如需詳細資訊，請參閱 [Amazon VPC 配額](https://docs.aws.amazon.com/vpc/latest/userguide/amazon-vpc-limits.html)。 ### 原因代碼 [describe-application-status](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-application-status.html) 回應包含每次檢查的原因。原因包含應用程式傳回的 HTTP 狀態碼 （以數字表示），以及用於檢查的通訊協定。`passed` 如果傳回的狀態碼包含在您的狀態碼比對程式中，則會標記檢查，`failed`否則會標記檢查。 原因還包括原因碼，以及 HTTP 層級結果的通訊協定和傳回的 HTTP 狀態碼。原因包含下列欄位： `Code` 應用程式狀態檢查結果的原因碼。下列其中一值： + `ResponseCodeMatched`：運作狀態檢查傳回的 HTTP 狀態碼符合設定的 `StatusCodeMatcher`。 + `ResponseCodeMismatch`：運作狀態檢查傳回的 HTTP 狀態碼不符合設定的 `StatusCodeMatcher`。 + `ConnectionTimeout`：與目標的連線逾時。 + `ResponseTimeout`：等待目標的回應時，運作狀態檢查逾時。 + `ConnectionRefused`：目標拒絕運作狀態檢查連線。 + `ConnectionReset`：在收到回應之前，已重設運作狀態檢查連線。 對於 `ResponseCodeMatched`和 `ResponseCodeMismatch`， `StatusCode` 欄位包含傳回的 HTTP 狀態碼，而 `Protocol` 欄位包含用於運作狀態檢查的通訊協定。對於連線錯誤，例如 `ConnectionTimeout`、`ConnectionRefused`、 `ResponseTimeout`和 `ConnectionReset`， `StatusCode`和 `Protocol` 欄位不存在。 `Protocol` 用於運作狀態檢查的通訊協定。`HTTP` 或 之一`HTTPS`。 `StatusCode` 運作狀態檢查傳回的 HTTP 狀態碼。 使用傳回的 HTTP 狀態碼來識別檢查失敗的原因。一些常見範例： | HTTP 狀態碼 | 典型意義 | 常見補救措施 | | --- | --- | --- | | `200` | 應用程式傳回成功的回應。 | 無。這通常是正常狀態。 | | `301`, `302` | 應用程式傳回重新導向。運作狀態檢查呼叫不會遵循重新導向。 | 將運作狀態檢查路徑指向重新導向的目的地，或者如果您認為重新導向碼正常運作，請將重新導向碼新增至您的狀態碼比對程式。 | | `401`, `403` | 應用程式需要身分驗證或拒絕存取運作狀態檢查路徑。 | 將運作狀態檢查路徑設定為未經驗證，或在不需要登入資料的路徑上提供運作狀態檢查。 | | `404` | 在應用程式上找不到設定的運作狀態檢查路徑。 | 確認路徑與您的應用程式提供的路由相符。 | | `500` | 應用程式傳回內部伺服器錯誤。 | 調查執行個體上的應用程式日誌。 | | `502`, `503`, `504` | 應用程式可連線，但會回報上游或容量問題。 | 調查應用程式運作狀態、相依性和容量。如果您的應用程式在啟動期間傳回這些代碼，請增加 `InitializationGracePeriodSeconds`。 | 如需完整的`ApplicationStatusReason`結構，請參閱《*Amazon EC2 API 參考*》中的 [ApplicationStatusReason](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_ApplicationStatusReason.html)。 ### 常見錯誤 + 安全群組不允許來自檢查連接埠上運作狀態檢查來源的傳入流量。 + 應用程式繫結至 網路界面`127.0.0.1`，而不是接聽。 + 運作狀態檢查路徑會傳回重新導向 (301、302) 而非成功回應，且狀態碼比對程式不包含重新導向碼。 + 檢查是針對 HTTPS 設定，但應用程式只提供 HTTP，反之亦然。 + 應用程式啟動的時間比`InitializationGracePeriodSeconds`值更長，Amazon EC2 Auto Scaling 會先取代執行個體，再準備就緒。 ## 監控應用程式狀態檢查 您可以透過三種方式監控應用程式狀態檢查： + **Amazon CloudWatch**。`StatusCheckFailed_Application` 指標會反映執行個體的整體應用程式狀態，並可驅動警示。指標會在彙總設定為 的相關聯檢查中，依執行個體彙總`included`。CloudWatch 也會針對每個名為 的相關聯檢查，發佈每個檢查的指標`StatusCheckFailed_Application_{{application-status-check-id}}`。 + **[describe-instance-status](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-instance-status.html)**。傳回整體應用程式狀態，以及執行個體的其他狀態資訊。 + **[describe-application-status](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-application-status.html)**。傳回每個執行個體的詳細結果，包括每個相關聯的檢查的個別狀態，以及應用程式傳回的 HTTP 狀態碼。 使用 CloudWatch 指標進行警示驅動型自動化。當您已查詢執行個體狀態`describe-instance-status`時，請使用 。使用 `describe-application-status`以取得每個檢查的詳細可見性。 ## 安全與許可 AWS 透過服務連結角色建立和管理用於應用程式狀態檢查的網路介面。服務不需要 IAM 設定即可建立這些 ENIs。服務連結角色使用 [`EC2ApplicationStatusChecksServiceRolePolicy`](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/EC2ApplicationStatusChecksServiceRolePolicy.html) AWS 受管政策。 若要自行建立、關聯、描述、刪除和隱藏應用程式狀態檢查，您的 IAM 使用者或角色需要對應的 Amazon EC2 許可。如需動作的完整清單，請參閱 *Amazon EC2 API 參考*。 執行個體的安全群組必須允許來自您設定連接埠上運作狀態檢查來源安全群組的傳入流量。使用 AWS 受管網路路徑時， AWS 會提供來源安全群組；使用客戶受管網路路徑時，請使用您指定為來源的安全群組。 ## 定價 應用程式狀態檢查依下列元件計費： + 每個可用區域每個受管彈性網路界面 (ENI) 的每小時 0.01 USD。 + 標準 Amazon CloudWatch 定價適用於應用程式狀態檢查指標。 ## 配額 應用程式狀態檢查受 AWS 服務配額約束。如需配額名稱、預設值和說明，請參閱《 *AWS 一般參考*》中的 [Amazon EC2 端點和配額](https://docs.aws.amazon.com/general/latest/gr/ec2-service.html)。 除了影響受管網路介面 AWS 的服務配額之外，應用程式狀態檢查還具有下列服務配額。您可以從 Service Quotas 主控台檢視您的用量和請求增加。 在這些配額中，*目標*是一個運作狀態檢查監控的單一執行個體。如果多個運作狀態檢查監控執行個體，則每個執行個體和運作狀態檢查配對都會計為個別目標。*關聯*是您與運作狀態檢查建立關聯的單一標籤規則或單一執行個體 ID。每個規則或執行個體 ID 都會計為一個關聯，無論其解析的執行個體數量為何。 | 配額 | 預設 | 可調整 | | --- | --- | --- | | 每個帳戶的運作狀態檢查 | 50 | 是，自動 | | 每個運作狀態檢查的關聯 | 50 | 是，自動 | | 每個帳戶的關聯數 | 200 | 是，自動 | | 每個帳戶的目標數 | 5,000 | 是，依請求 | 大多數配額增加會自動核准。增加*每個帳戶的目標*需要請求和手動核准。 **重要** 如果帳戶中的目標數量超過*每個帳戶*的目標配額，則不會監控超過限制的目標，也不會報告應用程式狀態。為了避免監控的差距，請將目標計數保持在配額內或請求增加。 我們建議您在應用程式狀態檢查配額用量上建立 Amazon CloudWatch 警示，以便在達到配額之前收到通知。Service Quotas 會將用量指標發佈到 CloudWatch 中的`AWS/Usage`命名空間，您可以使用它來建立警示。