使用 CloudWatch 應用程式地圖檢視您的應用程式拓撲並監控操作狀態

注意

CloudWatch 應用程式地圖取代了 Service Map。若要查看以 AWS X-Ray 追蹤為基礎的應用程式映射，請開啟 X-Ray 追蹤映射。在 CloudWatch 主控台的左側導覽窗格中，選擇 X-Ray 區段下的追蹤地圖。

啟用 Application Signals 的應用程式後，應用程式地圖會顯示代表您的群組的節點。然後，您可以深入分析這些群組，以檢視您的服務及其相依項。使用應用程式地圖來檢視應用程式用戶端的拓撲、Synthetics Canary、服務和相依項，以及監控操作狀態。若要檢視應用程式地圖，請開啟 CloudWatch 主控台，然後在左側導覽窗格的 Application Signals 區段下選擇應用程式地圖。

在啟用 Application Signals 的應用程式之後，請使用應用程式地圖，可更輕鬆地監控應用程式的操作狀態：

檢視用戶端、canary、服務和相依性節點之間的連線，以協助您了解應用程式拓撲和執行流程。如果您的服務營運商不是您的開發團隊，這將特別有用。
查看哪些服務符合或不符合您的服務水準目標 (SLO)。當服務不符合您的 SLO 時，您可以快速識別下游服務或相依性是否可能導致問題或影響多個上游服務。
選取個別用戶端、Synthetics Canary、服務或相依項節點，以查看相關指標。服務詳細資訊頁面將顯示有關操作、相依項、Synthetics Canary 和用戶端頁面的詳細資訊。
篩選和縮放應用程式地圖，以便更輕鬆地專注於部分應用程式拓撲，或查看整個地圖。從篩選文字方塊中選擇一個或多個屬性來建立篩選條件。當您選擇每個屬性時，系統會引導您完成篩選條件。您將在篩選文字方塊下方看到完整的篩選條件。可隨時選擇清除篩選條件以移除篩選條件。
在單一統一應用程式映射中監控跨多個 AWS 帳戶的服務。來自不同帳戶的服務會以帳戶資訊清楚識別，為分散式應用程式提供統一的可觀測性。
識別尚未在您的應用程式中檢測的服務。Application Signals 會自動偵測並顯示尚未經過檢測的服務，協助您實現完整的可觀測性涵蓋範圍。未檢測的服務會在地圖上以視覺化方式區分，以協助您排定檢測工作的優先順序。
對服務進行分組和篩選，以建立符合您工作流程的自訂檢視。此組織可協助您快速尋找和存取最常用的服務
儲存經過篩選和分組的檢視，以快速返回常用的組態

探索應用程式地圖

當您造訪應用程式地圖時，預設會顯示依相關服務分組的服務。相關服務將依相依項對服務分組。例如，若服務 A 呼叫服務 B，而服務 B 又呼叫服務 C，則這三者會被歸類在服務 A 之下。您可以檢視每個群組中所有服務的 SLI 運作狀態、指標及服務數量。

動態分組和篩選

您可以按一下分組依據下拉式清單，使用不同的分組選項。依預設，應用程式地圖提供 2 個分組選項：

相關服務：依服務相依項對服務分組
環境：依環境對服務分組

如果想要定義自己的自訂群組，請按一下管理群組定義自訂群組，然後使用群組金鑰標記服務或新增 OTEL 資源屬性。

注意

若要透過 OTEL 資源屬性啟用分組，CloudWatch 代理程式版本必須為 v1.300056.0 或更新版本。

Application Signals 中的預設分組機制會根據服務的下游相依項自動對服務分組。系統會分析服務相依項圖表，並建立根節點 (沒有上游相依項的服務) 成為群組名稱的群組。所有依賴此根服務的服務 (無論直接或間接) 都會自動包含在群組中。例如，若服務 A 呼叫服務 B，而服務 B 又呼叫服務 C，這三個服務將被歸為一組，並以服務 A 作為群組名稱，因為它是相依項鏈的根節點。此自動分組機制提供自然的方式，能依據服務間實際的執行時期互動與相依項，直觀呈現並管理相關服務。

群組動作與洞見

對於每個群組，可以執行下列動作：

按一下檢視更多以檢視指標圖表、最後兩個變更事件，以及群組的上次部署時間
按一下檢視儀表板以檢視群組的指標儀表板、變更事件表和服務清單

您可以使用左側列上的群組和篩選條件來篩選具有部署時間、SLI 運作狀態或運算平台類型之服務的群組。

您也可以依帳戶進行篩選，以在跨帳戶可觀測性設定中檢視來自特定 AWS 帳戶的服務。

透過搜尋和篩選條件導覽列，可依名稱搜尋群組，或搜尋包含特定服務環境或相依項的群組。依帳戶 ID 篩選，以專注於來自特定帳戶的服務。

設定自訂群組

