

# Application Signals
<a name="CloudWatch-Application-Monitoring-Sections"></a>

CloudWatch Application Signals は、AWS でのアプリケーションパフォーマンスのモニタリングと改善に役立ちます。Amazon EC2、Amazon ECS、Lambda などのサービスで実行されているアプリケーションからデータを自動的に収集します。CloudWatch Application Signals は、以下に使用できます。
+ アプリケーションのヘルスをリアルタイムでモニタリングする
+ ビジネス目標に対するパフォーマンスを追跡する
+ サービスと依存関係の関係を表示する
+ パフォーマンスの問題を迅速に特定して解決する
+ Application Signals を有効にすると、アプリケーションからメトリクスとトレースが自動的に収集され、呼び出し量、可用性、レイテンシー、障害、エラーなどの主要なメトリクスが表示されます。カスタムコードを記述したり、ダッシュボードを作成したりしなくても、現在の運用状態や、アプリケーションが長期的なパフォーマンス目標を達成しているかどうかをすばやく確認してトリアージできます。
+ Application Signals を使用して、[サービスレベル目標 (SLO)](CloudWatch-ServiceLevelObjectives.md) を作成し、モニタリングします。Application Signals が収集する新しい標準アプリケーションメトリクスを含む、CloudWatch メトリクスに関連する SLO のステータスを簡単に作成して追跡できます。アプリケーションサービスの[サービスレベル指標 (SLI)](CloudWatch-ServiceLevelObjectives.md#CloudWatch-ServiceLevelObjectives-concepts) のステータスをサービスリストとトポロジマップ内で確認して追跡できます。SLO を追跡するアラームを作成したり、Application Signals が収集する新しい標準アプリケーションメトリクスを追跡したりできます。
+ Application Signals が自動的に検出するアプリケーショントポロジのマップを参照してください。これには、アプリケーション、依存関係、およびそれらの接続性が視覚的に表示されています。
+ Application Signals は、[CloudWatch RUM](CloudWatch-RUM.md)、[CloudWatch Synthetics canary](CloudWatch_Synthetics_Canaries.md)、[AWS Service Catalog AppRegistry](https://docs.aws.amazon.com/servicecatalog/latest/arguide/intro-app-registry.html)、および Amazon EC2 Auto Scaling と連携し、ダッシュボードやマップ内にクライアントページ、Synthetics canary、アプリケーション名を表示します。

**サポートされている言語とアーキテクチャ**

Application Signals は、Java、Python、Node.js、.NET アプリケーションをサポートしています。

Application Signals は、Amazon EKS、Amazon ECS、および Amazon EC2 でサポートされ、テストされています。Amazon EKS クラスターでは、サービスとクラスターの名前が自動的に検出されます。他のアーキテクチャでは、Application Signals に対してそれらのサービスを有効にするときに、サービスと環境の名前を指定する必要があります。

Amazon EC2 で Application Signals を有効にする手順は、CloudWatch エージェントと AWS Distro for OpenTelemetry をサポートするすべてのアーキテクチャで機能する必要があります。ただし、この手順は Amazon ECS と Amazon EC2 以外のアーキテクチャではテストされていません。

**サポートされるリージョン**

Application Signals は、カナダ西部 (カルガリー) を除くすべての商用リージョンでサポートされています。

**Topics**
+ [機能](#application-signals-features)
+ [Application Signals に必要な権限](Application_Signals_Permissions.md)
+ [サポートされているシステム](CloudWatch-Application-Signals-supportmatrix.md)
+ [サポートされている計測設定](Getting-Started-App-Signals.md)
+ [アカウントで Application Signals を有効にする](CloudWatch-Application-Signals-Enable.md)
+ [(オプション) サンプルアプリケーションで Application Signals を試す](CloudWatch-Application-Signals-Enable-EKS-sample.md)
+ [Amazon EKS クラスターでアプリケーションを有効にする](CloudWatch-Application-Signals-Enable-EKS.md)
+ [Amazon EC2 でアプリケーションを有効にする](CloudWatch-Application-Signals-Enable-EC2Main.md)
+ [Amazon ECS でアプリケーションを有効にする](CloudWatch-Application-Signals-Enable-ECSMain.md)
+ [Kubernetes でアプリケーションを有効にする](CloudWatch-Application-Signals-Enable-KubernetesMain.md)
+ [Lambda でアプリケーションを有効にする](CloudWatch-Application-Signals-Enable-LambdaMain.md)
+ [Application Signals のインストールでトラブルシューティングを行う](CloudWatch-Application-Signals-Enable-Troubleshoot.md)
+ [(オプション) Application Signals を設定する](CloudWatch-Application-Signals-Configure.md)
+ [Application Signals を使用したアプリケーションの運用状態のモニタリング](Services.md)
+ [Application Signals によって収集されるメトリクス](AppSignals-MetricsCollected.md)
+ [Application Signals を使用したカスタムメトリクス](AppSignals-CustomMetrics.md)

## 機能
<a name="application-signals-features"></a>
+ **Application Signals を毎日のアプリケーションモニタリングに使用する** – 毎日のアプリケーションモニタリングの一環として、CloudWatch コンソール内で Application Signals を使用します。

  1. サービスのサービスレベル目標 (SLO) を作成した場合は、[サービスレベル目標 (SLO)](CloudWatch-ServiceLevelObjectives.md#CloudWatch-ServiceLevelObjectives-Triage) ページから始めてください。ここでは、最も重要なサービス、オペレーション、依存関係の状態をすぐに把握できます。SLO のサービス名、オペレーション名、または依存関係名を選択すると、[サービスの詳細](ServiceDetail.md)ページが開き、問題のトラブルシューティング時に詳細なサービス情報が表示されます。

  1. [サービス](Services-page.md)ページを開くと、すべてのサービスの概要が表示され、障害率またはレイテンシーが最も高いサービスをすばやく確認できます。SLO を作成した場合は、サービスのテーブルを見て、どのサービスに異常なサービスレベル指標 (SLI) があるかを確認してください。特定のサービスが異常状態にある場合は、サービスを選択して[サービスの詳細](ServiceDetail.md)ページを開き、サービスオペレーション、依存関係、Synthetics Canary、およびクライアントリクエストを確認します。グラフ内のポイントを選択して、相関関係のあるトレースを表示すると、運用上の問題の根本原因をトラブルシューティングして特定できます。

  1. 新しいサービスがデプロイされたり、依存関係が変更されたりした場合は、[[アプリケーションマップ]](ServiceMap.md) を開いてアプリケーショントポロジを調べます。クライアント、Synthetics Canary、サービス、依存関係の関係を示すアプリケーションのマップを参照してください。SLI の状態をすばやく確認したり、呼び出し量、障害率、レイテンシーなどの主要なメトリクスを表示したり、[サービスの詳細](ServiceDetail.md)ページでドリルダウンして詳細情報を確認したりできます。

  Application Signals を使用すると、料金が発生します。CloudWatch の料金の詳細については、[Amazon CloudWatch の料金](https://aws.amazon.com/cloudwatch/pricing)をご覧ください。
**注記**  
CloudWatch Synthetics または CloudWatch RUM を使用するために、Application Signals を有効にする必要はありません。ただし、Synthetics と CloudWatch RUM を Application Signals と連携させると、これらの機能を一緒に使用した場合にメリットが得られます。
+ **Application Signals のクロスアカウント** – Application Signals のクロスアカウントオブザーバビリティを使用すると、単一リージョン内の複数の AWS アカウントにまたがるアプリケーションをモニタリングおよびトラブルシューティングできます。

  Amazon CloudWatch オブザーバビリティアクセスマネージャーを使用して、1 つ以上の AWS アカウントをモニタリングアカウントとして設定できます。モニタリングアカウントにシンクを作成することで、モニタリングアカウントにソースアカウントのデータを表示する機能を持たせます。シンクを使用して、ソースアカウントからモニタリングアカウントへのリンクを作成します。詳細については、「[CloudWatch のクロスアカウントオブザーバビリティ](CloudWatch-Unified-Cross-Account.md)」を参照してください。

  Application Signals のクロスアカウントオブザーバビリティが適切に機能するためには、以下のテレメトリータイプが CloudWatch Observability Access Manager を通じて共有されていることを確認してください。
  + Application Signals サービスとサービスレベル目標 (SLOs)
  + Amazon CloudWatch のメトリクス
  + Amazon CloudWatch Logs のロググループ
  + [AWS X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/aws-xray.html) のトレース
+ **動的サービスのグループ化とフィルタリング** – Application Signals の動的グループ化機能を使用してサービスをグループ化およびフィルタリングします。グループ内のサービスのメトリクスと SLI を自動的に集約することで、グループビューから開始し、特定の問題領域を深く掘り下げることができます。Application Signals には、サービス環境別に整理する「環境」グループ化と、依存関係に基づいてサービスをグループ化する「関連サービス」グループ化の 2 つのデフォルトのグループ化方法があります。例えば、関連サービスのグループ化では、サービス A がサービス B を、サービス B がサービス C を呼び出す場合、それらはサービス A の下にグループ化されます。デフォルトのグループ化以外に、ビジネスユニットやチームなど、組織のニーズに合ったサービスを選択してカスタムグループを作成します。

  チーム構造、ビジネスドメイン、または運用要件に合った AWS タグまたは OpenTelemetry 属性を使用してカスタムグループ化を作成します。カスタムグループ化を使用すると、特定のモニタリングおよびトラブルシューティングワークフローに従ってサービスを整理できます。詳細については、「[カスタムグループの設定](ServiceMap.md#Application-Map-Configure-Custom-Groups)」を参照してください。  
![関連サービス別にグループ化された CloudWatch アプリケーションマップ。](http://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/images/application-map.png)  
![フィルタリングを使用した CloudWatch サービスリストページ。](http://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/images/services-page.png)
+ **変更イベント** – Application Signals による CloudTrail イベントの自動処理により、アプリケーション全体の変更イベントを追跡します。サービスとその依存関係の設定イベントとデプロイイベントをモニタリングし、運用分析とトラブルシューティングのコンテキストを即座に提供します。変更イベント検出は、CloudWatch コンソールまたは StartDiscovery API を介したサービス検出の有効化とともに有効になります。Amazon EKS サービスの場合、デプロイ検出では、Amazon EKS サービスが Application Signals 計測 SDK で計測される必要があります。

   変更イベントは、次のリソースでサポートされています。
  + Autoscaling グループ
  + EKS クラスター
  + EKS ワークロード (デプロイのみ)
  + ECS クラスターとサービス
  + ELB ロードバランサーとターゲットグループ
  + Lambda 関数
  + BedrockAgentCore ランタイムと RuntimeEndpoint  
![グループドロワーのデプロイフィルタリングと変更イベントを含む CloudWatch アプリケーションマップ。](http://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/images/application-map-with-drawer.png)  
![CloudWatch アプリケーションの概要と変更イベントテーブル。](http://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/images/application-overview.png)
+ **自動監査の検出結果** – Application Signals の自動監査の検出結果を通じて重要なインサイトを検出します。このサービスは、アプリケーションを分析して重大な観察結果と潜在的な問題を報告し、根本原因の分析を簡素化します。これらの自動検出結果により、関連するトレースが統合されるため、複数回クリックして移動する必要がなくなります。監査システムは、チームが問題とその基になる原因をすばやく特定し、問題解決を迅速化します。

  Application Signals は、高度な分析を使用してパターンを検出し、リソースの非効率性を強調し、最適化の機会を提案します。検出結果には重大度と潜在的なビジネスへの影響に基づいて優先順位が付けられるため、チームは最初に最も重要な問題に集中できます。手動分析をしないで、サービスの信頼性とパフォーマンスを向上させるための実用的な推奨事項を取得します。  
![監査の検出結果を含む CloudWatch サービスの概要。](http://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/images/service-overview.png)