# Application Signals を使用したアプリケーションの運用状態のモニタリング [CloudWatch コンソール](https://console.aws.amazon.com/cloudwatch/)内で Application Signals を使用すると、アプリケーションの運用状態のモニタリングとトラブルシューティングを行うことができます。 + **アプリケーションサービスのモニタリング** — 日常の運用状態のモニタリングの一環として、[[サービス]](Services-page.md) ページを使用すると、すべてのサービスの概要を確認できます。障害率またはレイテンシーが最も高いサービスを確認したり、どのサービスの[サービスレベル指標 (SLI)](CloudWatch-ServiceLevelObjectives.md) が正常でないかを確認したりできます。サービスを選択して [[サービスの詳細]](ServiceDetail.md) ページを開くと、詳細なメトリクス、サービスオペレーション、Synthetics Canary、およびクライアントリクエストを確認できます。これは、運用上の問題のトラブルシューティングと根本原因の特定に役立ちます。 + **アプリケーションのトポロジの検査** — [[アプリケーションマップ]](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 Canary](CloudWatch_Synthetics_Canaries.md) — Canary に X-Ray トレースを設定すると、Canary スクリプトからのサービスへの呼び出しがサービスに関連付けられ、[サービスの詳細] ページに表示されます。 + [CloudWatch リアルユーザーモニタリング (RUM)](CloudWatch-RUM.md) — CloudWatch RUM ウェブクライアントで X-Ray トレースが有効になっている場合、サービスへのリクエストが自動的に関連付けられ、[サービスの詳細] ページに表示されます。 + [AWS Service Catalog AppRegistry](https://docs.aws.amazon.com/servicecatalog/latest/arguide/intro-app-registry.html) — Application Signals は、アカウント内の AWS リソースを自動検出し、これらのリソースを AppRegistry で作成された論理アプリケーションにグループ化できるようにします。[サービス] ページに表示されるアプリケーション名は、サービスが実行されている基盤のコンピュートリソースに基づいています。 **注記** Application Signals は、ユーザーが選択した現在の時間フィルター内に出力されたメトリックとトレースに基づいて、サービスと運用を表示します。(デフォルトでは過去 3 時間です。) 現在の時間フィルター内にサービス、運用、依存関係、Synthetics Canary、またはクライアントページにアクティビティが発生しなかった場合は表示されません。 最大 1,000 個のサービスを表示できます。サービスとサービストポロジの検出は最大で 10 分遅れることがあります。サービスレベル指標 (SLI) の状態の評価は最大で 15 分遅れることがあります。 **注記** Application Signals コンソールは現在、30 日間の期間内で最大 1 日のみ選択することをサポートしています。 # サービスページで全体的なサービスアクティビティと運用状態を確認する サービスページでは、[Application Signals が有効になっている](CloudWatch-Application-Signals-Enable.md)サービスのリストを確認できます。また、オペレーションのメトリクスを表示して、どのサービスに異常なサービスレベル指標 (SLI) があるかをすばやく確認することもできます。ドリルダウンしてパフォーマンスの異常を探しながら、運用上の問題の根本原因を特定します。このページを表示するには、[CloudWatch コンソール](https://console.aws.amazon.com/cloudwatch/)を開き、左側のナビゲーションペインの **[Application Signals]** セクションで **[サービス]** を選択します。 未計測のサービスの場合、[サービスの概要] ページには、Application Signals 計測を有効にするための目立つ Call to Action とともに限定された情報が表示されます。 ## サービスの運用状態に関するメトリクスを詳しく見る [サービス] ページの上部には、サービス全体の運用状態のグラフ、上位のサービスとサービス依存関係を障害率別に表示した複数のテーブル、およびサービスのリストが表示されます。左側のサービスグラフには、現在のページレベルの時間フィルターで正常または異常なサービスレベル指標 (SLI) が発生したサービスの数の内訳が表示されます。SLI により、レイテンシー、可用性、その他の運用メトリクスをモニタリングできます。グラフの横にある 2 つのテーブルには、上位のサービスが障害率別に表示されています。いずれかのテーブルでサービス名を選択すると、[[サービスの詳細]](ServiceDetail.md) ページが開き、詳細なサービスオペレーション情報が表示されます。依存関係パスを選択して、詳細ページでサービス依存関係の詳細を表示します。 ページの右上でより長い期間のフィルターを選択した場合でも、過去 3 時間までの情報が両方のテーブルに表示されます。 動的サービスグループ化を使用する場合、運用状態に関するメトリクスは、各グループ内のすべてのサービスにわたって自動的に集計されたデータになります。これにより、以下が提供されます。 + サービスグループごとの統合障害率 + グループレベルの SLI ヘルスステータス + 問題のあるサービスクラスターの特定に役立つ集約されたパフォーマンスメトリクス + インシデント発生時に直ちに対応が必要なグループの迅速な特定 ![\[CloudWatch のサービス上部のグラフ\]](http://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/images/services-top-graphs.png) ## サービステーブルで運用状態を監視する サービステーブルには、Application Signals が有効になっているサービスのリストが表示されます。**[Application Signals を有効にする]** を選択してセットアップページを開き、サービスの設定を開始します。詳細については、「[Application Signals を有効にする](CloudWatch-Application-Signals-Enable.md)」を参照してください。 フィルターテキストボックスから 1 つまたは複数のプロパティを選択して、サービステーブルをフィルタリングすると、探しているものを見つけやすくなります。各プロパティを選択すると、フィルター条件が表示されます。フィルターテキストボックスの下に、すべてのフィルターが表示されます。**[フィルターのクリア]** を選択すると、いつでもテーブルのフィルターを削除できます。 高度なフィルタリングオプションを使用すると、次の操作が可能になります。 + サービスグループ (デフォルトグループ化とカスタムグループ化の両方) によるフィルタリング + 最近のデプロイアクティビティによるフィルタリング + プラットフォームによるフィルタリング + SLI ヘルスによるフィルタリング + (クロスアカウントオブザーバビリティ設定内の) アカウント ID によるフィルタリング + 計測ステータス (計測済みと未計測) によるフィルタリング + 環境によるフィルタリング + サービス状態のステータスによるフィルタリング ![\[CloudWatch のサービステーブル\]](http://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/images/services-table-healthy-updated.png) 未計測のサービスの場合、[サービスの概要] ページには、Application Signals 計測を有効にするための目立つ Call to Action とともに限定された情報が表示されます。未計測のサービスは、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/ja_jp/AmazonCloudWatch/latest/monitoring/images/services-unhealthy-sli.png) サービスの SLO が作成されていない場合は、**[SLI ステータス]** 列の **[SLO の作成]** ボタンを選択します。サービスに追加の SLO を作成するには、サービス名の横にあるオプションボタンを選択し、テーブルの右上にある **[SLO の作成]** を選択します。SLO を作成すると、どのサービスとオペレーションが正常に実行されていて、どれが異常かがひとめでわかります。詳細については、「[service level objectives (SLOs)](CloudWatch-ServiceLevelObjectives.md)」を参照してください。 ## サービスの概要 サービステーブルからサービスを選択すると、[サービスの概要] ページが開きます。このページでは、サービスの運用状態とパフォーマンスのメトリクスを包括的に表示します。[概要] には、以下の概要メトリクスが表示されます。 + 合計オペレーション数 + サービスの依存関係 + Canary モニタリングステータス + RUM クライアントデータ これらのメトリクスにより、サービスの現在の状態をすぐに把握できます。 一連のグラフを使用して、主要な運用パフォーマンス指標を経時的に可視化できます。傾向を分析し、サービス状態に影響する潜在的な問題を特定するには、時間フィルターを調整します。すべてのグラフは、選択した期間のデータを反映するように自動的に更新されます。 [監査の結果] セクションでは、サービスの動作における重大な問題が自動的に検出されて表示されるため、手動で調査する必要はありません。Application Signals は、アプリケーションを分析して重大な観察結果と潜在的な問題を報告し、根本原因の分析を簡素化します。これらの自動検出結果により、関連するトレースが統合されるため、複数回クリックして移動する必要がなくなります。監査システムは、チームが問題とその基になる原因をすばやく特定し、問題解決を迅速化します。 [変更イベント] セクションを使用すると、最近のデプロイまたは設定の変更がサービスの動作にどのように影響するかを特定できます。Application Signals は CloudTrail イベントを自動的に処理して、アプリケーション全体の変更イベントを追跡します。サービスとその依存関係の設定イベントとデプロイイベントをモニタリングし、運用分析とトラブルシューティングのコンテキストを即座に提供します。Application Signals は、デプロイ時刻とパフォーマンスの変化を自動的に関連付けるため、最近のデプロイがサービスの問題の原因になっているかどうかをすばやく特定できます。 ![\[サービスの概要\]](http://docs.aws.amazon.com/ja_jp/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]** のセクションで**[サービス]** をクリックします。 + **[サービス]**、**[上位サービス]**、[依存関係] のテーブルから、任意のサービスの名前を選択します。 **[schedule-visits]** では、サービス名の下にアカウント ラベルと ID が表示されます。 サービスの詳細ページは、次のタブで構成されています。 + [[概要]](#ServiceDetail-overview) - このタブは、オペレーション、依存関係、Synthetics、クライアントページの数など、特定のサービスの概要を表示するときに使用します。また、サービス全体に関する主要なメトリクス、上位のオペレーション、依存関係が表示されます。これらのメトリクスには、そのサービスのすべてのサービスオペレーションの、レイテンシー、障害、エラーに関する時系列データが含まれます。 + [[サービスオペレーション]](#ServiceDetail-operations) — このタブは、サービスが呼び出すオペレーションの一覧と、各オペレーションのヘルスを測定する主要メトリクスで構成された、実況グラフを表示するときに使用します。グラフ内のデータポイントを選択すると、そのデータポイントに関連付けられたトレース、ログ、メトリクスに関する情報を取得できます。 + [[依存関係]](#ServiceDetail-dependencies) — このタブは、サービスが呼び出す依存関係の一覧と、それら依存関係のメトリクスの一覧を表示するときに使用します。 + [[Synthetics Canary]](#ServiceDetail-canaries) — このタブは、サービスへのユーザーコールをシミュレートする Synthetics Canary の一覧と、それら Canary の主要なパフォーマンスメトリクスを表示するときに使用します。 + [[クライアントページ]](#ServiceDetail-clientpages) — このタブは、サービスを呼び出すクライアントページの一覧と、クライアントとアプリケーションとのインタラクションの質を測定する、メトリクスを表示するときに使用します。 + [関連メトリクス](#ServiceDetail-relatedmetrics) — このタブを使用して、サービス、そのオペレーションまたは依存関係の標準メトリクス、ランタイムメトリクス、カスタムメトリクスなどの関連メトリクスを関連付けます。 ## サービス概要の表示 サービス概要ページを使用すると、すべてのサービスオペレーションの、メトリクスの概要を 1 か所で表示できます。オペレーション、依存関係、クライアントページ、Synthetics Canary のすべてとアプリケーションとのインタラクションのパフォーマンスをチェックします。この情報があれば、問題を特定し、エラーをトラブルシューティングし、最適化の機会の見つけるために、どこに重点をおくべきかを判断するのに役立ちます。 **[サービスの詳細]** で任意のリンクをクリックし、特定のサービスに関連する情報を表示します。例えば、Amazon EKS でホストされているサービスの場合、サービスの詳細ページに **[クラスター]**、**[名前空間]**、**[ワークロード]** の情報が表示されます。Amazon ECS または Amazon EC2 でホストされているサービスの場合、[サービスの詳細] ページに **[環境]** の値が表示されます。 **[サービス]** の **[概要]** タブには、以下の項目の概要が表示されます。 + [オペレーション] – このタブは、サービスオペレーションのヘルスを確認するときに使用します。ヘルスの状態は、[サービスレベル目標](CloudWatch-ServiceLevelObjectives.md) (SLO) の一部として定義されているサービスレベル指標 (SLI) によって判定されます。 + [依存関係] — このタブは、アプリケーションによって呼び出されるサービスの上位の依存関係を障害率別に表示するときとサービスの依存関係の正常性を表示するときに使用します。ヘルスの状態は、サービスレベル目標 (SLO) の一部として定義されているサービスレベル指標 (SLI) によって判定されます。 + [Synthetics Canary] – このタブは、サービスに関連付けられたエンドポイントまたは API への、シミュレートされた呼び出しの結果と、失敗した Canary の数を表示するときに使用します。 + [クライアントページ] – このタブは、非同期 JavaScript と XML (AJAX) にエラーがあるクライアントが呼び出した、トップページを表示するときに使用します。 次の図に、サービスの概要を示します。 ![\[サービス概要のウィジェット\]](http://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/images/service-detail-widgets.png) **[概要]** タブには、すべてのサービスのうち、レイテンシーが最も高い上位 4 件の依存関係のグラフも表示されます。**p99**、**p90**、**p50** の各レイテンシーメトリクスを使用すると、次のように、どの依存関係がサービス全体のレイテンシーの一因になっているかをすばやく評価できます。 ![\[サービスオペレーションのレイテンシーを示したグラフ\]](http://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/images/service-detail-latency.png) 例えば、上記のグラフは**カスタマーサービス**の依存関係に対して行われたリクエストの 99% が完了までに約 4,950 ミリ秒かかっていることを示しています。他の依存関係はそこまで時間がかかっていません。 上位 4 つのサービスオペレーションをレイテンシー別に示したグラフでは、次のイメージのように、サービスごとにリクエスト量、可用性、障害率、エラー率が表示されます。 ![\[サービスオペレーションの量、可用性、障害率、エラー率を示したグラフ\]](http://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/images/service-detail-operations-graphs.png) **[サービスの詳細]** セクションには、**[アカウント ID]** と **[アカウントラベル]** を含むサービスの詳細が表示されます。 ## サービスオペレーションを表示する アプリケーションを計測すると、[Application Signals](CloudWatch-Application-Monitoring-Sections.md) は、アプリケーションが呼び出したすべてのサービスオペレーションを検出します。**[サービスオペレーション]** タブは、サービスオペレーションを含むテーブルと、選択したオペレーションのパフォーマンスを測定する、一連のメトリクスを表示するときに使用します。このメトリクスには、次に示すように、SLI のステータス、依存関係の数、レイテンシー、ボリューム、可用性が含まれています。 ![\[サービスオペレーションのテーブル\]](http://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/images/service-operations-table.png) フィルターテキストボックスから 1 つまたは複数のプロパティを選択してテーブルをフィルタリングすると、サービスオペレーションが見つけやすくなります。各プロパティを選択すると、フィルター条件が表示され、フィルターテキストボックスの下にフィルター全体が表示されます。**[フィルターのクリア]** を選択すると、いつでもテーブルのフィルターを削除できます。 オペレーションの SLI ステータスを選択すると、次のテーブルに示すように、異常な SLI へのリンクと、そのオペレーションのすべての SLO を確認するためのリンクがポップアップに表示されます。 ![\[サービスオペレーションの SLI ステータス\]](http://docs.aws.amazon.com/ja_jp/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/ja_jp/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/ja_jp/AmazonCloudWatch/latest/monitoring/images/service-operations-top-contributors.png) 上位の寄稿者には、次のメトリクスが含まれています。 + **[呼び出し量]** - 呼び出し量は、特定グループの、時間間隔あたりのリクエスト数を理解するときに使用します。 + **[可用性]** - 可用性は、特定のグループで、障害が検出されなかった時間の割合を把握するときに使用します。 + **[平均レイテンシー]** - レイテンシーは、調査対象のリクエストが実行された時期に応じて、特定のグループに対して特定の期間実行されたリクエストの、平均時間を確認するときに使用します。15 日以上前に行われたリクエストは、1 分間隔で評価されます。15～30 日前に行われたリクエストは、5 分間隔で評価されます。例えば、15 日前に障害の原因となったリクエストを調査している場合、呼び出し量メトリクスは 5 分間隔あたりのリクエスト数と等しくなります。 + **[エラー]** - 特定の時間間隔で測定されたグループあたりのエラーの数。 + **[障害]** - 特定の時間間隔におけるグループあたりの障害の数。 **Amazon EKS または Kubernetes を使用している上位の寄稿者** Amazon EKS または Kubernetes にデプロイされたアプリケーションの、上位の寄稿者の情報を使用して、**[ノード]**、**[ポッド]**、**[PodTemplateHash]** でグループ化された運用状態のメトリクスを確認します。各要因の定義は次のとおりです。 + **ポッド**は、ストレージとリソースを共有する 1 つ以上の Docker コンテナから成るグループです。Kubernetes プラットフォームにデプロイできる最小単位がポッドです。ポッド別にグループ化すると、エラーがポッド固有の制限に関連しているかどうかを確認できます。 + **ノード**は、ポッドを実行するサーバーです。ノード別にグループ化すると、エラーがノード固有の制限に関連しているかどうかを確認できます。 + **ポッドテンプレートハッシュ**は、特定のバージョンのデプロイを検出するために使用します。ポッドテンプレートハッシュでグループ化すると、エラーが特定のデプロイに関連しているかどうかを確認できます。 **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) で、インフラストラクチャのパフォーマンスメトリクスを、ポッドやノードなど特定のグループごとに表示します。クラスター、ノード、またはワークロードをリソース消費量別にソートして、エンドユーザーエクスペリエンスが影響を受ける前に異常をすばやく特定したり、プロアクティブにリスクを軽減したりできます。次のイメージに、これらのオプションを選択する方法を示します。 ![\[[上位の寄与要因] テーブル\]](http://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/images/service-operations-top-contributors-insights.png) **Container Insights** では、Amazon EKS コンテナや Amazon ECS コンテナに関するメトリクスのうち、上位の寄与要因のグループ化に固有のものを表示できます。例えば、EKS コンテナをポッド別にグループ化して上位の寄与要因を生成した場合、Container Insights にはポッドでフィルタリングされたメトリクスと統計が表示されます。 **Log Insights** では、次の手順を使用して、**[上位の寄与要因]** にメトリクスを生成したクエリを変更できます。 1. **[Log Insights に表示]** を選択します。**[Log Insights]** ページが開いて、自動的に生成されたクエリが表示されます。次の情報が含まれています。 + ログクラスターグループ名。 + CloudWatch で調査していたオペレーション。 + グラフで操作したオペレーションヘルスメトリクスの集計。 ログ結果は自動的にフィルタリングされて、サービスグラフ上のデータポイントを選択するまでの過去 5 分間のデータが表示されます。 1. クエリを編集するには、生成されたテキストを変更後の内容に置き換えます。また、**クエリジェネレーター**を使用して、新しいクエリを生成したり、既存のクエリを更新したりすることもできます。 #### アプリケーションログ **[アプリケーションログ]** タブのクエリを使用して、現在のロググループ、サービスに関するログ情報を生成し、タイムスタンプを挿入します。ロググループは、アプリケーションを設定する際に定義できるログストリームのグループです。 ロググループを使用して、次のような特性を持つログを整理します。 + 特定の組織、ソース、機能からログをキャプチャします。 + 特定のユーザーがアクセスするログをキャプチャします。 + 特定の期間のログをキャプチャします。 これらのログストリームを使用して、特定のグループまたは時間枠を追跡します。これらのロググループのモニタリングルール、アラーム、通知を設定することもできます。ロググループの詳細については、「[ロググループとログストリームを操作](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/Working-with-log-groups-and-streams.html)」を参照してください。 アプリケーションログクエリは、ログ、繰り返し発生するテキストパターン、およびグラフィカルに可視化したロググループを返します。 クエリを実行するには、**[Logs Insights でクエリを実行]** を選択して、自動生成されたクエリを実行するか、クエリを変更します。クエリを編集するには、自動生成されたテキストを変更後の内容に置き換えます。また、**クエリジェネレーター**を使用して、新しいクエリを生成したり、既存のクエリを更新したりすることもできます。 次のイメージに、サービスオペレーショングラフで選択されているポイントに基づいて自動的に生成されたサンプルのクエリを示します。 ![\[アプリケーションログテーブル\]](http://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/images/service-operations-application-logs.png) 前のイメージでは、CloudWatch は選択されたポイントに関連付けられているロググループを自動的に検出して、生成されたクエリに含めていました。 ## サービスの依存関係を表示する **[依存関係]** タブを選択すると、**[依存関係]** テーブルと、すべてのサービスオペレーションまたは 1 つのオペレーションの依存関係に関する一連のメトリクスが表示されます。このテーブルには、SLI ステータス、レイテンシー、コール量、障害率、エラー率、可用性のメトリクスなど、Application Signals によって検出された依存関係のリストが含まれています。 ページ上部の下向き矢印のリストからオペレーションを選択して依存関係を表示するか、**[すべて]** を選択してすべてのオペレーションの依存関係を表示します。 フィルターテキストボックスから 1 つまたは複数のプロパティを選択して、テーブルをフィルタリングすると、探しているものを見つけやすくなります。各プロパティを選択すると、フィルター条件が表示され、フィルターテキストボックスの下にフィルター全体が表示されます。**[フィルターのクリア]** を選択すると、いつでもテーブルのフィルターを削除できます。テーブルの右上にある **[依存関係別にグループ化]** を選択すると、依存関係をサービスとオペレーション名でグループ化できます。グループ化がオンになっている場合は、依存関係名の横にある **[\$1]** アイコンを使用して、依存関係のグループを展開するか折りたたみます。 ![\[依存関係のテーブル\]](http://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/images/service-dependencies-table.png) **[依存関係]** 列には依存関係サービス名が表示され、**[リモートオペレーション]** 列にはサービスオペレーション名が表示されます。**[SLI ステータス]** 列には、正常な SLI と異常な SLI の数、および各依存関係の SLI の合計数が表示されます。AWS のサービスを呼び出すと、**[ターゲット]** 列には DynamoDB のテーブルや Amazon SNS のキューといった AWS リソースが表示されます。 依存関係を選択するには、**[依存関係]** テーブルの依存関係の横にあるオプションを選択します。呼び出し量、可用性、障害、エラーに関する詳細なメトリクスを表示する一連のグラフが表示されます。グラフ内のポイントにカーソルを合わせると、ポップアップが開いて詳しい情報が表示されます。グラフ内のポイントを選択すると、診断ペインが開いて、グラフ内でのそのポイントの相関トレースが表示されます。**[相関トレース]** テーブルからトレース ID を選択して、選択したトレースの [[X-Ray トレースの詳細]](https://docs.aws.amazon.com/xray/latest/devguide/xray-console-traces.html) ページを開きます。 ![\[依存関係グラフと相関トレース\]](http://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/images/service-dependency-graph-traces.jpg) ## Synthetics Canary を表示する **[Synthetics Canary]** タブを選択すると、**[Synthetics Canary]** テーブルが表示され、そのテーブルには一連のメトリクスが canary ごとに表示されます。このテーブルには、成功率、平均所要時間、実行、失敗率に関するメトリクスが含まれています。[AWS X-Ray トレースが有効になっている](CloudWatch_Synthetics_Canaries_tracing.md) Canary のみが表示されます。 Synthetics Canary テーブルのフィルターテキストボックスを使用して、関心のある Canary を見つけます。作成する各フィルターは、フィルターテキストボックスの下に表示されます。**[フィルターのクリア]** を選択すると、いつでもテーブルのフィルターを削除できます。 ![\[Synthetics Canary のテーブル\]](http://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/images/service-canaries-table.png) Canary の名前の横にあるラジオボタンをクリックすると、成功、エラー、期間など、グラフの詳細なメトリクスを含む一連のタブが表示されます。グラフ内のポイントにカーソルを合わせると、ポップアップが開いて詳しい情報が表示されます。グラフ内のポイントを選択すると、選択したポイントと相関する Canary 実行を示す、診断ペインが開きます。Canary 実行を選択して **[ランタイム]** をクリックすると、ログ、HTTP アーカイブ (HAR) ファイル、スクリーンショット、問題のトラブルシューティングに役立つ推奨のステップなど、選択した Canary 実行のアーティファクトが表示されます。**[詳細]** をクリックして、**[Canary 実行]** の横にある [[CloudWatch Synthetics Canary]](CloudWatch_Synthetics_Canaries.md) のページを開きます。 ![\[Synthetics Canary のグラフと実行\]](http://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/images/service-canary-graphs-runs.jpg) ## クライアントページを表示する **[クライアントページ]** タブをクリックすると、サービスを呼び出すクライアントウェブページの一覧が表示されます。サービスまたはアプリケーションを操作する際のクライアントエクスペリエンスの質を測定するときは、選択したクライアントページの、一連のメトリクスを使用します。これらのメトリクスには、ページロード、ウェブバイタル、エラーなどが含まれます。 テーブルにクライアントページを表示するには、[CloudWatch RUM ウェブクライアントを X-Ray トレースに設定](CloudWatch-RUM-get-started-create-app-monitor.md)し、クライアントページの Application Signals メトリクスをオンにします。**[ページの管理]** をクリックして、Application Signals メトリクスを有効にするページを選択します。 フィルターテキストボックスを使用して、フィルターテキストボックスの下で、関心のあるクライアントページまたはアプリケーションモニターを特定します。**[フィルターのクリア]** を選択すると、テーブルのフィルターを削除できます。**[クライアント別にグループ化]** を選択すると、クライアントページをクライアントごとにグループ化できます。グループ化したら、クライアント名の横にある **[\$1]** アイコンを選択して行を展開し、そのクライアントのすべてのページを表示します。 ![\[クライアントページのテーブル\]](http://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/images/service-client-pages-table.png) クライアントページを選択するには、**[クライアントページ]** テーブルのクライアントページの横にあるオプションを選択します。詳細なメトリクスを表示する一連のグラフが表示されます。グラフ内のポイントにカーソルを合わせると、ポップアップが開いて詳しい情報が表示されます。グラフ内のポイントを選択すると、そのグラフ内の選択したポイントの相関パフォーマンスナビゲーションイベントを示す診断ペインが開きます。ナビゲーションイベントのリストからイベント ID を選択し、選択したイベントの [CloudWatch RUM ページビュー](CloudWatch-RUM-view-data.md)を開きます。 ![\[CloudWatch RUM クライアントページのリクエスト\]](http://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/images/service-client-page-graphs-events.jpg) **注記** クライアントページ内の AJAX エラーを確認するには、[CloudWatch RUM ウェブクライアント](CloudWatch-RUM-configure-client.md)バージョン 1.15 以降を使用してください。 サービスごとに、最大 100 のオペレーション、Canary、クライアントページと、最大 250 の依存関係を表示できます。 ## 関連メトリクスを表示する [関連メトリクス] タブを使用して、複数のメトリクスを視覚化し、相関パターンを特定し、問題の根本原因を特定します。 メトリクステーブルには、以下の 3 種類のメトリクスが表示されます。 + 標準メトリクス - 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/ja_jp/AmazonCloudWatch/latest/monitoring/images/Custom_metrics.png) + 左側のナビゲーションパネルは、すべてのオペレーションと依存関係が選択されていない状態で始まります + グラフには、最初に、障害率が最も高かったオペレーションの障害メトリクスが表示されます 相関関係の分析を開始する前に、サービスオペレーションまたは依存関係にデータポイントが表示されていることを確認してください。相関関係を分析するには: 1. [サービスオペレーション] または [依存関係] ページを開きます。 1. 任意のグラフのデータポイントを選択します。 1. 右側のパネルで、**[他のメトリクスに相関]** を選択します。 1. 開いた **[関連メトリクス]** タブには、以下が表示されます。 + 左側のナビゲーションで選択したオペレーションまたは依存関係 + *[メトリクスの参照]* テーブルでグラフ化された選択したメトリクス + データポイントを選択したときの相関スパン 複数のメトリクスをグラフ化するには、**[関連メトリクス]** タブの **[参照]** ビューから 1 つ以上のメトリクスを選択します。**[グラフ化されたメトリクス]** を選択して、グラフ化されたメトリクスをすべて表示します。 メトリクスをフィルタリングするには、左側のパネルフィルターを使用して特定のオペレーションまたは依存関係に焦点を当て、テーブルヘッダーフィルターバーを使用して名前、タイプ、またはその他の属性で検索します。これらのフィルタリングオプションは、パターンを検出し、問題をより効率的にトラブルシューティングするのに役立ちます。 関連するメトリクスを詳細に分析するには、**[関連メトリクス]** タブでデータポイントを選択します。その後、以下を表示できます。 + Top Contributors – CloudWatch Logs Insights クエリを実行してメトリクスを分析します。これらのクエリは、以下の詳細分析のためのキー属性を含む拡張メトリクス形式 (EMF) レコードを処理します。 + レイテンシー測定値 + 障害の発生 + サービスの可用性メトリクス 以下のメトリクスは Top Contributors をサポートしていません。 + OTEL メトリクス + サーバー側のスパンメトリクス RED メトリクスとクライアント側のスパンメトリクスの Top Contributors を表示できます。 + 相関スパン – 相関スパンセクションは、[サービスオペレーション] タブと一貫して動作します。関連するトレースとメトリクスを識別しやすくするために、相関メカニズムは以下によって機能します。 + メトリクス名とスパン属性の比較 + 選択した期間中に一致するパターンの特定 + 関連するトレース情報の表示 メトリクスとスパンを効果的に分析するには、さまざまなメトリクスタイプがどのように相関するかを理解する必要があります。主な制限事項は以下のとおりです。 + OTEL メトリクスは独立した命名システムを使用しているため、スパンと相関しません + サーバーまたはクライアント側のスパンメトリクスをスパンと関連付けるには: + 設定に Service ディメンションフィールドを含める + この Service ディメンションがないと、これらのメトリクスをスパンと関連付けることはできません + ログアプリケーション – ログアプリケーションの詳細については、「[サービスオペレーションを表示する](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、クライアントページに関する詳細が表示されます。 + アプリケーションマップをフィルタリングしてズームすると、アプリケーションのトポロジの一部に焦点を合わせたり、マップ全体を表示しやすくなります。フィルターテキストボックスから 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 の詳細を開きます。 ------ # AWS アクションのアプリケーションオブザーバビリティ AWS GitHub アクションのアプリケーションオブザーバビリティは、ソースコードとライブプロダクションテレメトリデータを AI エージェントに接続する、エンドツーエンドのアプリケーションオブザーバビリティ調査ワークフローを提供します。CloudWatch MCP を活用し、カスタムプロンプトを生成して、AI エージェントがトラブルシューティングやコード修正の適用に必要なコンテキストを提供します。 このアクションは、[CloudWatch Application Signals MCP サーバー](https://awslabs.github.io/mcp/servers/cloudwatch-applicationsignals-mcp-server)と [CloudWatch MCP サーバー](https://awslabs.github.io/mcp/servers/cloudwatch-applicationsignals-mcp-server)をセットアップおよび設定し、トラブルシューティングコンテキストとしてライブテレメトリデータにアクセスできるようにします。アプリケーションのパフォーマンス調査には、独自の API キー、サードパーティーモデル、Amazon Bedrock など、ご希望の AI モデルを使用できます。 開始するには、GitHub のIssue で `@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 Actions の OpenID Connect (OIDC) で設定された、以下の権限を持つ IAM ロール。 + CloudWatch Application Signals および CloudWatch へのアクセス + Amazon Bedrock モデルアクセス (Bedrock モデルを使用している場合) + **GitHub トークン**: ワークフローでは、必要なアクセス許可を持つ GITHUB\$1TOKEN が自動的に使用されます。 ### セットアップ手順 #### ステップ 1: AWS 認証情報を設定する このアクションは、GitHub Actions 環境で AWS 認証を設定する場合に [aws-actions/configure-aws-credentials](https://github.com/aws-actions/configure-aws-credentials) アクションに依存します。AWS での認証には OpenID Connect (OIDC) を使用することをお勧めします。OIDC を使用すると、GitHub Actions ワークフローは有効期間の短い AWS 認証情報を使用して AWS リソースにアクセスできるため、リポジトリに長期認証情報を保存する必要がなくなります。 1. **IAM ID プロバイダーを作成する** まず、AWS マネジメントコンソールで GitHub の OIDC エンドポイントを信頼する IAM ID プロバイダーを作成します。 1. IAM コンソールを開きます。 1. **[アクセス管理]** で **[ID プロバイダー]** をクリックします。 1. GitHub ID プロバイダーをまだ作成していない場合は、**[プロバイダーを追加]** ボタンをクリックして追加します。 1. **OpenID Connect** タイプの ID プロバイダーを選択します。 1. **[プロバイダーの URL]** 入力ボックスに「`https://token.actions.githubusercontent.com`」と入力します。 1. **[対象者]** 入力ボックスに「`sts.amazonaws.com`」と入力します。 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 組織名 + `` – リポジトリ名 + `` – ブランチ名 (例: main) 1. **IAM ポリシーをアタッチする** ロールの [アクセス許可] タブで、ステップ 2 で作成した IAM ポリシーをアタッチします。 AWS での OIDC の設定について詳しくは、「[configure-aws-credentials OIDC クイックスタートガイド](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 }} ``` **設定に関する注意事項:** + このワークフローは、Issue またはコメントで `@awsapm` がメンションされたときに自動的にトリガーされます。 + このワークフローは、前のステップで設定した `AWS_IAM_ROLE_ARN` シークレットを使用します。 + ステップ 2 のモデルパラメータを更新して、ご希望の Amazon Bedrock モデル ID を指定します。 + bot\$1name パラメータでボット名 (例: `@awsapm-prod`、`@awsapm-staging`) をカスタマイズすることで、さまざまな環境に対応できます。 #### ステップ 3: アクションの使用を開始する ワークフローの設定が完了したら、GitHub の Issue で `@awsapm` をメンションし、AI を活用した調査をトリガーします。このアクションはリクエストを分析し、ライブテレメトリデータにアクセスし、推奨事項を提供したり、修正を自動的に実装したりします。 **ユースケースの例:** 1. パフォーマンスの問題を調査し、その問題を投稿して修正します。 `@awsapm, can you help me investigate availability issues in my appointment service?` ![\[alt text not found\]](http://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/images/github-availability-issue-investigate.png) `@awsapm, can you post a fix?` ![\[alt text not found\]](http://docs.aws.amazon.com/ja_jp/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. エージェントは問題を分析し、次のいずれかを実行します。 + 検出結果と推奨事項を Issue に直接投稿します。 + コード変更 (計測または修正用) を含むプルリクエストを作成します。 1. 結果を確認し、フォローアップの質問で再度 @awsapm をメンションすることで、対話を継続できます。 ## セキュリティ このアクションでは、厳格なアクセスコントロール、OIDC ベースの AWS 認証、およびプロンプトインジェクション攻撃に対する組み込みの保護機能により、セキュリティが最優先事項とされています。書き込みアクセス権以上の権限を持つユーザーのみがこのアクションをトリガーでき、すべての操作は特定のリポジトリに限定されます。 以下を含む詳細なセキュリティ情報については、以下を参照してください。 + アクセスコントロールとアクセス許可の要件 + AWS IAM アクセス許可と OIDC 設定 + プロンプトインジェクションのリスクと緩和策 + セキュリティのベストプラクティス [セキュリティに関するドキュメント](https://github.com/aws-actions/application-observability-for-aws/blob/main/docs/security.md)をご覧ください。 ## 設定 ### 必要な許可 GitHub Actions が引き受ける IAM ロールには、以下のアクセス許可が必要です。 **注**: `bedrock:InvokeModel` および `bedrock:InvokeModelWithResponseStream` は、Amazon Bedrock モデルを使用している場合にのみ必要です。 ``` { "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/ja_jp/AmazonCloudWatch/latest/monitoring/images/example-scenario-services-page.jpg) Jane は、ページの上部を見て、障害率で最上位のサービスが `visits-service` であることを知りました。彼女がグラフ内のリンクを選択すると、そのサービスのサービス詳細ページが開きました。サービスのオペレーションテーブルには、異常なオペレーションがありました。このオペレーションを選択すると、[量と可用性] グラフが表示されました。そのグラフから、定期的な呼び出し量の急増と可用性の一時的低下には相関関係があるらしいことがわかりました。 ![\[サービスオペレーションの量と可用性\]](http://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/images/example-scenario-unhealthy-operation.png) Jane は、サービスの可用性の一時的低下を詳しく調べるために、グラフ内の可用性データポイントの 1 つを選択しました。ドロワーが開き、選択したデータポイントと相関関係がある X-Ray トレースが表示されました。彼女は、障害を含むトレースが複数あることに気付きました。 ![\[サービスの可用性と相関関係のあるトレース\]](http://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/images/example-scenario-correlated-traces.jpg) Jane が障害ステータスと相関関係があるトレースの 1 つを選択すると、選択したトレースの X-Ray トレース詳細ページが開きました。Jane は、[セグメントのタイムライン] セクションまでスクロールし、DynamoDB テーブルへの呼び出しがエラーを返していることがわかるまで呼び出しパスをたどりました。DynamoDB セグメントを選択し、右側のドロワーの [例外] タブに移動しました。 ![\[DynamoDB エラーのあるトレースセグメント\]](http://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/images/example-scenario-DDB-segment.jpg) Jane は、DynamoDB リソースの設定に誤りがあるため、顧客のリクエストが急増するとエラーが発生することに気付きました。DynamoDB テーブルのプロビジョニングされたスループットのレベルが定期的に超過していたため、サービスの可用性に問題が生じ、SLI に異常が発生していたのです。この情報に基づいて、彼女のチームはプロビジョニングされたスループットをより高いレベルに設定し、アプリケーションの高可用性を確保できるようになりました。 # 例: Application Signals を使用して、Amazon Bedrock モデルとやり取りする生成 AI アプリケーションのトラブルシューティングを行う Amazon Bedrock モデルとやり取りする生成 AI アプリケーションのトラブルシューティングには、Application Signals を使用できます。Application Signals は追加設定なしのテレメトリデータを提供することでこのプロセスを合理化し、LLM モデルとのアプリケーションのやり取りに関するより深いインサイトを提供します。これは、次のような主要なユースケースに対処するのに役立ちます。 + モデル設定の問題 + モデルの使用コスト + モデルのレイテンシー + モデルレスポンス生成の停止理由 LLM/GenAI Observability で [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/ja_jp/AmazonCloudWatch/latest/monitoring/images/AppSignalsAIExample.png) ## OpenTelemetry 生成 AI 属性のサポート Application Signals は、OpenTelemetry セマンティック規則を使用した Amazon Bedrock API コールに対して次の生成 AI 属性を生成します。これらの属性は、モデルの使用状況、コスト、レスポンス品質の分析に役立ち、[トランザクション検索](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 を使用した 生成 AI 属性。\]](http://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/images/AppSignalsAIExample_1.png) 例えば、トランザクション検索の分析機能を活用して、同じプロンプトの異なる LLM モデル間でトークンの使用量とコストを比較できるため、コスト効率の高いモデルを選択できます。 ![\[Application Signals を使用した 生成 AI 属性。\]](http://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/images/AppSignalsAIExample_2.png) 詳細については、「[Improve Amazon Bedrock Observability with CloudWatch Application Signals](https://aws.amazon.com/blogs/mt/improve-amazon-bedrock-observability-with-amazon-cloudwatch-appsignals/)」を参照してください。