本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。 # 使用 Application Signals 監控應用程式的運作狀態 在 [CloudWatch 主控台](https://console.aws.amazon.com/cloudwatch/)中使用 Application Signals 來監控和疑難排解應用程式的運作狀態： + **監控應用程式服務** – 作為日常營運監控的一部分，請使用[服務](Services-page.md)頁面查看所有服務的摘要。查看故障率或延遲最高的服務，並查看哪些服務的[服務水準指標 (SLI)](CloudWatch-ServiceLevelObjectives.md) 不良。選取服務以開啟[服務詳細資訊](ServiceDetail.md)頁面，並查看詳細指標、服務操作、Synthetics Canaries 和用戶端請求。這可協助您疑難排解並確定操作問題的根本原因。 + **檢查應用程式拓撲**：使用[應用程式地圖](ServiceMap.md)來了解和監控一段時間內的應用程式拓撲，包括用戶端、Synthetics Canary、服務和相依項之間的關係。立即查看服務水準指標 (SLI) 狀況，並檢視呼叫量、故障率和延遲等關鍵指標。深入查看[服務詳細資訊](ServiceDetail.md)頁面中的更多詳細資訊。 探索[範例案例](Services-example-scenario.md)，示範如何使用這些頁面快速疑難排解操作服務運作狀態問題，從初始偵測到識別根本原因。 **Application Signals 如何啟用操作運作狀態監控** 為 Application Signals [啟用應用程式](CloudWatch-Application-Signals-Enable.md)之後，您的應用程式服務、API 及其相依項會被自動偵測到，並顯示在**服務**、**服務詳細資訊**和**應用程式地圖**頁面中。Application Signals 會從多個來源收集資訊，以啟用服務探索和操作運作狀態監控： + [AWS Distro for OpenTelemetry (ADOT)](CloudWatch-Application-Signals-supportmatrix.md) — 作為啟用 Application Signals 的一部分，OpenTelemetry Java 和 Python 自動檢測程式庫設定為發出 CloudWatch 代理程式收集的指標和追蹤。指標和追蹤可用來探索服務、操作、相依性和其他服務資訊。 + [服務水準目標 (SLO)](CloudWatch-ServiceLevelObjectives.md)：在您為服務建立服務水準目標後，「服務」、「服務詳細資訊」和「應用程式地圖」頁面會顯示服務水準指標 (SLI) 運作狀態。SLI 可監控延遲、可用性和其他操作指標。 + [CloudWatch Synthetics Canaries](CloudWatch_Synthetics_Canaries.md) – 當您在 Canaries 上設定 X-Ray 追蹤時，從 canary 指令碼對服務的呼叫會與您的服務相關聯，並顯示在「服務詳細資訊」頁面中。 + [CloudWatch 真實使用者監控 (RUM)](CloudWatch-RUM.md) – 在 CloudWatch RUM Web 用戶端上啟用 X-Ray 追蹤時，對服務的請求會自動關聯並顯示在服務詳細資訊頁面中。 + [AWS Service Catalog AppRegistry](https://docs.aws.amazon.com/servicecatalog/latest/arguide/intro-app-registry.html) – Application Signals 會自動探索您帳戶中 AWS 的資源，並允許您將其分組到 AppRegistry 中建立的邏輯應用程式。「服務」頁面中顯示的應用程式名稱是基於執行服務的基礎運算資源。 **注意** Application Signals 會根據您選擇的目前時間篩選器中發出的指標和追蹤來顯示您的服務和操作。(根據預設，這是過去三個小時。) 如果服務、操作、相依性、Synthetics Canary 或用戶端頁面的目前時間篩選條件內沒有任何活動，則不會顯示。 最多可以顯示 1,000 條服務。探索服務和服務拓撲最多可能會延遲 10 分鐘。評估服務水準指標 (SLI) 運作狀態可能會延遲 15 分鐘。 **注意** Application Signals 主控台目前僅支援在 30 天的時間範圍內最多選擇一天。 # 使用「服務」頁面檢視整體服務活動和操作運作狀態 可以使用「服務」頁面來查看[已針對 Application Signals 啟用](CloudWatch-Application-Signals-Enable.md)的服務清單。也可以檢視操作指標，並快速查看哪些服務具有狀態不佳的服務水準指標 (SLI)。在確定操作問題的根本原因時，深入查找效能異常。若要檢視此頁面，請開啟 [CloudWatch 主控台](https://console.aws.amazon.com/cloudwatch/)，然後在左側導覽窗格的 **Application Signals** 區段下選擇**服務**。 對於未檢測的服務，服務概觀頁面會顯示具有顯著calls-to-action的有限資訊，以啟用 Application Signals 檢測。 ## 探索服務的操作狀態指標 「服務」頁面頂端包含整體服務操作狀態圖表和數個資料表，其中顯示故障率最高之服務和服務相依項，以及服務清單。左側的「服務」圖表顯示目前頁面層級時間篩選條件中，具有狀態良好或不良服務水準指標 (SLI) 的服務數目明細。SLI 可監控延遲、可用性和其他操作指標。請檢視圖表旁兩個資料表中，依故障率排序的主要服務。在任一資料表中選取服務名稱，開啟其[服務詳細資訊](ServiceDetail.md)頁面，其中會顯示詳細的服務操作資訊。選取相依項路徑，檢視其詳細資訊頁面上的服務相依項詳細資訊。 這兩個表格都會顯示過去最多 3 小時的資訊，即使在頁面右上方選擇了較長的週期篩選條件亦如此。 使用動態服務分組機制時，操作狀態指標會自動彙總每個群組中所有服務的資料。這可提供： + 服務群組的合併故障率 + 群組層級的 SLI 運作狀態 + 彙總的效能指標，可協助識別有問題的服務叢集 + 在事件發生時，快速識別需要即刻關注哪些群組 ![\[CloudWatch 服務熱門圖表\]](http://docs.aws.amazon.com/zh_tw/AmazonCloudWatch/latest/monitoring/images/services-top-graphs.png) ## 使用「服務」資料表監控操作運作狀態 「服務」資料表會顯示已針對 Application Signals 啟用的服務清單。選擇**啟用 Application Signals** 以開啟設定頁面並開始設定服務。如需詳細資訊，請參閱[啟用 Application Signals](CloudWatch-Application-Signals-Enable.md)。 篩選「服務」資料表，可讓您更容易找到要尋找的內容，方法是從篩選文字方塊中選擇一個或多個屬性。當您選擇每個屬性時，系統會引導您完成篩選條件。您將在篩選文字方塊下方看到完整的篩選條件。可隨時選擇**清除篩選條件**以移除資料表篩選條件。 進階篩選選項可用於： + 依服務群組篩選 (預設和自訂群組) + 依最近的部署活動篩選 + 依平台篩選 + 依 SLI 運作狀態篩選 + 依帳戶 ID 篩選 （在跨帳戶可觀測性設定中） + 依檢測狀態篩選 （檢測與未檢測） + 依環境篩選 + 依服務運作狀態篩選 ![\[CloudWatch 服務資料表\]](http://docs.aws.amazon.com/zh_tw/AmazonCloudWatch/latest/monitoring/images/services-table-healthy-updated.png) 對於未檢測的服務，服務概觀頁面會顯示具有顯著calls-to-action的有限資訊，以啟用 Application Signals 檢測。未檢測的服務即使尚未使用 Application Signals 設定，也會出現在服務資料表中，協助您識別可觀測性涵蓋範圍中的差距，並根據哪些服務在架構中的位置排定後續檢測的優先順序。 選擇資料表中任何服務的名稱，即可檢視包含服務水準指標、操作及其他詳細資訊的[服務詳細資訊頁面](ServiceDetail.md)。如果您已將服務的基礎運算資源與 AppRegistry 中的應用程式或 AWS 管理主控台 首頁上的應用程式卡建立關聯，請選擇應用程式名稱以在 [myApplications](https://docs.aws.amazon.com/awsconsolehelpdocs/latest/gsg/aws-myApplications.html) 主控台頁面中顯示應用程式詳細資訊。對於 Amazon EKS 中託管的服務，請選擇**託管位置**欄中的任何連結，以檢視 CloudWatch Container Insights 中的叢集、命名空間或工作負載。對於在 Amazon ECS 或 Amazon EC2 中執行的服務，會顯示「環境」值。 資料表中會顯示每個服務的[服務水準指標 (SLI)](CloudWatch-ServiceLevelObjectives.md#CloudWatch-ServiceLevelObjectives-concepts) 狀態。選擇服務的 SLI 狀態以顯示快顯視窗，其中包含任何狀態不良 SLI 的連結，以及可查看所有操作之 SLO 的連結。 ![\[SLI 狀態不佳的服務\]](http://docs.aws.amazon.com/zh_tw/AmazonCloudWatch/latest/monitoring/images/services-unhealthy-sli.png) 如果尚未為服務建立 SLO，請在 **SLI 狀態**欄中選擇**建立 SLO** 按鈕。若要為任何服務建立額外的 SLO，請選取服務名稱旁的選項按鈕，然後在資料表右上角選擇**建立 SLO**。建立 SLO 時，可以一目了然地看到哪些服務和操作執行良好，哪些運作狀況不佳。如需詳細資訊，請參閱[服務水準目標 (SLO)](CloudWatch-ServiceLevelObjectives.md)。 ## 服務概觀 從服務資料表選取服務之後，服務概觀頁面隨即開啟。此頁面提供服務運作狀態和效能指標的完整檢視。概觀會顯示這些摘要指標： + 操作總計 + 服務相依性 + Canary 監控狀態 + RUM 用戶端資料 這些指標可讓您立即深入了解服務的目前狀態。 您可以使用一系列圖表，將一段時間內的關鍵操作效能指標視覺化。若要分析趨勢並識別影響服務運作狀態的潛在問題，請調整時間篩選條件。所有圖表都會自動更新，以反映所選時段的資料。 稽核問題清單區段會自動偵測並顯示服務行為中的重大問題，因此您不需要手動調查。Application Signals 會分析您的應用程式，以報告重大觀察和潛在問題，簡化根本原因分析。這些自動化問題清單會合併相關追蹤，無需多次點選即可瀏覽。稽核系統可協助團隊快速識別問題及其根本原因，從而更快解決問題。 您可以使用變更事件區段來識別最近的部署或組態變更如何影響您的服務行為。Application Signals 會自動處理 CloudTrail 事件，以追蹤整個應用程式的變更事件。監控 服務的組態和部署事件及其相依性，提供操作分析和故障診斷的立即內容。Application Signals 會自動將部署時間與效能變更建立關聯，協助快速判斷近期的部署是否導致了服務問題。 ![\[服務概觀\]](http://docs.aws.amazon.com/zh_tw/AmazonCloudWatch/latest/monitoring/images/Service_detail.png) # 透過服務詳細資訊頁面檢視詳細的服務活動和操作狀態 當您檢測應用程式時，[Amazon CloudWatch Application Signals](CloudWatch-Application-Monitoring-Sections.md) 會對應應用程式發現的所有服務。透過服務詳細資訊頁面，可檢視單一服務的服務、操作、相依項、Canary 及用戶端請求概覽。若要檢視服務詳細資訊頁面，請執行下列動作： + 開啟 [CloudWatch 主控台](https://console.aws.amazon.com/cloudwatch/)。 + 在左側導覽窗格的 **Application Signals** 區段下選擇**服務**。 + 從**服務**、**熱門服務**或相依項資料表中選擇服務名稱。 在**排程造訪**下，服務名稱下方會顯示帳戶標籤和 ID。 服務詳細資訊頁面分為以下索引標籤： + [概觀](#ServiceDetail-overview)：可透過此索引標籤檢視單一服務的概觀，包括操作數量、相依項、合成和用戶端頁面。此索引標籤顯示您整個服務的關鍵指標、主要操作項目及相依項。這些指標包括該服務所有服務操作的延遲、故障和錯誤時間序列資料。 + [服務操作](#ServiceDetail-operations)：可透過此索引標籤檢視服務呼叫的操作清單，以及含關鍵指標 (用於衡量每項操作的運作狀態) 的互動式圖形。您可以在圖形中選取資料點，以取得與該資料點關聯的追蹤、日誌或指標的相關資訊。 + [相依項](#ServiceDetail-dependencies)：可透過此索引標籤檢視服務呼叫的相依項清單，以及該等相依項的指標清單。 + [Synthetics Canary](#ServiceDetail-canaries)：可透過此索引標籤檢視模擬使用者呼叫服務的 Synthetics Canary 清單，以及這些 Canary 如何運作的關鍵效能指標。 + [用戶端頁面](#ServiceDetail-clientpages)：可透過此索引標籤檢視呼叫您服務的用戶端頁面清單，以及衡量用戶端與應用程式互動品質的指標。 + [相關指標](#ServiceDetail-relatedmetrics)：可透過此索引標籤關聯相關指標，例如服務的標準指標、執行時期指標和自訂指標、其操作或相依項。 ## 檢視您的服務概觀 可透過服務概觀頁面，在一個位置檢視所有服務操作指標的高階摘要。檢查與您的應用程式互動的所有操作、相依項、用戶端頁面和 Synthetics Canary 的效能。此資訊可協助釐清應將精力集中於哪些領域，以識別問題、排除錯誤並尋找最佳化機會。 選擇**服務詳細資訊**中的連結可檢視與特定服務相關的資訊。例如，對於 Amazon EKS 中託管的服務，服務詳細資訊頁面會顯示**叢集**、**命名空間**及**工作負載**資訊。對於 Amazon ECS 或 Amazon EC2 中託管的服務，服務詳細資訊中會顯示**環境**值。 在**服務**下，**概觀**索引標籤顯示下列項目的摘要： + 操作 – 可透過此索引標籤檢視服務操作的運作狀態。運作狀態由服務水準指標 (SLI) 決定，此指標作為[服務水準目標](CloudWatch-ServiceLevelObjectives.md) (SLO) 一部分定義。 + 相依項 – 可透過此索引標籤檢視應用程式呼叫之服務的主要相依項 (依錯誤率列示)，並檢視服務相依項的運作狀態。運作狀態由服務水準指標 (SLI) 決定，此指標作為服務水準目標 (SLO) 一部分定義。 + Synthetics Canary – 可透過此標籤檢視模擬呼叫與服務關聯之端點或 API 的結果，以及失敗的 Canary 數量。 + 用戶端頁面 – 可透過此索引標籤檢視用戶端呼叫的具有非同步 JavaScript 和 XML (AJAX) 錯誤的主要頁面。 下圖顯示服務概觀： ![\[服務概觀小工具\]](http://docs.aws.amazon.com/zh_tw/AmazonCloudWatch/latest/monitoring/images/service-detail-widgets.png) **概觀**索引標籤亦會顯示所有服務中延遲最高的相依項圖表。使用 **p99**、**p90 **和 **p50** 延遲指標快速評估哪些相依項導致了您的總服務延遲，具體如下： ![\[服務操作延遲圖表\]](http://docs.aws.amazon.com/zh_tw/AmazonCloudWatch/latest/monitoring/images/service-detail-latency.png) 例如，上圖顯示對**客戶服務**相依項發出的請求中，有 99% 在約 4,950 毫秒內完成。其他相依項花費的時間更短。 顯示延遲最高的四項服務操作的圖表，呈現這些服務的請求量、可用性、故障率和錯誤率，如下圖所示： ![\[服務操作量、可用性、故障率和錯誤率圖表\]](http://docs.aws.amazon.com/zh_tw/AmazonCloudWatch/latest/monitoring/images/service-detail-operations-graphs.png) **服務詳細資訊**區段顯示服務的詳細資訊，包括**帳戶 ID** 和**帳戶標籤**。 ## 檢視服務操作 當您檢測應用程式時，[Application Signals](CloudWatch-Application-Monitoring-Sections.md) 會偵測到應用程式呼叫的所有服務操作。可透過**服務操作**索引標籤檢視包含服務操作的資料表，以及一組衡量所選操作效能的指標。這些指標包括 SLI 狀態、相依項數量、延遲、磁碟區、故障、錯誤及可用性，如下圖所示： ![\[服務操作資料表\]](http://docs.aws.amazon.com/zh_tw/AmazonCloudWatch/latest/monitoring/images/service-operations-table.png) 篩選「服務」資料表可更容易找到服務操作，方法是從篩選文字方塊中選擇一個或多個屬性。當您選擇每個屬性時，系統會引導您完成篩選條件，並在篩選文字方塊下方看到完整的篩選條件。可隨時選擇**清除篩選條件**以移除資料表篩選條件。 選擇操作的 SLI 狀態以顯示快顯視窗，其中包含任何狀態不良 SLI 的連結，以及可檢視所有操作之 SLO 的連結，如以下資料表中所示： ![\[服務操作 SLI 狀態\]](http://docs.aws.amazon.com/zh_tw/AmazonCloudWatch/latest/monitoring/images/service-operation-unhealthy-slo.png) 服務操作資料表會列出 SLI 狀態、運作狀態良好或不好之 SLI 的數量，以及每個操作的 SLO 總數。 SLI 可用於監控延遲、可用性，以及衡量服務操作狀態的其他操作指標。SLO 可用於檢查服務和操作的效能及運作狀態。 若要建立 SLO，請執行下列動作： + 如果操作沒有 SLO，請在 **SLI 狀態**資料欄中選擇**建立 SLO** 按鈕。 + 如果操作已有 SLO，請執行下列動作： + 點選操作名稱旁的單選按鈕。 + 從資料表右上角的**動作**向下箭頭中選擇**建立 SLO**。 如需詳細資訊，請參閱[服務水準目標 (SLO)](CloudWatch-ServiceLevelObjectives.md)。 **相依性**欄會顯示此操作所呼叫的相依性數目。選擇此數字可開啟已根據所選操作篩選的**相依性**索引標籤。 ### 檢視服務操作指標、相關追蹤和應用程式日誌 Application Signals 會將服務操作指標與 AWS X-Ray 追蹤、CloudWatch [Container Insights](ContainerInsights.md) 和應用程式日誌建立關聯。這些指標可用於排查操作狀態問題。若要以圖形形式檢視指標，請執行下列動作： 1. 在**服務操作**資料表中選取服務操作，以檢視資料表上方所選操作的一組圖形，其中包含**磁碟區和可用性**、**延遲**、**故障和錯誤**指標。 1. 將滑鼠游標移至圖形中的某個點可檢視詳細資訊。 1. 選取一個點可開啟診斷窗格，其中會顯示圖表中選取點的相關追蹤、指標及應用程式日誌。 下圖顯示將游標懸停於圖表中某個點後出現的工具提示，以及按一下該點後顯示的診斷窗格。工具提示包含**故障和錯誤**圖形中關聯資料點的相關資訊。窗格包含與所選點關聯的**關聯追蹤**、**主要貢獻因子**和**應用程式日誌**。 ![\[故障和錯誤的相關追蹤\]](http://docs.aws.amazon.com/zh_tw/AmazonCloudWatch/latest/monitoring/images/service-detail-correlated-traces.png) #### 相關追蹤 查看相關追蹤以了解與追蹤相關的潛在問題。您可以檢查相關追蹤或其關聯的任何服務節點是否表現出類似行為。若要檢查相關追蹤，從**關聯追蹤**資料表中選擇**追蹤 ID**，開啟所選追蹤的 [X-Ray 追蹤詳細資訊](https://docs.aws.amazon.com/xray/latest/devguide/xray-console-traces.html)頁面。追蹤詳細資訊頁面包含與所選追蹤相關聯的服務節點對應，以及追蹤區段的時間軸。 #### 主要貢獻因子 檢視主要貢獻因子，以尋找指標的主要輸入源。依不同元件對貢獻因子進行分組，以尋找群組中的相似性，並了解群組之間的追蹤行為差異。 **主要貢獻因子**索引標籤提供每個群組的**通話量**、**可用性**、**平均延遲**、**錯誤**和**故障**指標。下列範例影像顯示部署於 Amazon EKS 平台上之應用程式的各項指標的主要貢獻因子： ![\[服務操作主要貢獻因子\]](http://docs.aws.amazon.com/zh_tw/AmazonCloudWatch/latest/monitoring/images/service-operations-top-contributors.png) 主要貢獻因子包含下列指標： + **通話量**：可透過通話量了解某個群組在每個時間間隔內的請求數量。 + **可用性**：可透過可用性檢視某個群組中未偵測到故障的時間佔比。 + **平均延遲**：可透過延遲檢查某個群組在一定時間間隔內執行請求的平均時間，該時間間隔取決於您正在調查的請求是在多久以前發出的。對於 15 天內提出的請求，將以 1 分鐘為間隔進行評估。對於 15 到 30 天前提出的請求，將以 5 分鐘為間隔進行評估。例如，如果您正在調查 15 天前導致故障的請求，則呼叫量指標等於每 5 分鐘間隔的請求數。 + **錯誤**：特定時間間隔內，每個群組出現的錯誤數。 + **故障**：特定時間間隔內，每個群組出現的故障數。 **使用 Amazon EKS 或 Kubernetes 的主要貢獻因子** 針對部署於 Amazon EKS 或 Kubernetes 上的應用程式，使用主要貢獻因子相關資訊，檢視依**節點**、**Pod** 及 **PodTemplateHash** 分組的操作狀態指標。適用以下定義： + **Pod** 是共用儲存空間和資源的一或多個 Docker 容器群組。Pod 是可部署於 Kubernetes 平台上的最小單位。依 Pod 分組，確定錯誤是否與 Pod 特定限制相關。 + **節點**是執行 Pod 的伺服器。依節點分組，確定錯誤是否與節點特定限制相關。 + **Pod 範本雜湊**用於尋找特定版本的部署。依 Pod 範本雜湊分組，確定錯誤是否與特定部署相關。 **使用 Amazon EC2 的主要貢獻因子** 針對部署於 Amazon EKS 上的應用程式，使用主要貢獻因子相關資訊，檢視依執行個體 ID 和 Auto Scaling 群組分組的操作狀態指標。適用以下定義： + **執行個體 ID** 是您的服務執行之 Amazon EC2 執行個體的唯一識別符。依執行個體 ID 分組，確定錯誤是否與特定 Amazon EC2 執行個體相關。 + [Auto Scaling 群組](https://docs.aws.amazon.com/autoscaling/ec2/userguide/auto-scaling-groups.html)是 Amazon EC2 執行個體的集合，用於擴展或縮減處理應用程式請求所需的資源。如果想要確定錯誤是否僅限於群組內的執行個體，請依 Auto Scaling 群組分組。 **使用自訂平台的主要貢獻因子** 針對使用自訂檢測部署的應用程式，使用主要貢獻因子相關資訊，檢視依**主機名稱**分組的操作狀態指標。適用以下定義： + 主機名稱用於識別連線至網路的裝置，例如端點或 Amazon EC2 執行個體。依主機名稱分組，確定您的錯誤是否與特定實體或虛擬裝置相關。 **在 Log Insights 和 Container Insights 中檢視主要貢獻因子** 在 [Log Insights](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AnalyzingLogData.html) 中檢視和修改為主要貢獻因子產生指標的自動查詢。在 [Container Insights](ContainerInsights.md) 中依特定群組 (例如 Pod 或節點) 檢視基礎結構效能指標。可依資源消耗對叢集、節點或工作負載排序，並在最終使用者體驗受到影響之前快速識別異常或主動緩解風險。下圖展示如何選取這些選項： ![\[主要貢獻因子資料表\]](http://docs.aws.amazon.com/zh_tw/AmazonCloudWatch/latest/monitoring/images/service-operations-top-contributors-insights.png) 在 **Container Insights** 中，可以檢視特定於主要貢獻因子分組的 Amazon EKS 或 Amazon ECS 容器指標。例如，如果依 EKS 容器的 Pod 分組來產生主要貢獻因子，Container Insights 將顯示針對 Pod 篩選的指標和統計資料。 在 **Log Insights** 中，可依下列步驟修改**主要貢獻因子**下產生指標的查詢： 1. 選取**在 Log Insights 中檢視**。開啟的 **Logs Insights** 頁面包含自動產生的查詢，其中包括下列資訊： + 日誌叢集群組名稱。 + 使用 CloudWatch 調查的操作。 + 在圖表上互動之操作狀態指標的彙總。 日誌結果會自動篩選，僅顯示您在服務圖表上選取資料點前最後五分鐘的資料。 1. 若要編輯查詢，請用您的變更替換產生的文字。也可以使用**查詢產生器**協助產生新的查詢，或更新現有查詢。 #### 應用程式記錄 在**應用程式日誌**索引標籤中使用查詢來產生目前日誌群組、服務的記錄資訊，並插入時間戳記。日誌群組是一組日誌串流，您可以在設定應用程式時定義。 使用日誌群組來編排具有類似特性的日誌，包括下列內容： + 擷取來自特定組織、來源或功能的日誌。 + 擷取由特定使用者存取的日誌。 + 擷取特定時段的日誌。 這些日誌串流用於追蹤特定群組或時間範圍。也可以設定這些日誌群組的監控規則、警示和通知。如需有關日誌群組的詳細資訊，請參閱[使用日誌群組和日誌串流](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Working-with-log-groups-and-streams.html)。 應用程式日誌查詢會傳回日誌、週期性文字模式和日誌群組的圖形視覺化資料。 若要執行查詢，請選取**在 Logs Insights 中執行查詢**，以執行自動產生的查詢或修改查詢。若要編輯查詢，請用您的變更替換自動產生的文字。也可以使用**查詢產生器**協助產生新的查詢，或更新現有查詢。 下圖顯示根據服務操作圖表中選取的點自動產生的查詢範例： ![\[應用程式日誌資料表\]](http://docs.aws.amazon.com/zh_tw/AmazonCloudWatch/latest/monitoring/images/service-operations-application-logs.png) 在上圖中，CloudWatch 自動偵測到與您所選點關聯的日誌群組，並將其包含在產生的查詢中。 ## 檢視服務相依性 選擇**相依性**索引標籤，即可顯示**相依性**資料表，以及所有服務操作或單個操作之相依性的一組指標。此資料表包含 Application Signals 發現的相依項清單，包括 SLI 狀態、延遲、呼叫量、故障率、錯誤率和可用性的指標。 在頁面頂端，從下拉式清單中選擇操作以檢視其相依項，或選擇**全部**查看所有操作的相依項。 篩選資料表，可讓您更容易找到要尋找的內容，方法是從篩選文字方塊中選擇一個或多個屬性。當您選擇每個屬性時，系統會引導您完成篩選條件，並在篩選文字方塊下方看到完整的篩選條件。可隨時選擇**清除篩選條件**以移除資料表篩選條件。選取資料表右上角的**按相依性分組**，可按服務和操作名稱對相依性分組。開啟分組時，使用相依性名稱旁邊的 **\$1** 圖示來展開或摺疊相依性群組。 ![\[相依性資料表\]](http://docs.aws.amazon.com/zh_tw/AmazonCloudWatch/latest/monitoring/images/service-dependencies-table.png) **相依性**資料欄會顯示相依性服務名稱，而**遠端操作**資料欄則顯示服務操作名稱。**SLI 狀態**欄位顯示運作狀態良好或不好的 SLI 數量，以及每個相依項的 SLI 總數。呼叫 AWS 服務時，**目標**欄會顯示 AWS 資源，例如 DynamoDB 資料表或 Amazon SNS 佇列。 若要選取相依性，請選取**相依性**資料表中某個相依性旁邊的選項。此時會顯示一組圖表，其中顯示呼叫量、可用性、故障和錯誤的詳細指標。將滑鼠移至圖表中的某個點上，即可看到包含更多資訊的快顯視窗。在圖表中選取一個點可開啟診斷窗格，其中會顯示圖表中所選點的相關軌跡。從**關聯追蹤**資料表中選擇追蹤 ID，可開啟所選追蹤的 [X-Ray 追蹤詳細資訊](https://docs.aws.amazon.com/xray/latest/devguide/xray-console-traces.html)頁面。 ![\[相依性圖表和相關追蹤\]](http://docs.aws.amazon.com/zh_tw/AmazonCloudWatch/latest/monitoring/images/service-dependency-graph-traces.jpg) ## 檢視 Synthetics Canaries 選擇 **Synthetics Canaries** 索引標籤以顯示 **Synthetics Canaries** 資料表，以及資料表中每個 Canary 的一組指標。此表格包含成功百分比、平均持續時間、執行次數和失敗率的指標。只會顯示[已啟用 AWS X-Ray 追蹤的](CloudWatch_Synthetics_Canaries_tracing.md) Canary。 透過合成 Canary 資料表中的篩選條件文字方塊，可尋找您感興趣的 Canary。所建立的每個篩選條件將顯示在篩選條件文字方塊下方。可隨時選擇**清除篩選條件**以移除資料表篩選條件。 ![\[Synthetics Canaries 資料表\]](http://docs.aws.amazon.com/zh_tw/AmazonCloudWatch/latest/monitoring/images/service-canaries-table.png) 選取 Canary 名稱旁的選項按鈕，可看到包含圖形詳細指標的一組索引標籤，包括成功百分比、錯誤和持續時間。將滑鼠移至圖表中的某個點上，即可看到包含更多資訊的快顯視窗。在圖表中選取一個點可開啟診斷窗格，其中會顯示與所選點相關的 Canary 執行。選取 Canary 執行，然後選擇**執行時間**以查看所選 Canary 執行的成品，包括日誌、HTTP封存 (HAR) 檔案、螢幕擷取畫面和建議步驟，以協助排解問題。選擇**進一步了解**可開啟 [Canary 執行](CloudWatch_Synthetics_Canaries.md)旁的 **CloudWatch Synthetics Canary** 頁面。 ![\[Synthetics Canary 圖表和執行\]](http://docs.aws.amazon.com/zh_tw/AmazonCloudWatch/latest/monitoring/images/service-canary-graphs-runs.jpg) ## 檢視您的用戶端頁面 選擇**用戶端頁面**索引標籤，可顯示呼叫您服務的用戶端網頁清單。使用所選用戶端頁面的指標集，衡量用戶端在與服務或應用程式互動時獲得的體驗品質。這些指標包括頁面載入次數、網頁核心指標以及錯誤狀況。 若要在資料表中顯示用戶端頁面，必須[設定 CloudWatch RUM Web 用戶端以進行 X-Ray 追蹤](CloudWatch-RUM-get-started-create-app-monitor.md)，並為用戶端頁面開啟 Application Signals 指標。選擇**管理頁面**，以管理為 Application Signals 指標啟用哪些頁面。 透過篩選條件文字方塊，在篩選條件文字方塊下方找到您感興趣的用戶端頁面或應用程式監視器。選擇**清除篩選條件**以移除資料表篩選條件。選取**按用戶端分組**，可按用戶端對用戶端頁面進行分組。分組後，選擇用戶端名稱旁邊的 **\$1** 圖示以展開該列，並查看該用戶端的所有頁面。 ![\[用戶端頁面資料表\]](http://docs.aws.amazon.com/zh_tw/AmazonCloudWatch/latest/monitoring/images/service-client-pages-table.png) 若要選取用戶端頁面，請在**用戶端頁面**資料表中選取用戶端頁面旁邊的選項。您將看到一組顯示詳細指標的圖表。將滑鼠移至圖表中的某個點上，即可看到包含更多資訊的快顯視窗。在圖表中選取一個點可開啟診斷窗格，其中會顯示圖表中所選點的相關效能導覽事件。從導覽事件清單中選擇事件 ID，以開啟所選事件的 [CloudWatch RUM 頁面檢視](CloudWatch-RUM-view-data.md)。 ![\[CloudWatch RUM 用戶端頁面請求\]](http://docs.aws.amazon.com/zh_tw/AmazonCloudWatch/latest/monitoring/images/service-client-page-graphs-events.jpg) **注意** 若要查看用戶端頁面中的 AJAX 錯誤，請使用 [CloudWatch RUM Web 用戶端](CloudWatch-RUM-configure-client.md)版本 1.15 或更新版本。 每個服務最多可顯示 100 個操作、Canary 和用戶端頁面，以及最多 250 個相依項。 ## 檢視相關指標 透過相關指標索引標籤，可視覺化多個指標、識別相互關聯模式，以及判斷問題的根本原因。 指標資料表顯示三種類型的指標： + 標準指標 – Application Signals 會從它發現的服務中收集標準應用程式指標。如需詳細資訊，請參閱[收集的標準應用程式指標](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AppSignals-MetricsCollected.html#AppSignals-StandardMetrics) + 執行時間指標 – Application Signals 使用 AWS Distro for OpenTelemetry SDK 從您的 Java 和 Python 應用程式自動收集 OpenTelemetry 相容指標。如需詳細資訊，請參閱[執行時期指標](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/AppSignals-MetricsCollected.html#AppSignals-RuntimeMetrics) + 自訂指標 – 透過 Application Signals，可以從應用程式產生自訂指標。如需詳細資訊，請參閱[使用 Application Signals 自訂指標](AppSignals-CustomMetrics.md) 可以從服務概觀、服務操作、相依項、Synthetics Canary 或 RUM 索引標籤存取相關指標索引標籤。 ![\[檢視相關指標\]](http://docs.aws.amazon.com/zh_tw/AmazonCloudWatch/latest/monitoring/images/Custom_metrics.png) + 左側導覽面板啟動時所有操作和相依項均未選取 + 圖表一開始會顯示具有最高故障率之操作的故障指標 開始相互關聯分析之前，請確定在服務操作或相依項中可以看到資料點。若要分析相互關聯，請執行以下動作： 1. 開啟服務操作或相依項頁面。 1. 在任意圖形上選取一個資料點。 1. 在右側面板中，選擇**與其他指標建立關聯**。 1. 在開啟的**相關指標**索引標籤上，您會看到： + 您在左側導覽中選取的操作或相依項 + 所選指標已在*瀏覽指標*資料表中繪製為圖表 + 選取資料點時的相關範圍 若要繪製多個指標的圖表，請從**相關指標**索引標籤的**瀏覽**檢視中選取一或多個指標。選擇**圖表化指標**可檢視所有圖表化指標。 若要篩選指標，請使用左側面板篩選條件來專注於特定操作或相依項，並使用資料表標題篩選條件列來依名稱、類型或其他屬性進行搜尋。這些篩選選項可協助更有效率地偵測模式和排解問題。 若要詳細分析相關指標，請在**相關指標**索引標籤中選取一個資料點。隨後，可以檢視： + 主要貢獻因子 – 透過執行 CloudWatch Logs Insights 查詢來分析指標。這些查詢會處理包含金鑰屬性的增強型指標格式 (EMF) 記錄，以進行下列內容的詳細分析： + 延遲度量值 + 故障發生次數 + 服務可用性指標 下列指標不支援主要貢獻因子： + OTEL 指標 + 伺服器端範圍指標 可以檢視 RED 指標和用戶端範圍指標的主要貢獻因子。 + 相互關聯範圍 –「相互關聯範圍」區段與「服務操作」索引標籤一致運作。為協助您識別相關的追蹤和指標，相互關聯機制以如下方式運作： + 比較指標名稱與範圍屬性 + 識別所選期間內的比對模式 + 顯示相關的追蹤資訊 若要有效地將指標和範圍結合起來進行分析，需要了解不同的指標類型如何相互關聯。以下是主要限制： + OTEL 指標與範圍無關聯，因為它們使用獨立的命名系統 + 若要將伺服器或用戶端範圍指標與範圍建立關聯： + 將服務維度欄位納入組態中 + 如果沒有此服務維度，就無法將這些指標與範圍建立關聯 + 日誌應用程式 – 如需日誌應用程式相關資訊，請參閱[應用程式日誌](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/ServiceDetail.html#ServiceDetail-operations) # 使用 CloudWatch 應用程式地圖檢視您的應用程式拓撲並監控操作狀態 **注意** CloudWatch 應用程式地圖取代了 Service Map。若要查看以 AWS X-Ray 追蹤為基礎的應用程式映射，請開啟 [X-Ray 追蹤映射](https://docs.aws.amazon.com/xray/latest/devguide/xray-console-servicemap.html)。在 CloudWatch 主控台的左側導覽窗格中，選擇 **X-Ray** 區段下的**追蹤地圖**。 啟用 Application Signals 的應用程式後，應用程式地圖會顯示代表您的群組的節點。然後，您可以深入分析這些群組，以檢視您的服務及其相依項。使用應用程式地圖來檢視應用程式用戶端的拓撲、Synthetics Canary、服務和相依項，以及監控操作狀態。若要檢視應用程式地圖，請開啟 [CloudWatch 主控台](https://console.aws.amazon.com/cloudwatch/)，然後在左側導覽窗格的 **Application Signals** 區段下選擇**應用程式地圖**。 在[啟用 Application Signals 的應用程式](CloudWatch-Application-Signals-Enable.md)之後，請使用應用程式地圖，可更輕鬆地監控應用程式的操作狀態： + 檢視用戶端、canary、服務和相依性節點之間的連線，以協助您了解應用程式拓撲和執行流程。如果您的服務營運商不是您的開發團隊，這將特別有用。 + 查看哪些服務符合或不符合您的[服務水準目標 (SLO)](CloudWatch-ServiceLevelObjectives.md)。當服務不符合您的 SLO 時，您可以快速識別下游服務或相依性是否可能導致問題或影響多個上游服務。 + 選取個別用戶端、Synthetics Canary、服務或相依項節點，以查看相關指標。[服務詳細資訊](ServiceDetail.md)頁面將顯示有關操作、相依項、Synthetics Canary 和用戶端頁面的詳細資訊。 + 篩選和縮放應用程式地圖，以便更輕鬆地專注於部分應用程式拓撲，或查看整個地圖。從篩選文字方塊中選擇一個或多個屬性來建立篩選條件。當您選擇每個屬性時，系統會引導您完成篩選條件。您將在篩選文字方塊下方看到完整的篩選條件。可隨時選擇**清除篩選條件**以移除篩選條件。 + 在單一統一應用程式映射中跨多個 AWS 帳戶監控服務。來自不同帳戶的服務會以帳戶資訊清楚識別，為分散式應用程式提供統一的可觀測性。 + 識別尚未在您的應用程式中檢測的服務。Application Signals 會自動偵測並顯示尚未經過檢測的服務，協助您實現完整的可觀測性涵蓋範圍。未檢測的服務會在地圖上以視覺方式區分，以協助您排定檢測工作的優先順序。 + 對服務進行分組和篩選，以建立符合您工作流程的自訂檢視。此組織可協助您快速尋找和存取最常用的服務 + 儲存經過篩選和分組的檢視，以快速返回常用的組態 ## 探索應用程式地圖 當您造訪應用程式地圖時，預設會顯示依**相關服務**分組的服務。相關服務將依相依項對服務分組。例如，若服務 A 呼叫服務 B，而服務 B 又呼叫服務 C，則這三者會被歸類在服務 A 之下。您可以檢視每個群組中所有服務的 SLI 運作狀態、指標及服務數量。 ![\[CloudWatch 預設應用程式地圖依相關服務分組。\]](http://docs.aws.amazon.com/zh_tw/AmazonCloudWatch/latest/monitoring/images/explore-application-map-overview.png) 選擇索引標籤，獲取有關探索它們之間各種節點和邊緣 (連接) 的資訊。 ### 動態分組和篩選 您可以按一下**分組依據**下拉式清單，使用不同的分組選項。依預設，應用程式地圖提供 2 個分組選項： + **相關服務**：依服務相依項對服務分組 + **環境**：依環境對服務分組 如果想要定義自己的自訂群組，請按一下**管理群組**定義自訂群組，然後使用群組金鑰標記服務或新增 OTEL 資源屬性。 **注意** 若要透過 OTEL 資源屬性啟用分組，CloudWatch 代理程式版本必須為 v1.300056.0 或更新版本。 ![\[建立自訂分組面板\]](http://docs.aws.amazon.com/zh_tw/AmazonCloudWatch/latest/monitoring/images/explore-application-map-create-custom-grouping.png) Application Signals 中的預設分組機制會根據服務的下游相依項自動對服務分組。系統會分析服務相依項圖表，並建立根節點 (沒有上游相依項的服務) 成為群組名稱的群組。所有依賴此根服務的服務 (無論直接或間接) 都會自動包含在群組中。例如，若服務 A 呼叫服務 B，而服務 B 又呼叫服務 C，這三個服務將被歸為一組，並以服務 A 作為群組名稱，因為它是相依項鏈的根節點。此自動分組機制提供自然的方式，能依據服務間實際的執行時期互動與相依項，直觀呈現並管理相關服務。 ### 群組動作與洞見 對於每個群組，可以執行下列動作： + 按一下**檢視更多**以檢視指標圖表、最後兩個變更事件，以及群組的上次部署時間 ![\[在應用程式映射中檢視群組的更多抽屜\]](http://docs.aws.amazon.com/zh_tw/AmazonCloudWatch/latest/monitoring/images/explore-application-map-view-more.png) + 按一下**檢視儀表板**以檢視 群組的指標儀表板、變更事件表和服務清單 ![\[檢視 群組的應用程式儀表板\]](http://docs.aws.amazon.com/zh_tw/AmazonCloudWatch/latest/monitoring/images/explore-application-map-team-overview.png) ![\[檢視具有指標圖表之群組的應用程式儀表板\]](http://docs.aws.amazon.com/zh_tw/AmazonCloudWatch/latest/monitoring/images/explore-application-map-team-overview-2.png) 您可以使用左側列上的**群組和篩選條件**來篩選具有部署時間、SLI 運作狀態或運算平台類型的服務群組。 ![\[應用程式儀表板上的分組和篩選服務\]](http://docs.aws.amazon.com/zh_tw/AmazonCloudWatch/latest/monitoring/images/explore-application-map-grouping-filter.png) 您也可以依帳戶篩選，以在跨帳戶可觀測性設定中檢視來自特定 AWS 帳戶的服務。 ![\[在應用程式儀表板上依帳戶篩選服務\]](http://docs.aws.amazon.com/zh_tw/AmazonCloudWatch/latest/monitoring/images/explore-application-map-account-filter.png) 透過**搜尋和篩選條件**導覽列，可依名稱搜尋群組，或搜尋包含特定服務環境或相依項的群組。依帳戶 ID 篩選，以專注於來自特定帳戶的服務。 ![\[在應用程式映射中搜尋和篩選服務\]](http://docs.aws.amazon.com/zh_tw/AmazonCloudWatch/latest/monitoring/images/explore-application-map-search-and-filter.png) ### 設定自訂群組 透過自訂分組功能，您可以根據業務需求和營運優先順序以邏輯方式對服務分組。藉助此功能，您可以檢視並儲存依特定需求排序的預設檢視，依據團隊所有權建立群組，並組建關鍵業務交易所需的服務群組。 建立自訂群組名稱 (您將在 UI 中看到的群組名稱) 和對應的群組金鑰名稱。從 Application Signals UI 或者利用 [PutGroupingConfiguration](https://docs.aws.amazon.com/applicationsignals/latest/APIReference/API_PutGroupingConfiguration.html) API 完成此步驟。 群組金鑰名稱可以是您服務的 AWS 標籤金鑰或 OTEL 資源屬性。在決定使用標籤還是 OTEL 資源屬性時，請考慮您的運算平台： + 對於單一服務平台 （例如 Lambda 或 Auto Scaling 群組） – 使用 AWS 標籤 + 對於多服務平台 (例如 Amazon EKS 叢集)，使用 OTEL 資源屬性進行更精細的分組 **新增 AWS 標籤** 將具有自訂群組金鑰的 AWS 標籤做為金鑰和值新增至 Amazon EKS 叢集。如果有多個服務在同一個 Amazon EKS 叢集內執行，系統會使用同一自訂群組金鑰標記所有服務。例如，當 Amazon EKS 叢集 A 執行 Service 1、Service 2 和 Service 3 時，將具有金鑰 *Team X* 的 AWS 標籤新增至叢集會將所有三個服務新增至 *Team X*。 若要僅將特定服務新增至*團隊 X*，請新增服務的 OTEL 資源屬性，如下所示。 **新增 OTEL 資源屬性** 若要新增 OTEL 資源屬性，請參閱下列組態： **一般組態** 使用自訂群組索引鍵/值對在應用程式中設定 `OTEL_RESOURCE_ATTRIBUTES` 環境變數。金鑰以 `&` 分隔，列在 `aws.application_signals.metric_resource_keys` 下。 例如，若要使用 `Application=PetClinic` 和 `Owner=Test` 建立自訂群組，請遵照下列步驟： ``` OTEL_RESOURCE_ATTRIBUTES=Application=PetClinic,Owner=Test,aws.application_signals.metric_resource_keys=Application&Owner ``` **平台特定的組態** 以下是部署規格。 **Amazon EKS 及原生 kubernetes** ``` apiVersion: apps/v1 kind: Deployment metadata: ... spec: replicas: 1 ... template: spec: containers: - name: your-app image: your-app-image env: ... - name: OTEL_RESOURCE_ATTRIBUTES value: Application=PetClinic,Owner=Test,aws.application_signals.metric_resource_keys=Application&Owner ``` **Amazon EC2** 將 `OTEL_RESOURCE_ATTRIBUTES` 新增至您的應用程式啟動指令碼。如需完整範例，請參閱[新增 `OTEL_RESOURCE_ATTRIBUTES`](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Application-Signals-Enable-EC2Main.html#CloudWatch-Application-Signals-Monitor-EC2)。 ``` ... OTEL_RESOURCE_ATTRIBUTES="service.name=$YOUR_SVC_NAME,Application=PetClinic,Owner=Test,aws.application_signals.metric_resource_keys=Application&Owner" \ java -jar $MY_JAVA_APP.jar ``` **Amazon ECS** 將 `OTEL_RESOURCE_ATTRIBUTES` 新增至 TaskDefinition。如需完整範例，請參閱[在 Amazon ECS 上啟用](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Application-Signals-Enable-ECSMain.html)。 ``` { "name": "my-app", ... "environment": [ { "name": "OTEL_RESOURCE_ATTRIBUTES", "value": "service.name=$YOUR_SVC_NAME,Application=PetClinic,Owner=Test,aws.application_signals.metric_resource_keys=Applicationmanagement portalOwner" }, ... ] } ``` **Lambda** 將 `OTEL_RESOURCE_ATTRIBUTES` 新增至 Lambda 環境變數。 ``` OTEL_RESOURCE_ATTRIBUTES="Application=PetClinic,Owner=Test,aws.application_signals.metric_resource_keys=Application&Owner" ``` ### 檢視群組內的服務 若要檢視群組中的服務及其相依項，請按一下群組名稱。此時會顯示群組內的服務地圖。每個服務節點都會顯示 SLI 運作狀態、指標及平台詳細資訊。違反 SLI 的服務都會反白顯示，以便輕鬆辨識。 ![\[群組內的 CloudWatch 應用程式地圖服務。\]](http://docs.aws.amazon.com/zh_tw/AmazonCloudWatch/latest/monitoring/images/View-services-groups.png) 未檢測的服務會以獨特的視覺指標 （例如虛線邊界或不同顏色） 顯示，以區分它們與檢測的服務。將滑鼠游標暫留在未檢測的服務節點上，以查看檢測指引和設定文件的連結。 ![\[在應用程式映射上依未檢測的服務篩選\]](http://docs.aws.amazon.com/zh_tw/AmazonCloudWatch/latest/monitoring/images/explore-application-map-uninstrumented-filter.png) 根據預設，所有 Canary、RUM 用戶端 AWS 和服務節點都會收合。如果此群組中的服務呼叫不屬於此群組的服務，則這些服務預設也會收合。 ![\[Canary 節點會摺疊到應用程式映射中的群組中\]](http://docs.aws.amazon.com/zh_tw/AmazonCloudWatch/latest/monitoring/images/explore-application-map-canary-collapse.png) 若您的地圖仍過於龐大而難以有效調查，可運用嵌套分組功能逐步縮小調查範圍。例如，在依**業務單位**對服務分組之後，如果群組中仍有太多服務，請透過「分組依據」下拉式清單選取**團隊**，建立巢狀分組結構。 ![\[應用程式映射中的巢狀分組\]](http://docs.aws.amazon.com/zh_tw/AmazonCloudWatch/latest/monitoring/images/explore-application-map-nested-grouping.png) ### 服務洞察及詳細資訊 可在此頁面上按一下搜尋列旁的**儲存檢視**以儲存檢視，下次就不需要再次套用相同的分組和篩選設定。 ![\[儲存分組組態\]](http://docs.aws.amazon.com/zh_tw/AmazonCloudWatch/latest/monitoring/images/explore-application-map-save-view.png) 按一下在服務節點中**檢視更多**，以檢視服務稽核、變更事件、SLI 運作狀態和指標圖表。 ![\[CloudWatch 應用程式地圖服務洞察。\]](http://docs.aws.amazon.com/zh_tw/AmazonCloudWatch/latest/monitoring/images/explore-application-map-service-view-more.png) 如果您想要檢視服務操作和其他服務詳細資訊，請按一下**檢視儀表板**以前往服務概觀頁面。 ![\[CloudWatch 應用程式映射服務概觀。\]](http://docs.aws.amazon.com/zh_tw/AmazonCloudWatch/latest/monitoring/images/explore-application-map-service-overview.png) 也可以按一下 Edge 來檢視服務特定相依項呼叫的指標。 ![\[CloudWatch 應用程式映射節點邊緣抽屜\]](http://docs.aws.amazon.com/zh_tw/AmazonCloudWatch/latest/monitoring/images/explore-application-map-edge.png) ### 變更事件 使用 Application Signals 自動處理 CloudTrail 事件，追蹤整個應用程式的變更事件。監控 服務的組態和部署事件及其相依性，提供操作分析和故障診斷的立即內容。透過 CloudWatch 主控台或 StartDiscovery API 啟用服務探索，即可啟用變更事件偵測。對於 EKS 服務，部署偵測要求使用 Application Signals 檢測 SDK 檢測 EKS 服務。Application Signals 會自動將部署時間與效能變更建立關聯，協助快速判斷近期的部署是否導致了服務問題。檢視您服務中的變更事件歷史記錄和影響，而不需要額外的組態或設定要求。 ### 稽核調查結果 透過 Application Signals 的稽核調查結果，發掘關鍵洞察。此服務會分析您的應用程式，以報告重大觀察和潛在問題，簡化根本原因分析。這些自動化問題清單會合併相關追蹤，無需多次點選即可瀏覽。稽核系統可協助團隊快速識別問題及其根本原因，從而更快解決問題。 對於在 Amazon Bedrock 上執行的服務，Application Signals 會自動監控 GenAI 字符使用模式。稽核系統偵測輸入和輸出字符耗用的異常，比較目前用量與歷史基準。當字符用量超過正常模式時，稽核調查結果會提供詳細的分析，包括字符消耗趨勢、成本影響和最佳化建議。這有助於團隊識別效率低下的提示、非預期的字符峰值，以及降低 GenAI 營運成本的機會。 ### 應用程式地圖上的跨帳戶可觀測性 Application Signals 支援跨帳戶可觀測性，可讓您在單一統一應用程式映射中監控和視覺化分散在多個 AWS 帳戶中的服務。此功能對於具有遵循 AWS 最佳實務的多帳戶架構的組織至關重要。 **關鍵功能：** + *統一檢視*：在單一應用程式映射中檢視來自多個 AWS 帳戶的 服務，提供分散式應用程式架構的完整影像。 + *帳戶識別*：每個服務節點都會清楚顯示其帳戶 ID 和區域，讓您輕鬆識別服務擁有權和位置。 + *集中監控*：從單一監控帳戶監控所有連線帳戶的服務運作狀態、效能和 SLO 狀態。 + *跨帳戶篩選*：依帳戶 ID 篩選和分組服務，以專注於特定帳戶或檢視跨帳戶互動。 **運作方式：** Application Signals 使用 AWS Organizations 和跨帳戶共用來啟用多個帳戶的可觀測性。若要設定跨帳戶可觀測性，請參閱 [CloudWatch 跨帳戶觀察功能](CloudWatch-Unified-Cross-Account.md)。 ------ #### [ View your application services ] **服務 （已檢測）** 可以在 **Application Map** 中檢視應用程式服務及其 SLO 和服務層級指標 (SLI) 的狀態。如果尚未為服務建立 SLO，請選擇服務節點下方的**建立 SLO** 按鈕。 **Application Map** 會顯示所有服務。還會顯示取用服務的客戶和 Canary，以及您的服務呼叫的相依項，如下圖所示： ![\[顯示運作狀態良好和不佳服務的 CloudWatch Application Map。\]](http://docs.aws.amazon.com/zh_tw/AmazonCloudWatch/latest/monitoring/images/service-map-service-healthy-unhealthy.png) 當您選取服務節點時，會開啟一個窗格，顯示詳細的服務資訊： + 錯誤率和故障率總計。 + `healthy`或`unhealthy`的 SLI 和 SLO 總數。 + 檢視 SLO 詳細資訊的選項。 + Amazon EKS 中託管的服務的`Cluster`、`Namespace`和`Workload`，或是 Amazon ECS 或 Amazon EC2 中託管的服務環境。對於 Amazon EKS 託管的服務，請選擇任何連結以開啟 CloudWatch Container Insights。 + 帳戶 ID 和區域。 + **變更**區段顯示最近的變更事件和上次部署時間。 + **操作稽核**索引標籤顯示自動執行之稽核的調查結果和建議。 + 可用性、延遲、故障和錯誤的服務指標圖表。 選取服務節點與下游服務或相依項節點之間的邊緣或連接。此時會開啟一個窗格，其中包含依故障率、延遲和錯誤率排序的主要路徑，如以下影像範例中所示。選擇窗格中的任何連結以開啟[服務詳細資訊](ServiceDetail.md)頁面，並查看所選服務或相依項的詳細資訊。 ![\[CloudWatch Application Map 服務邊緣\]](http://docs.aws.amazon.com/zh_tw/AmazonCloudWatch/latest/monitoring/images/App-signals-service-edge.png) 當您選取邊緣節點時，會開啟一個窗格，顯示詳細的服務資訊： + 請求總數、延遲、錯誤率和故障率 + 依故障率排序的主要路徑 + 依延遲排序的主要路徑 + 依錯誤率排序的主要路徑 **服務 （未檢測）** 未檢測的服務即使尚未使用 Application Signals 設定，也會出現在 Application Map 上。這些服務會透過使用應用程式名稱和標籤來利用 Resource Explorer 來自動探索。系統最多可以自動偵測您 AWS 帳戶中的 3，000 個資源。 當您選取未檢測的服務節點時，窗格會開啟，顯示： + 服務名稱和識別資訊 + 偵測到服務的 AccountId 和區域 + 檢測狀態和指引 + 呼叫動作按鈕「啟用 Application Signals」，提供設定指示 + 運算平台類型 （如果可偵測） 未經檢測的服務可協助您： + 識別可觀測性涵蓋範圍中的差距 + 根據其在架構中的位置，排定接下來要檢測的服務優先順序 + 即使在完整檢測之前，也要了解完整的應用程式拓撲 + 規劃整個組織的檢測推展 **注意** 未檢測的服務會顯示有限的遙測資料，因為它們不會主動傳送指標或追蹤。 ![\[CloudWatch 應用程式映射檢測篩選條件\]](http://docs.aws.amazon.com/zh_tw/AmazonCloudWatch/latest/monitoring/images/explore-application-map-instrumentation-filter.png) ------ #### [ View dependencies ] 您的應用程式相依項會顯示在 Application Map 上，並連接到呼叫它們的服務。 選擇相依項節點以開啟包含錯誤率和故障率的窗格、請求的指標圖表、可用性、延遲、故障率和錯誤率。 如果相依性節點是服務或資源，則窗格會顯示請求時間範圍的變更事件。 ![\[顯示可擴展 AWS 服務相依性節點的 CloudWatch 應用程式映射。\]](http://docs.aws.amazon.com/zh_tw/AmazonCloudWatch/latest/monitoring/images/service-map-dependency.png) ------ #### [ View clients ] 在為 CloudWatch RUM Web 用戶端[開啟 X-Ray 追蹤](CloudWatch-RUM-get-started-create-app-monitor.md)之後，它們會顯示在連線到它們所呼叫的 Application Map 上。 選擇一個用戶端節點以打開顯示詳細用戶端資訊的窗格： + 頁面載入、平均載入時間、錯誤和平均 Web 關鍵數值的指標 + 顯示錯誤明細的圖表 + 在 CloudWatch RUM 中顯示用戶端詳細資訊的連結 ![\[顯示可擴展用戶端節點的 CloudWatch Application Map。\]](http://docs.aws.amazon.com/zh_tw/AmazonCloudWatch/latest/monitoring/images/service-map-client.png) 選擇**檢視儀表板**開啟 Canary 詳細資訊。 ------ #### [ View synthetics canaries ] 若要檢視 Application Map 上的 Canary，請為 CloudWatch Synthetics Canary [開啟 X-Ray 追蹤](CloudWatch-RUM-get-started-create-app-monitor.md)。啟用後，Canary 將在 Application Map 上顯示為已連線到其呼叫的服務。 系統預設會將 Canary 整合為單一可展開圖示。詳細的 Canary 資訊窗格會顯示指標、追蹤和狀態資訊。 選擇 Canary 節點以開啟顯示詳細 Canary 資訊的窗格，如下圖所示： ![\[顯示可展開 Synthetics Canary 節點的 CloudWatch Application Map。\]](http://docs.aws.amazon.com/zh_tw/AmazonCloudWatch/latest/monitoring/images/service-map-canary.png) 選擇**檢視儀表板**開啟 Canary 詳細資訊。 ------ # AWS 動作的應用程式可觀測性 Application Observability for AWS GitHub Action 提供end-to-end應用程式觀察性調查工作流程，將您的原始程式碼和即時生產遙測資料連線至 AI 代理器。它利用 CloudWatch MCPs 並產生自訂提示，以提供 AI 代理器故障診斷和套用程式碼修正所需的內容。 動作會設定 [CloudWatch Application Signals MCP Server](https://awslabs.github.io/mcp/servers/cloudwatch-applicationsignals-mcp-server) 和 [CloudWatch MCP Server](https://awslabs.github.io/mcp/servers/cloudwatch-applicationsignals-mcp-server)，讓他們能夠存取即時遙測資料做為疑難排解內容。您可以使用您偏好的 AI 模型 - 無論是透過您自己的 API 金鑰、第三方模型或 Amazon Bedrock - 進行應用程式效能調查。 若要開始使用，請在 GitHub 問題`@awsapm`中提及 以觸發 AI 代理器。代理程式會根據您的即時應用程式資料，對生產問題進行故障診斷、實作修正並增強可觀測性涵蓋範圍。 此動作本身不會產生任何直接成本。不過，使用此動作可能會導致 AWS 服務和 AI 模型使用費。如需潛在成本的詳細資訊，[請參閱成本考量文件](https://github.com/marketplace/actions/application-observability-for-aws#-cost-considerations)。 ## 開始使用 此動作會透過產生 AWS特定的 MCP 組態和自訂可觀測性提示，在您的 GitHub 工作流程中設定 AI 代理器。您只需要提供要擔任的 IAM 角色和要使用的 [Bedrock 模型 ID](https://docs.aws.amazon.com/bedrock/latest/userguide/models-supported.html)，或現有 LLM 訂閱中的 API 權杖。以下範例示範工作流程範本，此範本會將此動作與 [Anthropic 的 claude-code-base-action](https://github.com/anthropics/claude-code-base-action) 整合，以執行自動化調查。 ### 先決條件 開始之前，請確定您有下列項目： + **GitHub 儲存庫許可**：寫入存取儲存庫或更高版本 （觸發 動作時需要） + **AWS IAM 角色**：針對具有下列許可的 GitHub 動作使用 OpenID Connect (OIDC) 設定的 IAM 角色： + CloudWatch Application Signals 和 CloudWatch 存取 + Amazon Bedrock 模型存取 （如果使用 Bedrock 模型） + **GitHub 權杖**：工作流程會自動使用具有所需許可的 GITHUB\$1TOKEN ### 設定步驟 #### 步驟 1：設定 AWS 登入資料 此動作倚賴 [aws-actions/configure-aws-credentials](https://github.com/aws-actions/configure-aws-credentials) 動作，在您的 GitHub Actions Environment 中設定 AWS 身分驗證。建議使用 OpenID Connect (OIDC) 進行身分驗證 AWS。OIDC 允許 GitHub 動作工作流程使用短期 AWS 憑證存取 AWS 資源，因此您不需要在儲存庫中存放長期憑證。 1. **建立 IAM 身分提供者** 首先，在 AWS 管理主控台中建立信任 GitHub OIDC 端點的 IAM 身分提供者： 1. 開啟 IAM 主控台 1. 按一下**存取管理**下的**身分提供者** 1. 如果尚未建立，請按一下**新增提供者**按鈕來新增 GitHub Identity 提供者 1. 選取身分提供者的 **OpenID Connect** 類型 1. 在**提供者 URL** `https://token.actions.githubusercontent.com` 輸入方塊中輸入 1. **對象**輸入方塊`sts.amazonaws.com`的 Enter 1. 按一下**新增供應商**按鈕 1. **建立 IAM 政策** 建立具有此動作所需許可的 IAM 政策。如需詳細資訊，請參閱以下[所需的許可](#Service-Application-Observability-for-AWS-GitHub-Action-required-permissions)章節。 1. **建立 IAM 角色** 使用下列信任政策範本在 AWS 管理主控台中建立 IAM 角色 （例如 `AWS_IAM_ROLE_ARN`)。這可讓授權的 GitHub 儲存庫擔任該角色： ``` { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Federated": "arn:aws:iam:::oidc-provider/token.actions.githubusercontent.com" }, "Action": "sts:AssumeRoleWithWebIdentity", "Condition": { "StringEquals": { "token.actions.githubusercontent.com:aud": "sts.amazonaws.com" }, "StringLike": { "token.actions.githubusercontent.com:sub": "repo:/:ref:refs/heads/" } } } ] } ``` 取代範本中的下列預留位置： + `` - AWS 您的帳戶 ID + `` - 您的 GitHub 組織名稱 + `` - 您的儲存庫名稱 + `` - 您的分支名稱 （例如主要） 1. **連接 IAM 政策** 在角色的許可索引標籤中，連接您在步驟 2 中建立的 IAM 政策。 如需使用 設定 OIDC 的詳細資訊 AWS，請參閱 [configure-aws-credentials OIDC Quick Start Guide](https://github.com/aws-actions/configure-aws-credentials/tree/main?tab=readme-ov-file#quick-start-oidc-recommended)。 #### 步驟 2：設定秘密並新增工作流程 1. **設定儲存庫秘密** 前往您的儲存庫 → 設定 → 秘密和變數 → 動作。 + 建立名為 的新儲存庫秘密，並將其值`AWS_IAM_ROLE_ARN`設定為您在步驟 1 中建立之 IAM 角色的 ARN。 + （選用） 建立名為 的儲存庫變數`AWS_REGION`來指定您的 AWS 區域 (`us-east-1`若未設定，預設為 ) 1. **新增工作流程檔案** 以下是示範將此動作與 Amazon Bedrock 模型搭配使用的範例工作流程。在 GitHub 儲存庫目錄 中，從此範本建立應用程式可觀測性調查工作流程`.github/workflows`。 ``` name: Application observability for AWS on: issue_comment: types: [created, edited] issues: types: [opened, assigned, edited] jobs: awsapm-investigation: if: | (github.event_name == 'issue_comment' && contains(github.event.comment.body, '@awsapm')) || (github.event_name == 'issues' && (contains(github.event.issue.body, '@awsapm') || contains(github.event.issue.title, '@awsapm'))) runs-on: ubuntu-latest permissions: contents: write # To create branches for PRs pull-requests: write # To post comments on PRs issues: write # To post comments on issues id-token: write # Required for AWS OIDC authentication steps: - name: Checkout repository uses: actions/checkout@v4 - name: Configure AWS credentials uses: aws-actions/configure-aws-credentials@v4 with: role-to-assume: ${{ secrets.AWS_IAM_ROLE_ARN }} aws-region: ${{ vars.AWS_REGION || 'us-east-1' }} # Step 1: Prepare AWS MCP configuration and investigation prompt - name: Prepare Investigation Context id: prepare uses: aws-actions/application-observability-for-aws@v1 with: bot_name: "@awsapm" cli_tool: "claude_code" # Step 2: Execute investigation with Claude Code - name: Run Claude Investigation id: claude uses: anthropics/claude-code-base-action@beta with: use_bedrock: "true" # Set to any Bedrock Model ID model: "us.anthropic.claude-sonnet-4-5-20250929-v1:0" prompt_file: ${{ steps.prepare.outputs.prompt_file }} mcp_config: ${{ steps.prepare.outputs.mcp_config_file }} allowed_tools: ${{ steps.prepare.outputs.allowed_tools }} # Step 3: Post results back to GitHub issue/PR (reuse the same action) - name: Post Investigation Results if: always() uses: aws-actions/application-observability-for-aws@v1 with: cli_tool: "claude_code" comment_id: ${{ steps.prepare.outputs.awsapm_comment_id }} output_file: ${{ steps.claude.outputs.execution_file }} output_status: ${{ steps.claude.outputs.conclusion }} ``` **組態備註：** + 在問題或評論中`@awsapm`提及 時，此工作流程會自動觸發 + 工作流程使用上一個步驟中設定的`AWS_IAM_ROLE_ARN`秘密 + 更新步驟 2 中的模型參數，以指定您偏好的 Amazon Bedrock 模型 ID + 您可以在 bot\$1name 參數中自訂機器人名稱 （例如 `@awsapm-prod`、`@awsapm-staging`)，以支援不同的環境 #### 步驟 3：開始使用 動作 設定工作流程後，請在任何 GitHub 問題`@awsapm`中提及 ，以觸發 AI 支援的調查。動作會分析您的請求、存取即時遙測資料，並自動提供建議或實作修正。 **範例使用案例：** 1. 調查效能問題並發佈和修正： `@awsapm, can you help me investigate availability issues in my appointment service?` ![\[alt text not found\]](http://docs.aws.amazon.com/zh_tw/AmazonCloudWatch/latest/monitoring/images/github-availability-issue-investigate.png) `@awsapm, can you post a fix?` ![\[alt text not found\]](http://docs.aws.amazon.com/zh_tw/AmazonCloudWatch/latest/monitoring/images/github-availability-issue-pr-fix.png) 1. 啟用檢測： `@awsapm, please enable Application Signals for lambda-audit-service and create a PR with the required changes.` 1. 查詢遙測資料： `@awsapm, how many GenAI tokens have been consumed by my services in the past 24 hours?` **接下來會發生什麼：** 1. 工作流程會偵測`@awsapm`提及項目並觸發調查 1. AI 代理器會透過設定的 MCP 伺服器存取您的即時 AWS 遙測資料 1. 代理程式會分析問題，並： + 直接在問題中發佈問題清單和建議 + 建立具有程式碼變更的提取請求 （用於檢測或修正） 1. 您可以使用後續問題再次提及 @awsapm，來檢閱結果並繼續對話 ## 安全 此動作透過嚴格的存取控制、以 OIDC 為基礎的 AWS 身分驗證，以及內建的保護來防範提示注入攻擊，以排定安全性的優先順序。只有具有寫入存取權或更高層級的使用者才能觸發 動作，而且所有操作都會範圍限定在特定儲存庫。 如需詳細的安全性資訊，包括： + 存取控制和許可要求 + AWS IAM 許可和 OIDC 組態 + 提示注入風險和緩解措施 + 安全最佳實務 請參閱 [安全文件](https://github.com/aws-actions/application-observability-for-aws/blob/main/docs/security.md)。 ## Configuration ### 所需的許可 GitHub Actions 擔任的 IAM 角色必須具有下列許可。 **注意**：`bedrock:InvokeModelWithResponseStream`只有在您使用 Amazon Bedrock 模型時才需要 `bedrock:InvokeModel`和 ``` { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "application-signals:ListServices", "application-signals:GetService", "application-signals:ListServiceOperations", "application-signals:ListServiceLevelObjectives", "application-signals:GetServiceLevelObjective", "application-signals:ListAuditFindings", "cloudwatch:DescribeAlarms", "cloudwatch:DescribeAlarmHistory", "cloudwatch:ListMetrics", "cloudwatch:GetMetricData", "cloudwatch:GetMetricStatistics", "logs:DescribeLogGroups", "logs:DescribeQueryDefinitions", "logs:ListLogAnomalyDetectors", "logs:ListAnomalies", "logs:StartQuery", "logs:StopQuery", "logs:GetQueryResults", "logs:FilterLogEvents", "xray:GetTraceSummaries", "xray:GetTraceSegmentDestination", "xray:BatchGetTraces", "xray:ListRetrievedTraces", "xray:StartTraceRetrieval", "servicequotas:GetServiceQuota", "synthetics:GetCanary", "synthetics:GetCanaryRuns", "s3:GetObject", "s3:ListBucket", "iam:GetRole", "iam:ListAttachedRolePolicies", "iam:GetPolicy", "iam:GetPolicyVersion", "bedrock:InvokeModel", "bedrock:InvokeModelWithResponseStream" ], "Resource": "*" } ] } ``` ## 文件 如需詳細資訊，請參閱： + [CloudWatch Application Signals 文件](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Application-Monitoring-Intro.html) - 了解 CloudWatch Application Signals 功能 + [AWS 動作公開文件的應用程式可觀測性](https://github.com/marketplace/actions/application-observability-for-aws) - 詳細指南和教學課程 # 範例：使用 Application Signals 來解決操作運作狀態問題 下列案例提供如何使用 Application Signals 來監控服務及識別服務品質問題的範例。深入分析以找出潛在的根本原因，並採取行動來解決問題。此範例著重於由數個呼叫 DynamoDB AWS 服務 等微服務組成的寵物診所應用程式。 Jane 是 DevOps 團隊的一員，負責監管寵物診所應用程式的運作狀況。Jane 的團隊致力於確保應用程式具有高可用性和高回應速度。他們使用[服務水準目標 (SLO)](CloudWatch-ServiceLevelObjectives.md)，根據這些業務承諾來衡量應用程式效能。她收到有關數個不良服務水準指標 (SLI) 的警示。她開啟 CloudWatch 主控台並導覽至「服務」頁面，在此頁面上看到多個服務處於不佳狀態。 ![\[SLI 狀態不佳的服務\]](http://docs.aws.amazon.com/zh_tw/AmazonCloudWatch/latest/monitoring/images/example-scenario-services-page.jpg) 在頁面頂端，Jane 看到 `visits-service` 是故障率最高的服務。她選取圖表中的連結，開啟該服務的「服務」詳細資訊頁面。她看到服務操作資料表中有狀態不佳的操作。她選取此操作，並在「磁碟區與可用性」圖表中看到有定期呼叫量尖峰，這似乎與可用性下降相關。 ![\[服務操作量和可用性\]](http://docs.aws.amazon.com/zh_tw/AmazonCloudWatch/latest/monitoring/images/example-scenario-unhealthy-operation.png) 為了更深入了解服務可用性的下降，Jane 會在圖表中選取其中一個可用性資料點。隨即開啟一個選單，其中顯示與所選資料點相關的 X-Ray 追蹤。她看到有多個包含故障的追蹤。 ![\[服務可用性和相關追蹤\]](http://docs.aws.amazon.com/zh_tw/AmazonCloudWatch/latest/monitoring/images/example-scenario-correlated-traces.jpg) Jane 會選取其中一個具有錯誤狀態的相關追蹤，這會開啟所選追蹤的「X-Ray 追蹤」詳細資訊頁面。Jane 向下捲動至「區段時間軸」部分，並遵循呼叫路徑，直到看到對 DynamoDB 資料表的呼叫傳回錯誤為止。她選取 DynamoDB 區段，並導覽至右側抽屜的「例外狀況」索引標籤。 ![\[具有 DynamoDB 錯誤的追蹤區段\]](http://docs.aws.amazon.com/zh_tw/AmazonCloudWatch/latest/monitoring/images/example-scenario-DDB-segment.jpg) Jane 發現 DynamoDB 資源設定錯誤，導致客戶請求尖峰期間發生錯誤。DynamoDB 資料表的佈建輸送量水平會定期超出範圍，導致服務可用性問題和運作狀態不佳的 SLI。根據此資訊，她的團隊能夠設定更高層級的佈建輸送量，並確保應用程式的高可用性。 # 範例：使用 Application Signals 對與 Amazon Bedrock 模型互動的生成式 AI 應用程式進行疑難排解 您可以使用 Application Signals 來疑難排解與 Amazon Bedrock 模型互動的生成式 AI 應用程式。Application Signals 可提供即用型遙測資料，讓您更深入了解應用程式與 LLM 模型之間的互動，從而簡化此流程。它有助於解決關鍵使用案例，例如： + 模型組態問題 + 模型使用成本 + 模型延遲 + 模型回應產生停止的原因 透過 LLM/GenAI 可觀測性[啟用 Application Signals](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Application-Signals-Enable.html)，可讓您即時檢視應用程式與 Amazon Bedrock 服務的互動。Application Signals 會自動產生並關聯 Amazon Bedrock API 呼叫的效能指標和追蹤。 Application Signals 目前支援來自 Amazon Bedrock的以下 LLM 模型。 + AI21 Jamba + Amazon Titan + Anthropic Claude + Cohere Command + Meta Llama + Mistral AI + Nova ## 精細指標與追蹤 對於每個 Amazon Bedrock API 呼叫，Application Signals 會在資源層級產生詳細的效能指標，包括： + 模型 ID + 防護機制 ID + 知識庫 ID + Bedrock 代理程式 ID 此外，同一層級的相互關聯追蹤範圍有助於提供請求執行和相依項的全面視圖。 ![\[使用 Application Signals 的效能指標。\]](http://docs.aws.amazon.com/zh_tw/AmazonCloudWatch/latest/monitoring/images/AppSignalsAIExample.png) ## OpenTelemetry GenAI 屬性支援 Application Signals 會為具有 OpenTelemetry 語意慣例的 Amazon Bedrock API 呼叫產生下列 GenAI 屬性。這些屬性有助於分析模型使用情況、成本和回應品質；可以透過 [Transaction Search](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Transaction-Search.html) 利用該等屬性，以取得更深入的見解。 + gen\$1ai.system + gen\$1ai.request.model + gen\$1ai.request.max\$1tokens + gen\$1ai.request.temperature + gen\$1ai.request.top\$1p + gen\$1ai.usage.input\$1tokens + gen\$1ai.usage.output\$1tokens + gen\$1ai.response.finish\$1reasons ![\[使用 Application Signals 的 GenAI 屬性。\]](http://docs.aws.amazon.com/zh_tw/AmazonCloudWatch/latest/monitoring/images/AppSignalsAIExample_1.png) 例如，您可以利用 Transaction Search 的分析功能，比較不同 LLM 模型在相同提示詞下的權杖使用情況與成本，從而選取有成本效益的模型。 ![\[使用 Application Signals 的 GenAI 屬性。\]](http://docs.aws.amazon.com/zh_tw/AmazonCloudWatch/latest/monitoring/images/AppSignalsAIExample_2.png) 如需詳細資訊，請參閱[改善 CloudWatch Application Signals 的可 Amazon Bedrock 觀測性](https://aws.amazon.com/blogs/mt/improve-amazon-bedrock-observability-with-amazon-cloudwatch-appsignals/)。