透過自訂分組功能，您可以根據業務需求和營運優先順序以邏輯方式對服務分組。藉助此功能，您可以檢視並儲存依特定需求排序的預設檢視，依據團隊所有權建立群組，並組建關鍵業務交易所需的服務群組。

建立自訂群組名稱 (您將在 UI 中看到的群組名稱) 和對應的群組金鑰名稱。從 Application Signals UI 或者利用 PutGroupingConfiguration 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。


...
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 上啟用。


{
  "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 的服務都會反白顯示，以便輕鬆辨識。

未檢測的服務會以獨特的視覺指標（例如虛線邊界或不同顏色）顯示，以區分它們與檢測的服務。將滑鼠游標暫留在未檢測的服務節點上，以查看檢測指引和設定文件的連結。

根據預設，所有 Canary、RUM 用戶端 AWS 和服務節點都會收合。如果此群組中的服務呼叫不屬於此群組的服務，則這些服務預設也會收合。

若您的地圖仍過於龐大而難以有效調查，可運用嵌套分組功能逐步縮小調查範圍。例如，在依業務單位對服務分組之後，如果群組中仍有太多服務，請透過「分組依據」下拉式清單選取團隊，建立巢狀分組結構。

服務洞察及詳細資訊

可在此頁面上按一下搜尋列旁的儲存檢視以儲存檢視，下次就不需要再次套用相同的分組和篩選設定。

按一下在服務節點中檢視更多，以檢視服務稽核、變更事件、SLI 運作狀態和指標圖表。

如果您想要檢視服務操作和其他服務詳細資訊，請按一下檢視儀表板以前往服務概觀頁面。

也可以按一下 Edge 來檢視服務特定相依項呼叫的指標。

變更事件

使用 Application Signals 自動處理 CloudTrail 事件，追蹤整個應用程式的變更事件。監控服務的組態和部署事件及其相依性，提供操作分析和故障診斷的立即內容。透過 CloudWatch 主控台或 StartDiscovery API 啟用服務探索，即可啟用變更事件偵測。對於 EKS 服務，部署偵測要求使用 Application Signals 檢測 SDK 檢測 EKS 服務。Application Signals 會自動將部署時間與效能變更建立關聯，協助快速判斷近期的部署是否導致了服務問題。檢視您服務之間的變更事件歷史記錄和影響，而不需要額外的組態或設定要求。

稽核調查結果

透過 Application Signals 的稽核調查結果，發掘關鍵洞察。此服務會分析您的應用程式，以報告重大觀察和潛在問題，簡化根本原因分析。這些自動化問題清單會合併相關追蹤，無需多次點選即可瀏覽。稽核系統可協助團隊快速識別問題及其根本原因，以更快的速度解決問題。

應用程式地圖上的跨帳戶可觀測性

Application Signals 支援跨帳戶可觀測性，可讓您監控和視覺化在單一統一應用程式映射中分佈於多個 AWS 帳戶的服務。此功能對於具有遵循 AWS 最佳實務的多帳戶架構的組織至關重要。

關鍵功能：

統一檢視：在單一應用程式映射中檢視來自多個 AWS 帳戶的服務，提供分散式應用程式架構的完整影像。
帳戶識別：每個服務節點都會清楚顯示其帳戶 ID 和區域，讓您輕鬆識別服務擁有權和位置。
集中監控：從單一監控帳戶監控所有連線帳戶的服務運作狀態、效能和 SLO 狀態。
跨帳戶篩選：依帳戶 ID 篩選和分組服務，以專注於特定帳戶或檢視跨帳戶互動。

運作方式：

Application Signals 使用 AWS Organizations 和跨帳戶共用來啟用多個帳戶的可觀測性。若要設定跨帳戶可觀測性，請參閱 CloudWatch 跨帳戶可觀測性功能。

選擇索引標籤，獲取有關探索它們之間各種節點和邊緣 (連接) 的資訊。

View your application services

服務（已檢測）

可以在 Application Map 中檢視應用程式服務及其 SLO 和服務層級指標 (SLI) 的狀態。如果尚未為服務建立 SLO，請選擇服務節點下方的建立 SLO 按鈕。

Application Map 會顯示所有服務。還會顯示取用服務的客戶和 Canary，以及您的服務呼叫的相依項，如下圖所示：

顯示運作狀態良好和不佳服務的 CloudWatch Application Map。

當您選取服務節點時，會開啟一個窗格，顯示詳細的服務資訊：

錯誤率和故障率總計。
healthy或unhealthy的 SLI 和 SLO 總數。
檢視 SLO 詳細資訊的選項。
Amazon EKS 中託管的服務的Cluster、Namespace和Workload，或是 Amazon ECS 或 Amazon EC2 中託管的服務環境。對於 Amazon EKS 託管的服務，請選擇任何連結以開啟 CloudWatch Container Insights。
帳戶 ID 和區域。
變更區段顯示最近的變更事件和上次部署時間。
操作稽核索引標籤顯示自動執行之稽核的調查結果和建議。
可用性、延遲、故障和錯誤的服務指標圖表。