# 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、クライアントページに関する詳細が表示されます。
+ アプリケーションマップをフィルタリングしてズームすると、アプリケーションのトポロジの一部に焦点を合わせたり、マップ全体を表示しやすくなります。フィルターテキストボックスから 1 つ以上のプロパティを選択して、フィルターを作成します。各プロパティを選択すると、フィルター条件が表示されます。フィルターテキストボックスの下に、すべてのフィルターが表示されます。**[フィルターのクリア]** を選択すると、いつでもフィルターを削除できます。
+ 単一の統合アプリケーションマップで複数の AWS アカウントにわたるサービスをモニタリングします。異なるアカウントのサービスはアカウント情報によって明確に識別され、分散アプリケーションの統一されたオブザーバビリティが可能になります。
+ アプリケーションにまだ計測されていないサービスを特定します。Application Signals は、まだ計測されていないサービスを自動的に検出して表示するため、オブザーバビリティのカバー範囲を完全に網羅できます。未計測のサービスはマップ上で視覚的に区別されるため、計測作業の優先順位付けに役立ちます。
+ サービスをグループ化およびフィルタリングし、ワークフローに一致するカスタマイズされたビューを作成します。この整理機能は、最も頻繁に使用するサービスをすばやく見つけてアクセスするのに役立ちます。
+ フィルタリングおよびグループ化されたビューを保存し、頻繁に使用する設定にすばやく戻れるようにする
## アプリケーションマップについて詳しく見る
アプリケーションマップにアクセスすると、デフォルトで**関連サービス**別にグループ化されたサービスが表示されます。関連サービスでのサービスのグループ化は、その依存関係に基づいています。例えば、サービス A がサービス B を呼び出し、サービス B がサービス C を呼び出す場合、それらはサービス A の下にグループ化されます。各グループ内のすべてのサービスの SLI ヘルス、メトリクス、およびサービス数を表示できます。
![\[関連サービス別にグループ化された CloudWatch のデフォルトのアプリケーションマップ。\]](http://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/images/explore-application-map-overview.png)
各ノードの種類とノード間のエッジ (接続) の詳細を見るには、次のタブをクリックします。
### 動的グループ化とフィルタリング
**[グループ化の条件]** ドロップダウンをクリックすると、さまざまなグループ化オプションを使用できます。デフォルトでは、アプリケーションマップは次の 2 つのグループ化を提供します。
+ **関連サービス** – 依存関係に基づいてサービスをグループ化する
+ **環境** – 環境別にサービスをグループ化する
独自のカスタムグループ化を定義する場合は、**[グループの管理]** をクリックしてカスタムグループを定義し、サービスにタグを付けるか、グループキーで OTEL リソース属性を追加します。
**注記**
OTEL リソース属性によるグループ化を有効にするには、CloudWatch エージェントバージョンが v1.300056.0 以降である必要があります。
![\[カスタムグループ化パネルを作成する\]](http://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/images/explore-application-map-create-custom-grouping.png)
Application Signals のデフォルトのグループ化では、ダウンストリームの依存関係に基づいてサービスが自動的に整理されます。システムはサービス依存関係グラフを分析し、ルートノード (アップストリーム依存関係のないサービス) がグループ名になるグループを作成します。このルートサービスに直接的または間接的に依存するすべてのサービスは、自動的にグループに含められます。例えば、サービス A がサービス B を呼び出し、サービス B がサービス C を呼び出す場合、依存関係チェーンのルートであるサービス A をグループ名として、3 つのサービスがすべてがグループ化されます。この自動グループ化メカニズムは、実際のランタイムインタラクションと依存関係に基づいて関連サービスを可視化および管理するための自然な方法を提供します。
### アクションとインサイトをグループ化する
各グループに対して、以下のアクションを実行できます。
+ **[詳細を表示]** をクリックすると、グループのメトリクスグラフ、直近 2 つの変更イベント、および最終デプロイ時刻を表示できます。
![\[アプリケーションマップでグループのドロワーをさらに表示する\]](http://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/images/explore-application-map-view-more.png)
+ **[ダッシュボードの表示]** をクリックすると、グループのメトリクスダッシュボード、変更イベントテーブル、およびサービスリストを表示できます。
![\[グループのアプリケーションダッシュボードを表示する\]](http://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/images/explore-application-map-team-overview.png)
![\[グループのアプリケーションダッシュボード (メトリクスグラフ付き) を表示する\]](http://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/images/explore-application-map-team-overview-2.png)
左側のバーにある **[グループ化とフィルタリング]** を使用すると、デプロイ時刻、SLI ヘルスステータス、またはコンピューティングプラットフォームの種類を含むサービスを持つグループをフィルタリングできます。
![\[アプリケーションダッシュボードでサービスをグループ化およびフィルタリングする\]](http://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/images/explore-application-map-grouping-filter.png)
アカウントでフィルタリングして、クロスアカウントのオブザーバビリティ設定で特定の AWS アカウントのサービスを表示することもできます。
![\[アプリケーションダッシュボードでサービスをアカウント別にフィルタリングする\]](http://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/images/explore-application-map-account-filter.png)
**[検索およびフィルター]** バーを使用すると、名前あるいは特定のサービス環境または依存関係を含む検索グループでグループを検索できます。アカウント ID でフィルタリングすると、特定のアカウントのサービスに焦点を当てることができます。
![\[アプリケーションマップでサービスを検索およびフィルタリングする\]](http://docs.aws.amazon.com/ja_jp/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 クラスターに追加します。1 つの Amazon EKS クラスターで複数のサービスが実行されている場合、それらのサービスはすべて同じカスタムグループキーでタグ付けされます。例えば、Amazon EKS クラスター A でサービス 1、サービス 2、およびサービス 3 が実行されている場合、キー *Team X* を持つ AWS タグをクラスターに追加すると、3 つのサービスすべてが *Team X* に追加されます。特定のサービスのみを *Team 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` を追加します。完全な例については、「[Adding `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 に追加します。完全な例については、「[Enable on 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/ja_jp/AmazonCloudWatch/latest/monitoring/images/View-services-groups.png)
未計測のサービスは、特徴的な視覚的インジケータ (破線の境界線や異なる色など) とともに表示され、計測されたサービスと区別できるようになっています。未計測のサービスノードにカーソルを合わせると、計測に関するガイダンスとセットアップドキュメントへのリンクが表示されます。
![\[アプリケーションマップ上の計測されていないサービスでフィルタリングする\]](http://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/images/explore-application-map-uninstrumented-filter.png)
すべての Canary、RUM クライアント、および AWS サービスノードはデフォルトで折りたたまれます。このグループ内のサービスがこのグループに含まれていないサービスを呼び出す場合、それらもデフォルトで折りたたまれます。
![\[Canary ノードがアプリケーションマップで 1 つのグループに折りたたまれています\]](http://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/images/explore-application-map-canary-collapse.png)
マップが大きすぎて効果的に調査できない場合は、ネストされたグループ化を適用して調査範囲を絞り込むことができます。例えば、**ビジネスユニット**別にサービスをグループ化した後でも、グループ内のサービスが多すぎる場合は、[グループ化の条件] ドロップダウンを使用して **[チーム]** を選択し、ネストされたグループ化構造を作成します。
![\[アプリケーションマップのネストされたグループ化\]](http://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/images/explore-application-map-nested-grouping.png)
### サービスインサイトおよび詳細
このページでは、検索バーの横にある **[表示の保存]** をクリックしてビューを保存することもできます。これにより、次回同じグループ化とフィルタリングを再度適用する必要がなくなります。
![\[グループ化設定を保存する\]](http://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/images/explore-application-map-save-view.png)
サービスノードで **[詳細を表示]** をクリックすると、サービス監査、変更イベント、SLI ヘルス、およびメトリクスグラフを表示できます。
![\[CloudWatch アプリケーションマップサービスインサイト。\]](http://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/images/explore-application-map-service-view-more.png)
サービスオペレーションやその他のサービス詳細を表示する場合は、**[ダッシュボードの表示]** をクリックして [サービスの概要] ページに移動します。
![\[CloudWatch アプリケーションマップサービスの概要。\]](http://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/images/explore-application-map-service-overview.png)
あるいは、Edge をクリックして、サービスの特定の依存関係呼び出しのメトリクスを表示することもできます。
![\[CloudWatch アプリケーションマップノードエッジドロワー\]](http://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/images/explore-application-map-edge.png)
### 変更イベント
Application Signals の CloudTrail イベントの自動処理機能を使用して、アプリケーション全体の変更イベントを追跡します。サービスとその依存関係の設定イベントとデプロイイベントをモニタリングし、運用分析とトラブルシューティングのコンテキストを即座に提供します。変更イベント検出は、CloudWatch コンソールまたは StartDiscovery API を介したサービス検出の有効化とともに有効になります。EKS サービスの場合、デプロイ検出では、EKS サービスが Application Signals 計測 SDK で計測されている必要があります。Application Signals は、デプロイ時刻とパフォーマンスの変化を自動的に関連付けるため、最近のデプロイがサービスの問題の原因になっているかどうかをすばやく特定できます。追加の設定やセットアップを必要とせずに、サービス全体の変更イベント履歴と影響を表示します。
### 監査結果
Application Signals の監査結果を通じて重要なインサイトを見つけます。このサービスは、アプリケーションを分析して重大な観察結果と潜在的な問題を報告し、根本原因の分析を簡素化します。これらの自動検出結果により、関連するトレースが統合されるため、複数回クリックして移動する必要がなくなります。監査システムは、チームが問題とその基になる原因をすばやく特定し、問題解決を迅速化します。
Amazon Bedrock 上で実行されているサービスでは、Application Signals は GenAI トークンの使用パターンを自動的にモニタリングします。監査システムは、入力トークンと出力トークンの消費量の異常を検出し、現在の使用状況を過去のベースラインに照らして比較します。トークンの使用が通常のパターンを超えると、監査の検出結果は、トークンの消費傾向、コストへの影響、最適化の推奨事項など、詳細な分析を提供します。これにより、チームは非効率的なプロンプト、予期しないトークンの急増、および GenAI 運用コストを削減する機会を特定できます。
### アプリケーションマップでのクロスアカウントオブザーバビリティ
Application Signals はクロスアカウントオブザーバビリティをサポートしているため、複数の AWS アカウントに分散されたサービスを 1 つの統合アプリケーションマップでモニタリングおよび可視化できます。この機能は、AWS ベストプラクティスに従ったマルチアカウントアーキテクチャを備えた組織にとって不可欠です。
**主な機能:**
+ *統合ビュー*: 複数の AWS アカウントのサービスが 1 つのアプリケーションマップに表示されるため、分散アプリケーションアーキテクチャの全体像を把握できます。
+ *アカウント識別*: 各サービスノードにはアカウント ID とリージョンが明確に表示されるため、サービスの所有権と場所を簡単に識別できます。
+ *一元的なモニタリング*: 1 つのモニタリングアカウントから、接続されたすべてのアカウントのサービスの正常性、パフォーマンス、および SLO ステータスをモニタリングできます。
+ *クロスアカウントフィルタリング*: アカウント ID でサービスをフィルタリングしてグループ化し、特定のアカウントに焦点を絞ったり、クロスアカウントインタラクションを表示したりできます。
**仕組み:**
Application Signals は、AWS Organizations とクロスアカウント共有を使用して、複数のアカウントにわたるオブザーバビリティを実現します。クロスアカウントオブザーバビリティを設定するには、「[CloudWatch のクロスアカウントオブザーバビリティ](CloudWatch-Unified-Cross-Account.md)」を参照してください。
------
#### [ View your application services ]
**サービス (計測済み)**
アプリケーションサービスと、それらの SLO およびサービスレベル指標 (SLI) のステータスは、**アプリケーションマップ**で確認できます。サービスの SLO が作成されていない場合は、サービスノードの下にある **[SLO の作成]** ボタンをクリックします。
**アプリケーションマップ**には、すべてのサービスが表示されます。また、次の図に示すように、サービスを使用している顧客および Canary、ならびにそのサービスが呼び出す依存関係も表示されます。
![\[正常なサービスと異常なサービスを表示する CloudWatch アプリケーションマップ。\]](http://docs.aws.amazon.com/ja_jp/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 アプリケーションマップサービスエッジ\]](http://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/images/App-signals-service-edge.png)
エッジノードを選択すると、ペインが開き、次のような詳細なサービス情報が表示されます。
+ 合計リクエスト数、レイテンシー、エラー率、および障害率
+ 上位パス (障害率別)
+ 上位パス (レイテンシー別)
+ 上位パス (エラー率別)
**サービス (未計測)**
未計測のサービスは、Application Signals で設定されていない場合でも、アプリケーションマップに表示されます。これらのサービスは、アプリケーション名とタグを使用して Resource Explorer を活用することで自動的に検出されます。システムは AWS アカウント内の最大 3,000 個のリソースを自動的に検出できます。
未計測のサービスノードを選択すると、ペインが開き、以下が表示されます。
+ サービス名と識別情報
+ アカウント ID とサービスが検出されたリージョン
+ 計測ステータスとガイダンス
+ セットアップ手順を提供する Call to Action ボタン [Application Signals を有効にする]
+ コンピューティングプラットフォームの種類 (検出可能な場合)
未計測のサービスは、以下の場合に役立ちます。
+ オブザーバビリティのカバー範囲のギャップを特定する
+ アーキテクチャ内の位置に基づいて、次に計測するサービスを優先順位付けする
+ 完全な計測を行う前でも完全なアプリケーショントポロジを把握する
+ 組織全体での計測ロールアウトを計画する
**注記**
未計測のサービスでは、メトリクスやトレースをアクティブに送信しないため、限られたテレメトリデータが表示されます。
![\[CloudWatch アプリケーションマップ計測フィルター\]](http://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/images/explore-application-map-instrumentation-filter.png)
------
#### [ View dependencies ]
アプリケーションの依存関係は、それを呼び出すサービスに接続されたアプリケーションマップに表示されます。
依存関係ノードを選択すると、エラー率と障害率のほか、リクエスト、可用性、レイテンシー、障害率、およびエラー率のメトリクスグラフを含むペインが開きます。
依存関係ノードがサービスまたはリソースの場合、ペインにはリクエストされた時間範囲の変更イベントが表示されます。
![\[展開可能な AWS サービス依存関係ノードを表示する CloudWatch アプリケーションマップ。\]](http://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/images/service-map-dependency.png)
------
#### [ View clients ]
CloudWatch RUM ウェブクライアントの [X-Ray トレースを有効にする](CloudWatch-RUM-get-started-create-app-monitor.md)と、そのクライアントは、呼び出すサービスに接続されたアプリケーションマップに表示されます。
クライアントノードを選択すると、次のような詳細なクライアント情報が表示されているペインが開きます。
+ ページロード、平均ロード時間、エラー、および平均ウェブバイタルのメトリクス
+ エラーの内訳を示すグラフ
+ CloudWatch RUM でクライアントの詳細を表示するためのリンク
![\[展開可能なクライアントノードを表示する CloudWatch アプリケーションマップ。\]](http://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/images/service-map-client.png)
**[ダッシュボードの表示]** を選択して、Canary の詳細を開きます。
------
#### [ View synthetics canaries ]
アプリケーションマップで Canary を表示するには、CloudWatch Synthetics Canary の [X-Ray トレースを有効にします](CloudWatch-RUM-get-started-create-app-monitor.md)。有効にすると、Canary は呼び出されたサービスに接続された状態でアプリケーションマップに表示されます。
システムは、デフォルトで Canary を 1 つの展開可能なアイコンにグループ化します。詳細な Canary 情報ペインには、メトリクス、トレース、およびステータス情報が表示されます。
次の画像に示すように、Canary ノードをクリックして詳細な Canary 情報を表示するペインを開きます。
![\[展開可能な Synthetics Canary ノードを表示する CloudWatch アプリケーションマップ。\]](http://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/images/service-map-canary.png)
**[ダッシュボードの表示]** を選択して、Canary の詳細を開きます。
------