# CloudWatch オブザーバビリティソリューション
CloudWatch オブザーバビリティソリューションには、さまざまな AWS サービスや Java Virtual Machines (JVM)、Apache Kafka、Apache Tomcat、NGINX などの一般的なワークロードのモニタリングを迅速に実装するのに役立つ、すぐに利用可能な設定のカタログが用意されています。これらのソリューションからは、CloudWatch エージェントのインストールと設定、事前定義されたカスタムダッシュボードのデプロイ、メトリクスアラームの設定など、主要なモニタリングタスクに焦点を当てたガイダンスが得られます。これらは、デベロッパーと運用チームが AWS モニタリングツールとオブザーバビリティツールをより効果的に活用するのに役立つように設計されています。
このソリューションには、インフラストラクチャの Detailed Monitoring メトリクス、コンテナモニタリングの Container Insights、アプリケーションモニタリングの Application Signals など、特定のオブザーバビリティ機能を使用するタイミングに関するガイダンスが含まれています。これらのソリューションは、実施例と実用的な設定を提供することで、初期セットアッププロセスを簡単にして機能モニタリングをより迅速に確立し、特定の要件に合わせて必要に応じてカスタマイズすることを目指しています。
オブザーバビリティソリューションを開始するには、CloudWatch コンソールの[オブザーバビリティソリューションページ](https://console.aws.amazon.com/cloudwatch/home?#settings:/observability-solutions)にアクセスしてください。
Amazon Managed Grafana で動作するオープンソースソリューションについては、[Amazon Managed Grafana のソリューション](https://docs.aws.amazon.com/grafana/latest/userguide/AMG_solutions.html)に関するページを参照してください。
CloudWatch エージェントを必要とするソリューションの詳細を以下に示します。
**Topics**
+ [CloudWatch ソリューション: Amazon EC2 での JVM ワークロード](Solution-JVM-On-EC2.md)
+ [CloudWatch ソリューション: Amazon EC2 での NGINX ワークロード](Solution-NGINX-On-EC2.md)
+ [CloudWatch ソリューション: Amazon EC2 での NVIDIA GPU ワークロード](Solution-NVIDIA-GPU-On-EC2.md)
+ [CloudWatch ソリューション: Amazon EC2 での Kafka ワークロード](Solution-Kafka-On-EC2.md)
+ [CloudWatch ソリューション: Amazon EC2 での Tomcat ワークロード](Solution-Tomcat-On-EC2.md)
+ [CloudWatch ソリューション: Amazon EC2 ヘルス](Solution-EC2-Health.md)
**ソリューションダッシュボードの仕組み**
CloudWatch ソリューションのダッシュボードでは、検索駆動型の変数 (ドロップダウン) を使用して、ワークロードのさまざまな側面を動的に探索および可視化できます。
検索駆動型の変数の柔軟性と事前設定された[メトリクスウィジェット](create-and-work-with-widgets.md)を組み合わせることで、ダッシュボードはワークロードに関する深いインサイトを提供し、プロアクティブモニタリング、トラブルシューティング、最適化を可能にします。この動的なアプローチにより、大幅にカスタマイズや設定をしなくても、ダッシュボードを特定のモニタリングニーズにすばやく適応させることができます。
**ソリューションはクロスリージョンオブザーバビリティをサポートしていますか?**
CloudWatch ソリューションダッシュボードには、ソリューションダッシュボードが作成されたリージョンのメトリクスが表示されます。しかし、ソリューションダッシュボードには、複数のリージョンにわたるメトリクスは表示されません。1 つのダッシュボードで複数のリージョンのデータを表示するユースケースがある場合は、ダッシュボード JSON をカスタマイズして、表示するリージョンを追加する必要があります。これを行うには、メトリクス形式の `region` 属性を使用して、別々のリージョンからメトリクスをクエリします。ダッシュボード JSON の変更の詳細については、「[メトリクスウィジェット: 配列内の各メトリクスの形式](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/CloudWatch-Dashboard-Body-Structure.html#CloudWatch-Dashboard-Properties-Metrics-Array-Format)」を参照してください。
**ソリューションダッシュボードは、[クロスアカウントクロスリージョン CloudWatch コンソール](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Cross-Account-Cross-Region.html)をサポートしていますか?**
CloudWatch クロスアカウントオブザーバビリティを使用する場合、中心となるモニタリングアカウントのソリューションダッシュボードには、同じリージョンの複数のソースアカウントからのメトリクスが表示されます。類似のワークロードのメトリクスをアカウント間で区別するには、エージェント設定で一意のグループ化ディメンション値を指定します。例えば、Kafka ワークロードの異なるアカウントの Kafka ブローカーに互いに異なる `ClusterName` 値を割り当てると、クラスターの正確な選択とダッシュボードでのメトリクスの表示が可能になります。
**ソリューションダッシュボードは [CloudWatch のクロスアカウントオブザーバビリティ](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Unified-Cross-Account.html)をサポートしていますか?**
クロスアカウントクロスリージョン CloudWatch コンソールでクロスアカウントを有効にしている場合、モニタリングアカウントで作成されたソリューションダッシュボードを使用して複数のソースアカウントからのメトリクスを表示することはできません。そうではなく、それぞれのソースアカウントにダッシュボードを作成する必要があります。ただし、ソースアカウントにダッシュボードを作成し、コンソールでアカウント ID 設定を切り替えることで、モニタリングアカウントからダッシュボードを表示できます。
**ソリューションダッシュボードにはどのような制限がありますか?**
ソリューションダッシュボードは、検索式を活用してワークロードのメトリクスをフィルタリングおよび分析します。これにより、ドロップダウンオプションの選択に基づいて動的ビューが有効になります。これらの検索式は 500 を超える時系列を返す可能性がありますが、各ダッシュボードウィジェットには 500 を超える時系列を表示することはできません。ソリューションダッシュボードのメトリクス検索の結果、すべての Amazon EC2 で 500 を超える時系列が返された場合、寄与する要因の上位を表示するグラフに不正確な結果が表示される可能性があります。検索式の詳細については、「[CloudWatch 検索式の構文](search-expression-syntax.md)」を参照してください。
ダッシュボードウィジェットの `i` アイコンをクリックすると、CloudWatch はダッシュボードにメトリクス情報を表示します。ただし、現在、これは検索式を使用するダッシュボードウィジェットでは機能しません。ソリューションダッシュボードは検索式を使用するため、ダッシュボードにメトリクスの説明を表示することはできません。
**ソリューションが提供するエージェント設定やダッシュボードをカスタマイズできますか?**
エージェント設定とダッシュボードをカスタマイズできます。エージェント設定をカスタマイズする場合は、それに応じてダッシュボードを更新する必要があることに注意してください。更新しないと、空のメトリクスウィジェットが表示されます。また、CloudWatch がソリューションの新しいバージョンをリリースした場合、ソリューションの新しいバージョンを適用するとカスタマイズを繰り返す必要がある場合があります。
**ソリューションのバージョニング方法**
各ソリューションでは、最新の手順とリソースが用意されています。常に、利用可能な最新バージョンを使用することをお勧めします。ソリューション自体はバージョニングされていませんが、関連するアーティファクト (ダッシュボードの CloudFormation テンプレートやエージェントのインストールなど) はバージョニングされています。
CloudFormation テンプレートの説明フィールドまたはダウンロードしたテンプレートのファイル名を確認することで、以前にデプロイされたアーティファクトのバージョンを特定できます。最新バージョンを使用しているかどうかを確認するには、デプロイしたバージョンをソリューションドキュメントで現在参照されているバージョンと比較します。
# CloudWatch ソリューション: Amazon EC2 での JVM ワークロード
このソリューションは、EC2 インスタンスで実行されている JVM アプリケーション用の CloudWatch エージェントを使用して、すぐに使用できるメトリクス収集を設定するのに役立ちます。さらに、事前設定された CloudWatch ダッシュボードを設定するのに役立ちます。すべての CloudWatch オブザーバビリティソリューションの一般的な情報については、「[CloudWatch オブザーバビリティソリューション](Monitoring-Solutions.md)」を参照してください。
**Topics**
+ [要件](#Solution-JVM-On-EC2-Requirements)
+ [利点](#Solution-JVM-On-EC2-Benefits)
+ [コスト](#Solution-JVM-On-EC2-Costs)
+ [このソリューションの CloudWatch エージェント設定](#Solution-JVM-CloudWatch-Agent)
+ [ソリューションにエージェントをデプロイする](#Solution-JVM-Agent-Deploy)
+ [JVM ソリューションダッシュボードを作成する](#Solution-JVM-Dashboard)
## 要件
このソリューションは、以下の条件に適しています。
+ サポートされているバージョン: Java LTS バージョン 8、11、17、21
+ コンピューティング: Amazon EC2
+ 特定の AWS リージョン内の JVM ワークロード全体で最大 500 個の EC2 インスタンスをサポート
+ CloudWatch エージェントの最新バージョン
+ EC2 インスタンスにインストールされた SSM エージェント
**注記**
AWS Systems Manager (SSM エージェント) は、AWS および信頼できるサードパーティーが提供している一部の [Amazon マシンイメージ (AMI)](https://docs.aws.amazon.com/systems-manager/latest/userguide/ami-preinstalled-agent.html) にプリインストールされています。エージェントがインストールされていない場合は、使用しているオペレーティングシステムタイプの手順を使用して、手動でインストールできます。
[Linux 用 EC2 インスタンスに SSM Agent を手動でインストールおよびアンインストールする](https://docs.aws.amazon.com/systems-manager/latest/userguide/manually-install-ssm-agent-linux.html)
[macOS 用の EC2 インスタンスに SSM Agent を手動でインストールおよびアンインストールする](https://docs.aws.amazon.com/systems-manager/latest/userguide/manually-install-ssm-agent-macos.html)
[Windows Server 用の EC2 インスタンスに SSM Agent を手動でインストールおよびアンインストールする](https://docs.aws.amazon.com/systems-manager/latest/userguide/manually-install-ssm-agent-windows.html)
## 利点
このソリューションでは JVM をモニタリングしているため、以下のユースケースに役立つインサイトが得られます。
+ JVM のヒープメモリと非ヒープメモリの使用状況をモニタリングします。
+ 同時実行の問題がないか、スレッドとクラスのロードを分析します。
+ ガベージコレクションを追跡してメモリリークを特定します。
+ 同じアカウントでソリューションを介して設定された異なる JVM アプリケーションを切り替えます。
ソリューションの主な利点を以下に示します。
+ CloudWatch エージェント設定を使用して JVM のメトリクス収集を自動化し、手動計測をなくします。
+ JVM メトリクス用の事前設定済みの統合 CloudWatch ダッシュボードが用意されています。ダッシュボードは、ダッシュボードを初めて作成するときにメトリクスが存在しない場合でも、ソリューションを使用して設定された新しい JVM EC2 インスタンスからのメトリクスを自動的に処理します。また、メトリクスを論理アプリケーションにグループ化して、重点の絞り込みと管理を容易にすることもできます。
以下の画像は、このソリューションのダッシュボードの例です。
![\[JVM ダッシュボードの例\]](http://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/images/JvmDashboard.png)
## コスト
このソリューションは、アカウントでリソースを作成して使用します。標準使用には料金がかかります。これには以下を含みます。
+ CloudWatch エージェントによって収集されたすべてのメトリクスは、カスタムメトリクスとして課金されます。このソリューションで使用されるメトリクスの数は、EC2 ホストの数によって異なります。
+ ソリューション用に設定された各 JVM ホストは、合計 18 個のメトリクスと、ホストのパス数によってメトリクス数が異なる 1 つのメトリクス (`disk_used_percent`) を公開します。
+ 1 つのカスタムダッシュボード。
+ CloudWatch エージェントによってメトリクスの公開がリクエストされた API オペレーション。このソリューションのデフォルト設定では、CloudWatch エージェントは EC2 ホストごとに毎分 1 回 **PutMetricData** を呼び出します。つまり、**PutMetricData** API は EC2 ホストごとに 30 日の月には `30*24*60=43,200` 回呼び出されます。
CloudWatch の料金の詳細については、「[Amazon CloudWatch の料金](https://aws.amazon.com/cloudwatch/pricing/)」をご覧ください。
料金計算ツールを使用すると、このソリューションを使用するためのおよその月額コストを見積もることができます。
**料金計算ツールを使用して毎月のソリューションのコストを見積もるには**
1. [Amazon CloudWatch 料金計算ツール](https://calculator.aws/#/createCalculator/CloudWatch)を開きます。
1. **[リージョンを選択]** では、ソリューションをデプロイするリージョンを選択します。
1. **[メトリクス]** セクションの **[メトリクスの数]** に **(18 \$1 average number of disk paths per EC2 host) \$1 number of EC2 instances configured for this solution** を入力します。
1. **[API]** セクションの **[API リクエストの数]** に **43200 \$1 number of EC2 instances configured for this solution** を入力します。
デフォルトでは、CloudWatch エージェントは EC2 ホストごとに毎分 1 回 **PutMetricData** オペレーションを実行します。
1. **[ダッシュボードとアラーム]** セクションの **[ダッシュボードの数]** に「**1**」と入力します。
1. 毎月の見積コストは、料金計算ツールの下部に表示されます。
## このソリューションの CloudWatch エージェント設定
CloudWatch エージェントは、サーバー上およびコンテナ化された環境で継続的かつ自律的に実行されるソフトウェアです。インフラストラクチャとアプリケーションからメトリクス、ログ、トレースを収集し、CloudWatch と X-Ray に送信します。
CloudWatch エージェントの詳細については、「[CloudWatch エージェントを使用してメトリクス、ログ、トレースを収集する](Install-CloudWatch-Agent.md)」を参照してください。
このソリューションのエージェント設定では、ソリューションの基本的なメトリクスが収集されます。CloudWatch エージェントは、ダッシュボードのデフォルトで表示されるよりも多くの JVM メトリクスを収集するように設定できます。収集できるすべての JVM メトリクスのリストについては、「[JVM メトリクスの収集](CloudWatch-Agent-JMX-metrics.md#CloudWatch-Agent-JVM-metrics)」を参照してください。CloudWatch エージェント設定の一般的な情報については、「[CloudWatch エージェントにより収集されるメトリクス](metrics-collected-by-CloudWatch-agent.md)」を参照してください。
**JVM アプリケーションの JMX ポートを公開する**
CloudWatch エージェントは JMX に依存して JVM プロセスに関連するメトリクスを収集します。これを実現するには、JVM アプリケーションから JMX ポートを公開する必要があります。JMX ポートを公開する手順は、JVM アプリケーションに使用するワークロードタイプによって異なります。これらの手順については、アプリケーションのドキュメントを参照してください。
通常、モニタリングと管理のために JMX ポートを有効にするには、JVM アプリケーションに次のシステムプロパティを設定します。必ず未使用のポート番号を指定してください。次の例では、認証されていない JMX を設定します。セキュリティポリシー/要件で、JMX を有効にするためにパスワード認証やリモートアクセスで SSL を有効にすることが必須の場合は、[JMX のドキュメント](https://docs.oracle.com/en/java/javase/17/management/monitoring-and-management-using-jmx-technology.html)を参照して必要なプロパティを設定します。
```
-Dcom.sun.management.jmxremote
-Dcom.sun.management.jmxremote.port=port-number
-Dcom.sun.management.jmxremote.authenticate=false
-Dcom.sun.management.jmxremote.ssl=false
```
アプリケーションの開始スクリプトと設定ファイルを確認して、これらの引数を追加する最適な場所を見つけます。コマンドラインから `.jar` ファイルを実行する場合、このコマンドは次のようになります。ここで、*pet-search.jar* はアプリケーション jar の名前です。
```
$ java -jar -Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=9999 -Dcom.sun.management.jmxremote.authenticate=false -Dcom.sun.management.jmxremote.ssl=false pet-search.jar
```
**このソリューションのエージェント設定**
エージェントによって収集されるメトリクスは、エージェント設定で定義されます。このソリューションには、ソリューションのダッシュボードに適したディメンションで推奨メトリクスを収集するためのエージェント設定が用意されています。
ソリューションをデプロイする手順については、「[ソリューションにエージェントをデプロイする](#Solution-JVM-Agent-Deploy)」で後述します。以下の情報は、環境に合わせてエージェント設定をカスタマイズする方法を理解するのに役立ちます。
環境に合わせて、次のエージェント設定の一部をカスタマイズする必要があります。
+ JMX ポート番号は、このドキュメントの前のセクションで設定したポート番号です。設定の `endpoint` 行にあります。
+ `ProcessGroupName`– `ProcessGroupName` ディメンションに意味のある名前を付けます。これらの名前は、同じアプリケーションまたはプロセスを実行している EC2 インスタンスのクラスター、アプリケーション、またはサービスのグループを表す必要があります。これにより、同じ JVM プロセスグループに属するインスタンスからのメトリクスをグループ化し、ソリューションダッシュボードでクラスター、アプリケーション、サービスのパフォーマンスを統一して表示できます。
例えば、同じアカウントで実行されている Java アプリケーションが 2 つあり、1 つは `order-processing` アプリケーション用、もう 1 つは `inventory-management` アプリケーション用である場合、それに応じて各インスタンスのエージェント設定で `ProcessGroupName` ディメンションを設定する必要があります。
+ `order-processing` アプリケーションのインスタンスには、`ProcessGroupName=order-processing` を設定します。
+ `inventory-management` アプリケーションのインスタンスには、`ProcessGroupName=inventory-management` を設定します。
これらのガイドラインに従うと、ソリューションダッシュボードは `ProcessGroupName` ディメンションに基づいてメトリクスを自動的にグループ化します。ダッシュボードには、特定のプロセスグループのメトリクスを選択および表示するドロップダウンオプションが含まれており、個々のプロセスグループのパフォーマンスを個別にモニタリングできます。
### JVM ホストのエージェント設定
Java アプリケーションがデプロイされている EC2 インスタンスでは、次の CloudWatch エージェント設定を使用します。設定は、「[ステップ 2: 推奨 CloudWatch エージェント設定ファイルを Systems Manager パラメータストアに保存する](#Solution-JVM-Agent-Step2)」で後述するように、SSM のパラメータストアにパラメータとして保存されます。
*ProcessGroupName* をプロセスグループの名前に置き換えます。*port-number* を Java アプリケーションの JMX ポートに置き換えます。JMX がリモートアクセス用のパスワード認証または SSL で有効になっている場合は、必要に応じて、エージェント設定で TLS または認証を設定する方法について「[Java Management Extensions (JMX) メトリクスの収集](CloudWatch-Agent-JMX-metrics.md)」を参照してください。
この設定 (JMX ブロックの外部に示される設定) に示される EC2 メトリクスは、Linux インスタンスと macOS インスタンスでのみ機能します。Windows インスタンスを使用している場合は、設定でこれらのメトリクスを省略できます。Windows インスタンスで収集されたメトリクスについては、「[Windows Server インスタンスで CloudWatch エージェントにより収集されるメトリクス](metrics-collected-by-CloudWatch-agent.md#windows-metrics-enabled-by-CloudWatch-agent)」を参照してください。
```
{
"metrics": {
"namespace": "CWAgent",
"append_dimensions": {
"InstanceId": "${aws:InstanceId}"
},
"metrics_collected": {
"jmx": [
{
"endpoint": "localhost:port-number",
"jvm": {
"measurement": [
"jvm.classes.loaded",
"jvm.gc.collections.count",
"jvm.gc.collections.elapsed",
"jvm.memory.heap.committed",
"jvm.memory.heap.max",
"jvm.memory.heap.used",
"jvm.memory.nonheap.committed",
"jvm.memory.nonheap.max",
"jvm.memory.nonheap.used",
"jvm.threads.count"
]
},
"append_dimensions": {
"ProcessGroupName": "ProcessGroupName"
}
}
],
"disk": {
"measurement": [
"used_percent"
]
},
"mem": {
"measurement": [
"used_percent"
]
},
"swap": {
"measurement": [
"used_percent"
]
},
"netstat": {
"measurement": [
"tcp_established",
"tcp_time_wait"
]
}
}
}
}
```
## ソリューションにエージェントをデプロイする
ユースケースに応じて、CloudWatch エージェントをインストールするためのいくつかのアプローチがあります。このソリューションには Systems Manager を使用することをお勧めします。これにより、コンソール操作機能が提供され、1 つの AWS アカウント内のマネージドサーバーのフリートの管理が簡単になります。このセクションの手順では Systems Manager を使用し、CloudWatch エージェントを既存の設定で実行していない場合を想定しています。CloudWatch エージェントが実行されているかどうかは、「[CloudWatch エージェントが実行されていることを確認する](troubleshooting-CloudWatch-Agent.md#CloudWatch-Agent-troubleshooting-verify-running)」の手順に従って確認できます。
ワークロードがデプロイされている EC2 ホストで CloudWatch エージェントを既に実行していて、エージェント設定を管理している場合は、このセクションの手順をスキップし、既存のデプロイメカニズムに従って設定を更新できます。JVM のエージェント設定を既存のエージェント設定とマージしてから、マージされた設定をデプロイするようにしてください。Systems Manager を使用して CloudWatch エージェントの設定を保存および管理している場合は、設定を既存のパラメータ値にマージできます。詳細については、「[CloudWatch エージェント設定ファイルの管理](https://docs.aws.amazon.com/prescriptive-guidance/latest/implementing-logging-monitoring-cloudwatch/create-store-cloudwatch-configurations.html)」を参照してください。
**注記**
Systems Manager を使用して次の CloudWatch エージェント設定をデプロイすると、EC2 インスタンスの既存の CloudWatch エージェント設定がある場合は置き換えられるか、上書きされます。独自の環境やユースケースに合わせてこの設定を変更できます。このソリューションで定義されているメトリクスは、推奨されるダッシュボードに最小限必要なものです。
このデプロイプロセスには、以下のステップが含まれます。
+ ステップ 1: ターゲット EC2 インスタンスに必要な IAM アクセス許可があることを確認します。
+ ステップ 2: 推奨エージェント設定ファイルを Systems Manager パラメータストアに保存します。
+ ステップ 3: CloudFormation スタックを使用して 1 つまたは複数の EC2 インスタンスに CloudWatch エージェントをインストールします。
+ ステップ 4: エージェントのセットアップが正しく設定されていることを確認します。
### ステップ 1: ターゲット EC2 インスタンスに必要な IAM アクセス許可があることを確認する
CloudWatch エージェントをインストールして設定するためのアクセス許可を Systems Manager に付与する必要があります。また、EC2 インスタンスから CloudWatch にテレメトリを発行するアクセス許可を CloudWatch エージェントに付与する必要もあります。インスタンスにアタッチされた IAM ロールに **CloudWatchAgentServerPolicy** と **AmazonSSMManagedInstanceCore** の IAM ポリシーがアタッチされていることを確認します。
+ ロールを作成したら、ロールを EC2 インスタンスにアタッチします。新しい EC2 インスタンスの起動中にロールをアタッチするには、[IAM ロールを持つインスタンスの起動](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html#launch-instance-with-role)に関するページの手順に従います。既存の EC2 インスタンスにロールをアタッチするには、[インスタンスへの IAM ロールのアタッチ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html#attach-iam-role)に関するページの手順に従います。
### ステップ 2: 推奨 CloudWatch エージェント設定ファイルを Systems Manager パラメータストアに保存する
パラメータストアでは、設定パラメータを安全に保存および管理することで EC2 インスタンスへの CloudWatch エージェントのインストールが簡素化され、ハードコーディングされた値が不要になります。これにより、デプロイプロセスがより安全で柔軟になり、集中管理が可能になり、複数のインスタンスで設定を簡単に更新できるようになります。
以下の手順を使用して、パラメータストアに推奨 CloudWatch エージェント設定ファイルをパラメータとして保存します。
**CloudWatch エージェント設定ファイルをパラメータとして作成するには**
1. AWS Systems Manager コンソール ([https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)) を開きます。
1. ナビゲーションペインで **[アプリケーション管理]**、**[パラメータストア]** を選択します。
1. 以下の手順に従って、設定の新しいパラメータを作成します。
1. **[パラメータの作成]** を選択します。
1. **[名前]** ボックスに、後のステップで CloudWatch エージェント設定ファイルを参照するために使用する名前を入力します。例えば、**AmazonCloudWatch-JVM-Configuration**。
1. (オプション) **[説明]** ボックスにパラメータの説明を入力します。
1. **[パラメータ階層]** で、**[標準]** を選択します。
1. **[型]** で、**[文字列]** を選択します。
1. **[データ型]** で、**[テキスト]** を選択します。
1. **[値]** ボックスに、[JVM ホストのエージェント設定](#Solution-JVM-Agent-Config) にリストされた対応する JSON ブロックを貼り付けます。説明に従って、グループ化ディメンション値とポート番号を必ずカスタマイズしてください。
1. **[パラメータの作成]** を選択します。
### ステップ 3: CloudWatch エージェントをインストールし、CloudFormation テンプレートを使用して設定を適用する
AWS CloudFormation を使用してエージェントをインストールし、これまでの手順で作成した CloudWatch エージェント設定を使用するように設定できます。
**このソリューションの CloudWatch エージェントをインストールして設定するには**
1. 次のリンクを使用して、CloudFormation **[スタックのクイック作成]** ウィザードを開きます: [https://console.aws.amazon.com/cloudformation/home?\$1/stacks/quickcreate?templateURL=https://aws-observability-solutions-prod-us-east-1.s3.us-east-1.amazonaws.com/CloudWatchAgent/CFN/v1.0.0/cw-agent-installation-template-1.0.0.json](https://console.aws.amazon.com/cloudformation/home?#/stacks/quickcreate?templateURL=https://aws-observability-solutions-prod-us-east-1.s3.us-east-1.amazonaws.com/CloudWatchAgent/CFN/v1.0.0/cw-agent-installation-template-1.0.0.json)。
1. コンソールで選択したリージョンが JVM ワークロードが実行されているリージョンであることを確認します。
1. **[スタック名]** にこのスタックを識別する名前 (**CWAgentInstallationStack** など) を入力します。
1. **[パラメータ]** セクションで、以下を指定します。
1. **[CloudWatchAgentConfigSSM]** に、**AmazonCloudWatch-JVM-Configuration** など、前に作成したエージェント設定の Systems Manager パラメータの名前を入力します。
1. ターゲットインスタンスを選択するには、2 つのオプションがあります。
1. **[InstanceIds]** に、この設定で CloudWatch エージェントをインストールするインスタンス ID のカンマ区切りリストを指定します。1 つのインスタンスまたは複数のインスタンスを一覧表示できます。
1. 大規模にデプロイする場合は、**[TagKey]** とそれに対応する **[TagValue]** を指定して、このタグと値を持つすべての EC2 インスタンスをターゲットにできます。**[TagKey]** を指定する場合は、対応する **[TagValue]** を指定する必要があります。(Auto Scaling グループの場合、Auto Scaling グループ内のすべてのインスタンスにデプロイするには、**[TagKey]** に **aws:autoscaling:groupName** を指定し、**[TagValue]** に Auto Scaling グループ名を指定します。)
**[InstanceIds]** パラメータと **[TagKeys]** パラメータの両方を指定すると、**[InstanceIds]** が優先され、タグは無視されます。
1. 設定を確認し、**[スタックの作成]** を選択します。
まずテンプレートファイルを編集してカスタマイズする場合は、**[スタックの作成ウィザード]** の **[テンプレートファイルのアップロード]** オプションを選択して、編集したテンプレートをアップロードします。詳細については、「[CloudFormation コンソールからスタックを作成する](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-console-create-stack.html)」を参照してください。次のリンクを使用して、テンプレートをダウンロードできます: [https://aws-observability-solutions-prod-us-east-1.s3.us-east-1.amazonaws.com/CloudWatchAgent/CFN/v1.0.0/cw-agent-installation-template-1.0.0.json](https://aws-observability-solutions-prod-us-east-1.s3.us-east-1.amazonaws.com/CloudWatchAgent/CFN/v1.0.0/cw-agent-installation-template-1.0.0.json)。
**注記**
このステップが完了すると、この Systems Manager パラメータは、ターゲットインスタンスで実行されている CloudWatch エージェントに関連付けられます。これにより、以下のように処理されます。
Systems Manager パラメータが削除されると、エージェントは停止します。
Systems Manager パラメータを編集すると、設定の変更はスケジュールされた頻度 (デフォルトで 30 日) でエージェントに自動的に適用されます。
この Systems Manager パラメータに変更をすぐに適用する場合は、このステップを再度実行する必要があります。関連付けの詳細については、「[Systems Manager の関連付けの使用](https://docs.aws.amazon.com/systems-manager/latest/userguide/state-manager-associations.html)」を参照してください。
### ステップ 4: エージェントのセットアップが正しく設定されていることを確認する
CloudWatch エージェントがインストールされているかどうかは、「[CloudWatch エージェントが実行されていることを確認する](troubleshooting-CloudWatch-Agent.md#CloudWatch-Agent-troubleshooting-verify-running)」の手順に従って確認できます。CloudWatch エージェントがインストールされておらず、実行されていない場合は、すべてが正しく設定されていることを確認してください。
+ 「[ステップ 1: ターゲット EC2 インスタンスに必要な IAM アクセス許可があることを確認する](#Solution-JVM-Agent-Step1)」の説明に従って、EC2 インスタンスに正しいアクセス許可を持つロールがアタッチされていることを確認してください。
+ Systems Manager パラメータの JSON が正しく設定されていることを確認してください。「[CloudFormation での CloudWatch エージェントのインストールのトラブルシューティング](Install-CloudWatch-Agent-New-Instances-CloudFormation.md#CloudWatch-Agent-CloudFormation-troubleshooting)」のステップを実行してください。
すべてが正しく設定されている場合は、JVM メトリクスが CloudWatch に公開されているはずです。CloudWatch コンソールをチェックして、公開されていることを確認します。
**JVM メトリクスが CloudWatch に公開されていることを確認するには**
1. CloudWatch コンソールの [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/) を開いてください。
1. **[メトリクス]**、**[すべてのメトリクス]** を選択します。
1. ソリューションをデプロイしたリージョンを選択したことを確認し、**[カスタム名前空間]**、**[CWAgent]** を選択します。
1. `jvm.memory.heap.used` など、「[JVM ホストのエージェント設定](#Solution-JVM-Agent-Config)」で説明されているメトリクスを検索します。これらのメトリクスの結果が表示された場合、メトリクスは CloudWatch に公開されています。
## JVM ソリューションダッシュボードを作成する
このソリューションが提供するダッシュボードには、サーバーの基盤となる Java 仮想マシン (JVM) のメトリクスが表示されます。すべてのインスタンスでメトリクスを集約して表示することで JVM の概要が示され、全体的なヘルスと運用状態の概要がわかります。さらに、ダッシュボードには、各メトリクスに寄与する上位の要因 (メトリクスウィジェットあたり上位 10 件) の内訳が表示されます。これにより、観測されたメトリクスに大きく寄与する外れ値やインスタンスをすばやく特定できます。
ソリューションダッシュボードには EC2 メトリクスは表示されません。EC2 メトリクスを表示するには、EC2 自動ダッシュボードを使用して EC2 からのメトリクスを表示し、EC2 コンソールダッシュボードを使用して CloudWatch エージェントによって収集された EC2 メトリクスを表示する必要があります。AWS サービスの自動ダッシュボードの詳細については、「[単一の AWS サービスの CloudWatch ダッシュボードの表示](CloudWatch_Automatic_Dashboards_Focus_Service.md)」を参照してください。
ダッシュボードを作成するには、以下のオプションを使用できます。
+ CloudWatch コンソールを使用してダッシュボードを作成します。
+ AWS CloudFormation コンソールを使用してダッシュボードをデプロイします。
+ AWS CloudFormation インフラストラクチャをコードとしてダウンロードし、継続的インテグレーション (CI) オートメーションの一部として統合します。
CloudWatch コンソールを使用してダッシュボードを作成すると、実際に作成して課金される前にダッシュボードをプレビューできます。
**注記**
このソリューションで CloudFormation を使用して作成されたダッシュボードには、ソリューションがデプロイされたリージョンのメトリクスが表示されます。JVM メトリクスが公開されるリージョンに CloudFormation スタックを必ず作成してください。
CloudWatch エージェントメトリクスが `CWAgent` とは異なる名前空間に公開されている場合 (カスタマイズされた名前空間を指定した場合など)、CloudFormation 設定を変更して、使用しているカスタマイズされた名前空間に `CWAgent` を置き換える必要があります。
**CloudWatch コンソールを使用してダッシュボードを作成するには**
**注記**
現在、ソリューションダッシュボードには、最新の Java バージョンのデフォルトコレクターである G1 ガベージコレクターのガベージコレクション関連のメトリクスのみが表示されます。別のガベージコレクションアルゴリズムを使用している場合、ガベージコレクションに関連するウィジェットは空です。ただし、ダッシュボードの CloudFormation テンプレートを変更し、適切なガベージコレクションタイプをガベージコレクション関連のメトリクスの名前ディメンションに適用することで、これらのウィジェットをカスタマイズできます。例えば、並列ガベージコレクションを使用している場合は、ガベージコレクション数メトリクス `jvm.gc.collections.count` の **name=\$1"G1 Young Generation\$1"** を **name=\$1"Parallel GC\$1"** に変更します。
1. 次のリンクを使用して CloudWatch コンソール **[ダッシュボードの作成]** を開きます: [https://console.aws.amazon.com/cloudwatch/home?\$1dashboards?dashboardTemplate=JvmOnEc2&referrer=os-catalog](https://console.aws.amazon.com/cloudwatch/home?#dashboards?dashboardTemplate=JvmOnEc2&referrer=os-catalog)。
1. コンソールで選択したリージョンが JVM ワークロードが実行されているリージョンであることを確認します。
1. ダッシュボードの名前を入力し、**[ダッシュボードの作成]** を選択します。
このダッシュボードを他のリージョンの類似のダッシュボードと簡単に区別するために、**JVMDashboard-us-east-1** のように、ダッシュボード名にリージョン名を含めることをお勧めします。
1. ダッシュボードをプレビューし、**[保存]** を選択してダッシュボードを作成します。
**CloudFormation を使用してダッシュボードを作成するには**
1. 次のリンクを使用して、CloudFormation **[スタックのクイック作成]** ウィザードを開きます: [https://console.aws.amazon.com/cloudformation/home?\$1/stacks/quickcreate?templateURL=https://aws-observability-solutions-prod-us-east-1.s3.us-east-1.amazonaws.com/JVM\$1EC2/CloudWatch/CFN/v1.0.0/dashboard-template-1.0.0.json](https://console.aws.amazon.com/cloudformation/home?#/stacks/quickcreate?templateURL=https://aws-observability-solutions-prod-us-east-1.s3.us-east-1.amazonaws.com/JVM_EC2/CloudWatch/CFN/v1.0.0/dashboard-template-1.0.0.json)。
1. コンソールで選択したリージョンが JVM ワークロードが実行されているリージョンであることを確認します。
1. **[スタック名]** にこのスタックを識別する名前 (**JVMDashboardStack** など) を入力します。
1. **[パラメータ]** セクションで、**[DashboardName]** パラメータにダッシュボードの名前を指定します。
このダッシュボードを他のリージョンの類似のダッシュボードと簡単に区別するために、**JVMDashboard-us-east-1** のように、ダッシュボード名にリージョン名を含めることをお勧めします。
1. **[機能と変換]** で、変換のためのアクセス機能を承認します。CloudFormation は IAM リソースを追加しないことに注意してください。
1. 設定を確認し、**[スタックの作成]** を選択します。
1. スタックステータスが **CREATE\$1COMPLETE** になったら、作成したスタックの **[リソース]** タブを選択し、**[物理 ID]** のリンクを選択してダッシュボードに移動します。コンソールの左側のナビゲーションペインで **[ダッシュボード]** を選択し、**[カスタムダッシュボード]** でダッシュボード名を検索することで、CloudWatch コンソールでダッシュボードにアクセスすることもできます。
何らかの目的でテンプレートファイルを編集してカスタマイズする場合は、**[スタックの作成ウィザード]** の **[テンプレートファイルのアップロード]** オプションを使用して、編集したテンプレートをアップロードできます。詳細については、「[CloudFormation コンソールからスタックを作成する](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-console-create-stack.html)」を参照してください。次のリンクを使用して、テンプレートをダウンロードできます: [https://aws-observability-solutions-prod-us-east-1.s3.us-east-1.amazonaws.com/JVM\$1EC2/CloudWatch/CFN/v1.0.0/dashboard-template-1.0.0.json](https://aws-observability-solutions-prod-us-east-1.s3.us-east-1.amazonaws.com/JVM_EC2/CloudWatch/CFN/v1.0.0/dashboard-template-1.0.0.json)。
**注記**
現在、ソリューションダッシュボードには、最新の Java バージョンのデフォルトコレクターである G1 ガベージコレクターのガベージコレクション関連のメトリクスのみが表示されます。別のガベージコレクションアルゴリズムを使用している場合、ガベージコレクションに関連するウィジェットは空です。ただし、ダッシュボードの CloudFormation テンプレートを変更し、適切なガベージコレクションタイプをガベージコレクション関連のメトリクスの名前ディメンションに適用することで、これらのウィジェットをカスタマイズできます。例えば、並列ガベージコレクションを使用している場合は、ガベージコレクション数メトリクス `jvm.gc.collections.count` の **name=\$1"G1 Young Generation\$1"** を **name=\$1"Parallel GC\$1"** に変更します。
### JVM ダッシュボードの使用を開始する
新しい JVM ダッシュボードで試すことができるタスクをいくつか示します。これらのタスクにより、ダッシュボードが正しく機能していることの検証が可能になり、JVM プロセスグループをモニタリングするためにダッシュボードを実際に使用する経験ができます。これらを試すと、ダッシュボードの操作に慣れ、可視化されたメトリクスを解釈できるようになっていきます。
**プロセスグループを選択する**
**[JVM プロセスグループ名]** ドロップダウンリストを使用して、モニタリングするプロセスグループを選択します。ダッシュボードは自動的に更新されて、選択したプロセスグループのメトリクスが表示されます。複数の Java アプリケーションまたは環境がある場合、それぞれが別々のプロセスグループとして表される場合があります。適切なプロセスグループを選択すると、分析するアプリケーションまたは環境に固有のメトリクスを表示できます。
**メモリ使用率を確認する**
ダッシュボードの概要セクションから、**[ヒープメモリ使用率 (%)]** ウィジェットと **[非ヒープメモリ使用率 (%)]** ウィジェットを見つけます。これらは、選択したプロセスグループ内のすべての JVM で使用されているヒープメモリと非ヒープメモリの使用率を示しています。使用率が高いと、メモリにプレッシャーがかかっている可能性があります。これはパフォーマンスの問題や `OutOfMemoryError` 例外につながる可能性があります。また、**[ホスト別のメモリ使用率]** でホスト別のヒープ使用率の内訳を確認して、使用率の高いホストをチェックすることもできます。
**スレッドとロードされたクラスを分析する**
**[ホスト別のスレッドとロードされたクラス]** セクションで、**[上位 10 のスレッド数]** ウィジェットと **[ロードされた上位 10 のクラス]** ウィジェットを見つけます。スレッド数またはクラス数が他と比較して異常に多い JVM がないか探します。スレッドが多すぎることは、スレッドリークや過剰な同時実行を示している可能性があり、ロードされたクラスが多いことは、クラスローダーリークや非効率的な動的クラス生成を示している可能性があります。
**ガベージコレクションの問題を特定する**
**[ガベージコレクション]** セクションで、**Young**、**Concurrent**、**Mixed** の各ガベージコレクタータイプに対して、**[1 分あたりのガベージコレクションの呼び出し上位 10 件]** ウィジェットと、**[ガベージコレクションの持続時間上位 10 件**] ウィジェットを見つけます。他と比較して非常にコレクションが多い JVM やコレクションの持続時間が長い JVM がないか探します。これは、設定の問題やメモリリークを示している可能性があります。
# CloudWatch ソリューション: Amazon EC2 での NGINX ワークロード
このソリューションは、EC2 インスタンスで実行されている NGINX アプリケーション用の CloudWatch エージェントを使用して、すぐに使用できるメトリクス収集を設定するのに役立ちます。すべての CloudWatch オブザーバビリティソリューションの一般的な情報については、「[CloudWatch オブザーバビリティソリューション](Monitoring-Solutions.md)」を参照してください。
**Topics**
+ [要件](#Solution-NGINX-On-EC2-Requirements)
+ [利点](#Solution-NGINX-On-EC2-Benefits)
+ [コスト](#Solution-NGINX-On-EC2-Costs)
+ [このソリューションの CloudWatch エージェント設定](#Solution-NGINX-CloudWatch-Agent)
+ [ソリューションにエージェントをデプロイする](#Solution-NGINX-Agent-Deploy)
+ [NGINX ソリューションダッシュボードを作成する](#Solution-NGINX-Dashboard)
## 要件
このソリューションは、以下の条件に適しています。
+ サポートされているバージョン: NGINX バージョン 1.24
+ コンピューティング: Amazon EC2
+ 特定の AWS リージョン のすべての NGINX ワークロードで最大 500 個の EC2 インスタンスをサポート
+ CloudWatch エージェントの最新バージョン
+ Prometheus Exporter: nginxinc/nginx-prometheus-exporter (Apache 2.0 ライセンス)
+ EC2 インスタンスにインストールされた SSM エージェント
**注記**
AWS Systems Manager (SSM エージェント) は、AWS および信頼できるサードパーティーが提供している一部の [Amazon マシンイメージ (AMI)](https://docs.aws.amazon.com/systems-manager/latest/userguide/ami-preinstalled-agent.html) にプリインストールされています。エージェントがインストールされていない場合は、使用しているオペレーティングシステムタイプの手順を使用して、手動でインストールできます。
[Linux 用 EC2 インスタンスに SSM Agent を手動でインストールおよびアンインストールする](https://docs.aws.amazon.com/systems-manager/latest/userguide/manually-install-ssm-agent-linux.html)
[macOS 用の EC2 インスタンスに SSM Agent を手動でインストールおよびアンインストールする](https://docs.aws.amazon.com/systems-manager/latest/userguide/manually-install-ssm-agent-macos.html)
[Windows Server 用の EC2 インスタンスに SSM Agent を手動でインストールおよびアンインストールする](https://docs.aws.amazon.com/systems-manager/latest/userguide/manually-install-ssm-agent-windows.html)
## 利点
このソリューションでは NGINX をモニタリングしているため、以下のユースケースに役立つインサイトが得られます。
+ 接続メトリクスを確認して、潜在的なボトルネック、接続の問題、予期しない使用状況を特定します。
+ HTTP リクエストボリュームを分析して、NGINX の全体的なトラフィック負荷を把握します。
ソリューションの主な利点を以下に示します。
+ CloudWatch エージェント設定を使用して NGINX のメトリクス収集を自動化し、手動計測をなくします。
+ NGINX メトリクス用の事前設定済みの統合 CloudWatch ダッシュボードが用意されています。ダッシュボードは、ダッシュボードを初めて作成するときにメトリクスが存在しない場合でも、ソリューションを使用して設定された新しい NGINX EC2 インスタンスからのメトリクスを自動的に処理します。
以下の画像は、このソリューションのダッシュボードの例です。
![\[NGINX ソリューションのダッシュボードの例。\]](http://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/images/NGINXDashboard.png)
## コスト
このソリューションは、アカウントでリソースを作成して使用します。標準使用には料金がかかります。これには以下を含みます。
+ このソリューションのために CloudWatch エージェントによって収集されたすべてのメトリクスは、埋め込みメトリクス形式 (EMF) を使用して CloudWatch Logs に公開されます。これらの CloudWatch ログは、ボリュームと保持期間に基づいて課金されます。したがって、このソリューションの **PutMetricData** API コールに対して課金されることはありません。ログから抽出して取り込まれたメトリクスは、カスタムメトリクスとして課金されます。このソリューションで使用されるメトリクスの数は、EC2 ホストの数によって異なります。
+ ソリューション用に設定された各 NGINX EC2 ホストは、合計 8 つのメトリクスを公開します。
+ 1 つのカスタムダッシュボード。
CloudWatch の料金の詳細については、「[Amazon CloudWatch の料金](https://aws.amazon.com/cloudwatch/pricing/)」をご覧ください。
料金計算ツールを使用すると、このソリューションを使用するためのおよその月額コストを見積もることができます。
**料金計算ツールを使用して毎月のソリューションのコストを見積もるには**
1. [Amazon CloudWatch 料金計算ツール](https://calculator.aws/#/createCalculator/CloudWatch)を開きます。
1. **[リージョンの選択]** では、ソリューションをデプロイする AWS リージョンを選択します。
1. **[メトリクス]** セクションの **[メトリクスの数]** に **8 \$1 number of EC2 instances configured for this solution** を入力します。
1. **[ログ]** セクションの **[標準ログ: 取り込まれたデータ]** に、すべての EC2 ホストで CloudWatch Agent によって生成される 1 日あたりのログのボリューム推定値を入力します。例えば、5 つの EC2 インスタンスは 1 日あたり 1000 バイト未満しか生成しません。設定したら、CloudWatch Logs から提供される ` IncomingBytes` メトリクスを使用してバイト使用量を確認できます。必ず適切なロググループを選択してください。
1. **[ログ]** セクションの **[ログストレージ/アーカイブ (標準および公開ログ)]** で、**Yes to Store Logs: Assuming 1 month retention** を選択します。保持期間にカスタム変更を加える場合は、この値を変更します。
1. **[ダッシュボードとアラーム]** セクションの **[ダッシュボードの数]** に「**1**」と入力します。
1. 毎月の見積コストは、料金計算ツールの下部に表示されます。
## このソリューションの CloudWatch エージェント設定
CloudWatch エージェントは、サーバー上およびコンテナ化された環境で継続的かつ自律的に実行されるソフトウェアです。インフラストラクチャとアプリケーションからメトリクス、ログ、トレースを収集し、CloudWatch と X-Ray に送信します。
CloudWatch エージェントの詳細については、「[CloudWatch エージェントを使用してメトリクス、ログ、トレースを収集する](Install-CloudWatch-Agent.md)」を参照してください。
このソリューションのエージェント設定では、NGINX ワークロードのモニタリングと観測を開始するのに役立つ一連のメトリクスを収集します。CloudWatch エージェントは、ダッシュボードにデフォルトで表示されるよりも多くの NGINX メトリクスを収集するように設定できます。収集できるすべての NGINX メトリクスのリストについては、「[NGINX OSS のメトリクス](https://github.com/nginxinc/nginx-prometheus-exporter?tab=readme-ov-file#exported-metrics)」を参照してください。
CloudWatch エージェントを設定する前に、まずメトリクスを公開するように NGINX を設定する必要があります。次に、サードパーティーの Prometheus メトリクスエクスポーターをインストールして設定する必要があります。
### NGINX メトリクスを公開する
**注記**
次のコマンドは、Linux 用です。Windows Server の同等のコマンドについては、[Windows 用 NGINX に関するページ](https://nginx.org/en/docs/windows.html)を確認してください。
まず、`stub_status` モジュールを有効にする必要があります。NGINX 設定ファイルに新しいロケーションブロックを追加します。NGINX の `stub_status` モジュールを有効にするには、`nginx.conf` の `server` ブロックに次の行を追加します。
```
location /nginx_status {
stub_status on;
allow 127.0.0.1; # Allow only localhost to access
deny all; # Deny all other IPs
}
```
NGINX を再ロードする前に、NGINX 設定を次のように検証します。
```
sudo nginx -t
```
この検証コマンドは、ウェブサイトがダウンする原因となる予期しないエラーを防ぐのに役立ちます。次の例は、正常なレスポンスを示します。
```
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
```
更新された設定が正常に検証されたら、次のように NGINX を再ロードします (出力はありません)。
```
sudo systemctl reload nginx
```
このコマンドは、NGINX プロセスに設定を再ロードするように指示します。再ロードは、フル再起動より簡明です。再ロードでは、新しい設定で新しいワーカープロセスを開始し、古いワーカープロセスを的確にシャットダウンします。
NGINX ステータスエンドポイントを次のようにテストします。
```
curl http://127.0.0.1/nginx_status
```
次の例は、正常なレスポンスを示します。
```
Active connections: 1
server accepts handled requests
6 6 6
Reading: 0 Writing: 1 Waiting: 0
```
次の例は、正常でないレスポンスを示しています (続行する前にこれまでの手順を確認してください)。
```
The page is not found
...
```
### Prometheus メトリクスエクスポーターを設定する
[公式 GitHub リポジトリ](https://github.com/nginxinc/nginx-prometheus-exporter/releases)から最新の NGINX Prometheus エクスポーターリリースをダウンロードします。プラットフォームに適合するバイナリをダウンロードする必要があります。
次の例は、AMD64 のコマンドを示しています。
```
cd /tmp
wget https://github.com/nginxinc/nginx-prometheus-exporter/releases/download/v1.3.0/nginx-prometheus-exporter_1.3.0_linux_amd64.tar.gz
tar -xzvf nginx-prometheus-exporter_1.3.0_linux_amd64.tar.gz
sudo cp nginx-prometheus-exporter /usr/local/bin/
rm /tmp/nginx-prometheus-exporter*
```
Prometheus エクスポーターを実行して、NGINX スタブステータスページに移動します。
```
nohup /usr/local/bin/nginx-prometheus-exporter -nginx.scrape-uri http://127.0.0.1/nginx_status &>/dev/null &
```
次の例は、レスポンス (バックグラウンドジョブ ID と PID) を示しています。
```
[1] 74699
```
### NGINX Prometheus エンドポイントをテストする
NGINX Prometheus エクスポーターが関連するメトリクスの公開を開始したことを次のように検証します。
```
curl http://localhost:port-number/metrics
```
次の例は、正常なレスポンスを示します。
```
# HELP go_gc_duration_seconds A summary of the pause duration of garbage collection cycles.
# TYPE go_gc_duration_seconds summary
go_gc_duration_seconds{quantile="0"} 0
go_gc_duration_seconds{quantile="0.25"} 0
...
# HELP nginx_connections_accepted Accepted client connections
# TYPE nginx_connections_accepted counter
nginx_connections_accepted 14
# HELP nginx_connections_active Active client connections
# TYPE nginx_connections_active gauge
nginx_connections_active 1
...
# TYPE promhttp_metric_handler_requests_total counter
promhttp_metric_handler_requests_total{code="200"} 1
promhttp_metric_handler_requests_total{code="500"} 0
promhttp_metric_handler_requests_total{code="503"} 0
```
### このソリューションのエージェント設定
エージェントによって収集されるメトリクスは、エージェント設定で定義されます。このソリューションには、ソリューションのダッシュボードに適したディメンションで推奨メトリクスを収集するためのエージェント設定が用意されています。
ソリューションをデプロイする手順については、「[ソリューションにエージェントをデプロイする](#Solution-NGINX-Agent-Deploy)」で後述します。以下の情報は、環境に合わせてエージェント設定をカスタマイズする方法を理解するのに役立ちます。
Prometheus エクスポーターで使用されるポート番号など、環境に合わせてエージェントと Prometheus の設定の一部をカスタマイズする必要があります。
Prometheus エクスポーターで使用されるポートは、次のコマンドを使用して確認できます。
```
sudo netstat -antp | grep nginx-prom
```
次の例は、レスポンスを示しています (ポート値 9113 を確認)。
```
tcp6 0 0 :::9113 :::* LISTEN 76398/nginx-prometh
```
### NGINX ホストのエージェント設定
Prometheus モニターリングを使用した CloudWatch エージェントには、Prometheus メトリクスをスクレイプするために 2 つの設定が必要です。各設定は、「[ステップ 2: 推奨 CloudWatch エージェント設定ファイルを Systems Manager パラメータストアに保存する](#Solution-NGINX-Agent-Step2)」で後述するように、SSM のパラメータストアに別々のパラメータとして保存されます。
最初の設定は、Prometheus の「[scrape\$1config](https://prometheus.io/docs/prometheus/latest/configuration/configuration/#scrape_config)」ドキュメントに記載されているように、Prometheus エクスポーター用です。2 番目の設定は、CloudWatch エージェント用です。
**Prometheus の設定**
*port-number* をサーバーのポートに置き換えます。
```
global:
scrape_interval: 30s
scrape_timeout: 10s
scrape_configs:
- job_name: 'nginx'
metrics_path: /metrics
static_configs:
- targets: ['localhost:port-number']
ec2_sd_configs:
- port: port-number
relabel_configs:
- source_labels: ['__meta_ec2_instance_id']
target_label: InstanceId
metric_relabel_configs:
- source_labels: ['__name__']
regex: 'nginx_up|nginx_http_requests_total|nginx_connections_.*'
action: keep
```
**CloudWatch エージェントの設定**
以前の CloudWatch エージェント設定では、これらのメトリクスは[埋め込みメトリクス形式 (EMF)](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch_Embedded_Metric_Format_Specification.html) を使用して CloudWatch Logs を介して公開されていました。これらのログは、ロググループ ` nginx` を使用するように設定されています。*log\$1group\$1name* は、CloudWatch ログを表す別の名前にカスタマイズできます。
Windows Server を使用している場合は、次の設定の *prometheus\$1config\$1path* を `C:\\ProgramData\\Amazon\\AmazonCloudWatchAgent\\prometheus.yaml` に設定します。
```
{
"agent": {
"metrics_collection_interval": 60
},
"logs": {
"metrics_collected": {
"prometheus": {
"log_group_name": "nginx",
"prometheus_config_path": "/opt/aws/amazon-cloudwatch-agent/etc/prometheus.yaml",
"emf_processor": {
"metric_declaration_dedup": true,
"metric_namespace": "CWAgent",
"metric_declaration":[
{
"source_labels":["InstanceId"],
"metric_selectors":["nginx_up", "nginx_http_requests_total", "nginx_connections*"],
"dimensions": [["InstanceId"]]
}
]
}
}
}
}
}
```
## ソリューションにエージェントをデプロイする
ユースケースに応じて、CloudWatch エージェントをインストールするためのいくつかのアプローチがあります。このソリューションには Systems Manager を使用することをお勧めします。これにより、コンソール操作機能が提供され、1 つの AWS アカウント内のマネージドサーバーのフリートの管理が簡単になります。このセクションの手順では Systems Manager を使用し、CloudWatch エージェントを既存の設定で実行していない場合を対象としています。CloudWatch エージェントが実行されているかどうかは、「[CloudWatch エージェントが実行されていることを確認する](troubleshooting-CloudWatch-Agent.md#CloudWatch-Agent-troubleshooting-verify-running)」の手順に従って確認できます。
ワークロードがデプロイされている EC2 ホストで CloudWatch エージェントを既に実行していて、エージェント設定を管理している場合は、このセクションの手順をスキップし、既存のデプロイメカニズムに従って設定を更新できます。新しい CloudWatch エージェントと Prometheus の設定を既存の設定とマージしてから、マージされた設定をデプロイしてください。Systems Manager を使用して CloudWatch エージェントの設定を保存および管理している場合は、設定を既存のパラメータ値にマージできます。詳細については、「[CloudWatch エージェント設定ファイルの管理](https://docs.aws.amazon.com/prescriptive-guidance/latest/implementing-logging-monitoring-cloudwatch/create-store-cloudwatch-configurations.html)」を参照してください。
**注記**
Systems Manager を使用して次の CloudWatch エージェント設定をデプロイすると、EC2 インスタンスの既存の CloudWatch エージェント設定がある場合は置き換えられるか、上書きされます。独自の環境やユースケースに合わせてこの設定を変更できます。設定で定義されているメトリクスは、ソリューションを提供するダッシュボードに最小限必要なものです。
このデプロイプロセスには、以下のステップが含まれます。
+ ステップ 1: ターゲット EC2 インスタンスに必要な IAM アクセス許可があることを確認します。
+ ステップ 2: 推奨エージェント設定ファイルを Systems Manager パラメータストアに保存します。
+ ステップ 3: CloudFormation スタックを使用して 1 つまたは複数の EC2 インスタンスに CloudWatch エージェントをインストールします。
+ ステップ 4: エージェントのセットアップが正しく設定されていることを確認します。
### ステップ 1: ターゲット EC2 インスタンスに必要な IAM アクセス許可があることを確認する
CloudWatch エージェントをインストールして設定するためのアクセス許可を Systems Manager に付与する必要があります。EC2 インスタンスから CloudWatch にテレメトリを発行するアクセス許可を CloudWatch エージェントに付与する必要があります。また、CloudWatch エージェント EC2 読み取りアクセス権を付与する必要もあります。EC2 InstanceId をメトリクスディメンションとして追加するには、EC2 読み取りアクセス権が必要です。この追加要件は、EC2 Service Discovery を介して ` __meta_ec2_instance_id` を使用するため、上記で説明したように `prometheus.yaml` によって扱われます。
インスタンスにアタッチされた IAM ロールに **CloudWatchAgentServerPolicy**、**AmazonSSMManagedInstanceCore**、および **AmazonEC2ReadOnlyAccess** IAM ポリシーがアタッチされていることを確認します。
+ ロールを作成したら、ロールを EC2 インスタンスにアタッチします。EC2 インスタンスにロールをアタッチするには、「[インスタンスへの IAM ロールのアタッチ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/attach-iam-role.html)」の手順に従います。
### ステップ 2: 推奨 CloudWatch エージェント設定ファイルを Systems Manager パラメータストアに保存する
パラメータストアでは、設定パラメータを安全に保存および管理することで EC2 インスタンスへの CloudWatch エージェントのインストールが簡素化され、ハードコーディングされた値が不要になります。これにより、デプロイプロセスがより安全で柔軟になり、集中管理が可能になり、複数のインスタンスで設定を簡単に更新できるようになります。
以下の手順を使用して、パラメータストアに推奨 CloudWatch エージェント設定ファイルをパラメータとして保存します。
**CloudWatch エージェント設定ファイルをパラメータとして作成するには**
1. AWS Systems Manager コンソール ([https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)) を開きます。
1. コンソールで選択したリージョンが NGINX が実行されているリージョンであることを確認します。
1. ナビゲーションペインで **[アプリケーション管理]**、**[パラメータストア]** を選択します。
1. 以下の手順に従って、設定の新しいパラメータを作成します。
1. **[パラメータの作成]** を選択します。
1. **[名前]** ボックスに、後のステップで CloudWatch エージェント設定ファイルを参照するために使用する名前を入力します。例えば、** AmazonCloudWatch-NGINX-CloudWatchAgent-Configuration**。
1. (オプション) **[説明]** ボックスにパラメータの説明を入力します。
1. **[パラメータ階層]** で、**[標準]** を選択します。
1. **[型]** で、**[文字列]** を選択します。
1. **[データ型]** で、**[テキスト]** を選択します。
1. **[値]** ボックスに、[NGINX ホストのエージェント設定](#Solution-NGINX-Agent-Config) にリストされた対応する JSON ブロックを貼り付けます。必要に応じてカスタマイズしてください。例えば、関連する `log_group_name`。
1. **[パラメータの作成]** を選択します。
**Prometheus 設定ファイルをパラメータとして作成するには**
1. AWS Systems Manager コンソール ([https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)) を開きます。
1. ナビゲーションペインで **[アプリケーション管理]**、**[パラメータストア]** を選択します。
1. 以下の手順に従って、設定の新しいパラメータを作成します。
1. **[パラメータの作成]** を選択します。
1. **[名前]** ボックスに、後のステップで設定ファイルを参照するために使用する名前を入力します。例えば、** AmazonCloudWatch-NGINX-Prometheus-Configuration**。
1. (オプション) **[説明]** ボックスにパラメータの説明を入力します。
1. **[パラメータ階層]** で、**[標準]** を選択します。
1. **[型]** で、**[文字列]** を選択します。
1. **[データ型]** で、**[テキスト]** を選択します。
1. **[値]** ボックスに、[NGINX ホストのエージェント設定](#Solution-NGINX-Agent-Config) にリストされた対応する YAML ブロックを貼り付けます。必要に応じてカスタマイズしてください。例えば、`targets` に従った関連するポート番号。
1. **[パラメータの作成]** を選択します。
### ステップ 3: CloudWatch エージェントをインストールし、CloudFormation テンプレートを使用して設定を適用する
AWS CloudFormation を使用してエージェントをインストールし、これまでの手順で作成した CloudWatch エージェント設定を使用するように設定できます。
**このソリューションの CloudWatch エージェントをインストールして設定するには**
1. 次のリンクを使用して、CloudFormation **[スタックのクイック作成]** ウィザードを開きます: [https://console.aws.amazon.com/cloudformation/home?\$1/stacks/quickcreate?templateURL=https://aws-observability-solutions-prod-us-east-1.s3.us-east-1.amazonaws.com/CloudWatchAgent/CFN/v1.0.0/cw-agent-installation-template-with-prometheus-config-1.0.0.json](https://console.aws.amazon.com/cloudformation/home?#/stacks/quickcreate?templateURL=https://aws-observability-solutions-prod-us-east-1.s3.us-east-1.amazonaws.com/CloudWatchAgent/CFN/v1.0.0/cw-agent-installation-template-with-prometheus-config-1.0.0.json)。
1. コンソールで選択したリージョンが NGINX ワークロードが実行されているリージョンであることを確認します。
1. **[スタック名]** にこのスタックを識別する名前 (** CWAgentInstallationStack** など) を入力します。
1. **[パラメータ]** セクションで、以下を指定します。
1. **[CloudWatchAgentConfigSSM]** に、** AmazonCloudWatch-NGINX-CloudWatchAgent-Configuration** など、前に作成したエージェント設定の AWS Systems Manager パラメータの名前を入力します。
1. **[PrometheusConfigSSM]** に、** AmazonCloudWatch-NGINX-Prometheus-Configuration** など、前に作成したエージェント設定の AWS Systems Manager パラメータの名前を入力します。
1. ターゲットインスタンスを選択するには、2 つのオプションがあります。
1. **[InstanceIds]** に、この設定で CloudWatch エージェントをインストールするインスタンス ID のカンマ区切りリストを指定します。1 つのインスタンスまたは複数のインスタンスを一覧表示できます。
1. 大規模にデプロイする場合は、**[TagKey]** とそれに対応する **[TagValue]** を指定して、このタグと値を持つすべての EC2 インスタンスをターゲットにできます。**[TagKey]** を指定する場合は、対応する **[TagValue]** を指定する必要があります。(Auto Scaling グループの場合、Auto Scaling グループ内のすべてのインスタンスにデプロイするには、**[TagKey]** に **aws:autoscaling:groupName** を指定し、**[TagValue]** に Auto Scaling グループ名を指定します。)
1. 設定を確認し、**[スタックの作成]** を選択します。
まずテンプレートファイルを編集してカスタマイズする場合は、**[スタックの作成ウィザード]** の **[テンプレートファイルのアップロード]** オプションを選択して、編集したテンプレートをアップロードします。詳細については、「[CloudFormation コンソールからスタックを作成する](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-console-create-stack.html)」を参照してください。次のリンクを使用して、テンプレートをダウンロードできます: [https://aws-observability-solutions-prod-us-east-1.s3.us-east-1.amazonaws.com/CloudWatchAgent/CFN/v1.0.0/cw-agent-installation-template-with-prometheus-config-1.0.0.json]( https://aws-observability-solutions-prod-us-east-1.s3.us-east-1.amazonaws.com/CloudWatchAgent/CFN/v1.0.0/cw-agent-installation-template-with-prometheus-config-1.0.0.json)
**注記**
このステップが完了すると、この Systems Manager パラメータは、ターゲットインスタンスで実行されている CloudWatch エージェントに関連付けられます。これにより、以下のように処理されます。
Systems Manager パラメータが削除されると、エージェントは停止します。
Systems Manager パラメータを編集すると、設定の変更はスケジュールされた頻度 (デフォルトで 30 日) でエージェントに自動的に適用されます。
この Systems Manager パラメータに変更をすぐに適用する場合は、このステップを再度実行する必要があります。関連付けの詳細については、「[Systems Manager の関連付けの使用](https://docs.aws.amazon.com/systems-manager/latest/userguide/state-manager-associations.html)」を参照してください。
### ステップ 4: エージェントのセットアップが正しく設定されていることを確認する
CloudWatch エージェントがインストールされているかどうかは、「[CloudWatch エージェントが実行されていることを確認する](troubleshooting-CloudWatch-Agent.md#CloudWatch-Agent-troubleshooting-verify-running)」の手順に従って確認できます。CloudWatch エージェントがインストールされておらず、実行されていない場合は、すべてが正しく設定されていることを確認してください。
+ 「[ステップ 1: ターゲット EC2 インスタンスに必要な IAM アクセス許可があることを確認する](#Solution-NGINX-Agent-Step1)」の説明に従って、EC2 インスタンスに正しいアクセス許可を持つロールがアタッチされていることを確認してください。
+ Systems Manager パラメータの JSON が正しく設定されていることを確認してください。「[CloudFormation での CloudWatch エージェントのインストールのトラブルシューティング](Install-CloudWatch-Agent-New-Instances-CloudFormation.md#CloudWatch-Agent-CloudFormation-troubleshooting)」のステップを実行してください。
すべてが正しく設定されている場合は、NGINX メトリクスが CloudWatch に公開されているはずです。CloudWatch コンソールをチェックして、公開されていることを確認します。
**NGINX メトリクスが CloudWatch に公開されていることを確認するには**
1. CloudWatch コンソールの [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/) を開いてください。
1. **[メトリクス]**、**[すべてのメトリクス]** を選択します。
1. ソリューションをデプロイしたリージョンを選択したことを確認し、**[カスタム名前空間]**、**[CWAgent]** を選択します。
1. `nginx_http_requests_total` などのメトリクスを検索します。これらのメトリクスの結果が表示された場合、メトリクスは CloudWatch に公開されています。
## NGINX ソリューションダッシュボードを作成する
このソリューションが提供するダッシュボードは、すべてのインスタンスでメトリクスを集約して表示することで、NGINX ワークロードメトリクスを表示します。ダッシュボードには、各メトリクスに寄与する上位の要因 (メトリクスウィジェットあたり上位 10 件) の内訳が表示されます。これにより、観測されたメトリクスに大きく寄与する外れ値やインスタンスをすばやく特定できます。
ダッシュボードを作成するには、以下のオプションを使用できます。
+ CloudWatch コンソールを使用してダッシュボードを作成します。
+ AWS CloudFormation コンソールを使用してダッシュボードをデプロイします。
+ AWS CloudFormation インフラストラクチャをコードとしてダウンロードし、継続的インテグレーション (CI) オートメーションの一部として統合します。
CloudWatch コンソールを使用してダッシュボードを作成すると、実際に作成して課金される前にダッシュボードをプレビューできます。
**注記**
このソリューションで CloudFormation を使用して作成されたダッシュボードには、ソリューションがデプロイされたリージョンのメトリクスが表示されます。NGINX メトリクスが公開されるリージョンに CloudFormation スタックを必ず作成してください。
CloudWatch エージェント設定で `CWAgent` 以外のカスタム名前空間を指定した場合は、ダッシュボードの CloudFormation テンプレートを変更して、`CWAgent` を、使用しているカスタマイズされた名前空間に置き換える必要があります。
**CloudWatch コンソールを使用してダッシュボードを作成するには**
1. 次のリンクを使用して CloudWatch コンソール **[ダッシュボードの作成]** を開きます: [https://console.aws.amazon.com/cloudwatch/home?\$1dashboards?dashboardTemplate=NginxOnEc2&referrer=os-catalog](https://console.aws.amazon.com/cloudwatch/home?#dashboards?dashboardTemplate=NginxOnEc2&referrer=os-catalog)。
1. コンソールで選択したリージョンが NGINX ワークロードが実行されているリージョンであることを確認します。
1. ダッシュボードの名前を入力し、**[ダッシュボードの作成]** を選択します。
このダッシュボードを他のリージョンの類似のダッシュボードと簡単に区別するために、**NGINXDashboard-us-east-1** のように、ダッシュボード名にリージョン名を含めることをお勧めします。
1. ダッシュボードをプレビューし、**[保存]** を選択してダッシュボードを作成します。
**CloudFormation を使用してダッシュボードを作成するには**
1. 次のリンクを使用して、CloudFormation **[スタックのクイック作成]** ウィザードを開きます: [https://console.aws.amazon.com/cloudformation/home?\$1/stacks/quickcreate?templateURL=https://aws-observability-solutions-prod-us-east-1.s3.us-east-1.amazonaws.com/NGINX\$1EC2/CloudWatch/CFN/v1.0.0/dashboard-template-1.0.0.json](https://console.aws.amazon.com/cloudformation/home?#/stacks/quickcreate?templateURL=https://aws-observability-solutions-prod-us-east-1.s3.us-east-1.amazonaws.com/NGINX_EC2/CloudWatch/CFN/v1.0.0/dashboard-template-1.0.0.json)。
1. コンソールで選択したリージョンが NGINX ワークロードが実行されているリージョンであることを確認します。
1. **[スタック名]** にこのスタックを識別する名前 (** NGINXDashboardStack** など) を入力します。
1. **[パラメータ]** セクションで、**[DashboardName]** パラメータにダッシュボードの名前を指定します。
1. このダッシュボードを他のリージョンの類似のダッシュボードと簡単に区別するために、** NGINXDashboard-us-east-1** のように、ダッシュボード名にリージョン名を含めることをお勧めします。
1. **[機能と変換]** で、変換のためのアクセス機能を承認します。CloudFormation は IAM リソースを追加しないことに注意してください。
1. 設定を確認し、**[スタックの作成]** を選択します。
1. スタックステータスが **CREATE\$1COMPLETE** になったら、作成したスタックの **[リソース]** タブを選択し、**[物理 ID]** のリンクを選択してダッシュボードに移動します。コンソールの左側のナビゲーションペインで **[ダッシュボード]** を選択し、**[カスタムダッシュボード]** でダッシュボード名を検索することで、CloudWatch コンソールでダッシュボードにアクセスすることもできます。
まずテンプレートファイルを編集してカスタマイズする場合は、**[スタックの作成ウィザード]** の **[テンプレートファイルのアップロード]** オプションを選択して、編集したテンプレートをアップロードします。詳細については、「[CloudFormation コンソールからスタックを作成する](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-console-create-stack.html)」を参照してください。次のリンクを使用して、テンプレートをダウンロードできます: [https://aws-observability-solutions-prod-us-east-1.s3.us-east-1.amazonaws.com/NGINX\$1EC2/CloudWatch/CFN/v1.0.0/dashboard-template-1.0.0.json]( https://aws-observability-solutions-prod-us-east-1.s3.us-east-1.amazonaws.com/NGINX_EC2/CloudWatch/CFN/v1.0.0/dashboard-template-1.0.0.json)
### NGINX ダッシュボードの使用を開始する
新しい NGINX ダッシュボードで試すことができるタスクをいくつか示します。これらのタスクにより、ダッシュボードが正しく機能していることの検証が可能になり、NGINX ワークロードをモニタリングするためにダッシュボードを実際に使用する経験ができます。これらを試すと、ダッシュボードの操作に慣れ、可視化されたメトリクスを解釈できるようになっていきます。
**接続メトリクスを確認する**
**[接続]** セクションには、NGINX サーバーのクライアント接続処理に関するインサイトを提供するいくつかの主要なメトリクスがあります。これらの接続メトリクスをモニタリングすると、潜在的なボトルネック、接続の問題、予期しない接続パターンを特定するのに役立ちます。
+ 受け付けられたクライアント接続
+ アクティブなクライアント接続
+ 処理されたクライアント接続
+ リクエストを読み取る接続
+ アイドル状態のクライアント接続
+ レスポンスを書き込む接続
**HTTP リクエストボリュームを分析する**
**[HTTP リクエスト]** セクションの `request` メトリクスは、NGINX サーバーによって処理された HTTP リクエストの合計数を示しています。このメトリクスを経時的に追跡することで、NGINX インフラストラクチャの全体的なトラフィック負荷を把握し、それに応じてリソースの割り当てとスケーリングを計画できます。
# CloudWatch ソリューション: Amazon EC2 での NVIDIA GPU ワークロード
このソリューションは、EC2 インスタンスで実行されている NVIDIA GPU ワークロードの CloudWatch エージェントを使用して、すぐに使用できるメトリクス収集を設定するのに役立ちます。さらに、事前設定された CloudWatch ダッシュボードを設定するのに役立ちます。すべての CloudWatch オブザーバビリティソリューションの一般的な情報については、「[CloudWatch オブザーバビリティソリューション](Monitoring-Solutions.md)」を参照してください。
**Topics**
+ [要件](#Solution-NVIDIA-GPU-On-EC2-Requirements)
+ [利点](#Solution-NVIDIA-GPU-On-EC2-Benefits)
+ [このソリューションの CloudWatch エージェント設定](#Solution-NVIDIA-GPU-CloudWatch-Agent)
+ [ソリューションにエージェントをデプロイする](#Solution-NVIDIA-GPU-Agent-Deploy)
+ [NVIDIA GPU ソリューションダッシュボードを作成する](#Solution-NVIDIA-GPU-Dashboard)
## 要件
このソリューションは、以下の条件に適しています。
+ コンピューティング: Amazon EC2
+ 特定の AWS リージョン内の EC2 インスタンス全体で最大 500 個の GPU をサポート
+ CloudWatch エージェントの最新バージョン
+ EC2 インスタンスにインストールされた SSM エージェント
+ EC2 インスタンスには NVIDIA ドライバーがインストールされている必要があります。NVIDIA ドライバーは、一部の Amazon マシンイメージ (AMI) にプリインストールされています。それ以外の場合は、ドライバーを手動でインストールできます。詳細については、「[Linux インスタンスへの NVIDIA ドライバーのインストール](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/install-nvidia-driver.html)」を参照してください。
**注記**
AWS Systems Manager (SSM エージェント) は、AWS および信頼できるサードパーティーが提供している一部の [Amazon マシンイメージ (AMI)](https://docs.aws.amazon.com/systems-manager/latest/userguide/ami-preinstalled-agent.html) にプリインストールされています。エージェントがインストールされていない場合は、使用しているオペレーティングシステムタイプの手順を使用して、手動でインストールできます。
[Linux 用 EC2 インスタンスに SSM Agent を手動でインストールおよびアンインストールする](https://docs.aws.amazon.com/systems-manager/latest/userguide/manually-install-ssm-agent-linux.html)
[macOS 用の EC2 インスタンスに SSM Agent を手動でインストールおよびアンインストールする](https://docs.aws.amazon.com/systems-manager/latest/userguide/manually-install-ssm-agent-macos.html)
[Windows Server 用の EC2 インスタンスに SSM Agent を手動でインストールおよびアンインストールする](https://docs.aws.amazon.com/systems-manager/latest/userguide/manually-install-ssm-agent-windows.html)
## 利点
このソリューションでは NVIDIA をモニタリングしているため、以下のユースケースに役立つインサイトが得られます。
+ GPU とメモリの使用状況を分析して、パフォーマンスのボトルネックや追加のリソースの必要性を確認します。
+ 温度と消費電力をモニタリングして、GPU が安全の範囲内で動作していることを確認します。
+ GPU ビデオワークロードのエンコーダーパフォーマンスを評価します。
+ 期待される世代と幅の PCIe 接続を確認します。
+ GPU クロック速度をモニタリングして、スケーリングとスロットリングの問題を検出します。
ソリューションの主な利点を以下に示します。
+ CloudWatch エージェント設定を使用して NVIDIA のメトリクス収集を自動化し、手動計測をなくします。
+ NVIDIA メトリクス用の事前設定済みの統合 CloudWatch ダッシュボードが用意されています。ダッシュボードは、ダッシュボードを初めて作成するときにメトリクスが存在しない場合でも、ソリューションを使用して設定された新しい NVIDIA EC2 インスタンスからのメトリクスを自動的に処理します。
以下の画像は、このソリューションのダッシュボードの例です。
![\[NVIDIA GPU ソリューションのダッシュボードの例。\]](http://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/images/NVIDIADashboard.png)
### コスト
このソリューションは、アカウントでリソースを作成して使用します。標準使用には料金がかかります。これには以下を含みます。
+ CloudWatch エージェントによって収集されたすべてのメトリクスは、カスタムメトリクスとして課金されます。このソリューションで使用されるメトリクスの数は、EC2 ホストの数によって異なります。
+ ソリューション用に設定された各 EC2 ホストは、GPU ごとに合計 17 個のメトリクスを公開します。
+ 1 つのカスタムダッシュボード。
+ CloudWatch エージェントによってメトリクスの公開がリクエストされた API オペレーション。このソリューションのデフォルト設定では、CloudWatch エージェントは EC2 ホストごとに毎分 1 回 **PutMetricData** を呼び出します。つまり、**PutMetricData** API は EC2 ホストごとに 30 日の月には `30*24*60=43,200` 回呼び出されます。
CloudWatch の料金の詳細については、「[Amazon CloudWatch の料金](https://aws.amazon.com/cloudwatch/pricing/)」をご覧ください。
料金計算ツールを使用すると、このソリューションを使用するためのおよその月額コストを見積もることができます。
**料金計算ツールを使用して毎月のソリューションのコストを見積もるには**
1. [Amazon CloudWatch 料金計算ツール](https://calculator.aws/#/createCalculator/CloudWatch)を開きます。
1. **[リージョンを選択]** では、ソリューションをデプロイするリージョンを選択します。
1. **[メトリクス]** セクションの **[メトリクスの数]** に **17 \$1 average number of GPUs per EC2 host \$1 number of EC2 instances configured for this solution** を入力します。
1. **[API]** セクションの **[API リクエストの数]** に **43200 \$1 number of EC2 instances configured for this solution** を入力します。
1. デフォルトでは、CloudWatch エージェントは EC2 ホストごとに毎分 1 回 **PutMetricData** オペレーションを実行します。
1. **[ダッシュボードとアラーム]** セクションの **[ダッシュボードの数]** に「**1**」と入力します。
1. 毎月の見積コストは、料金計算ツールの下部に表示されます。
## このソリューションの CloudWatch エージェント設定
CloudWatch エージェントは、サーバー上およびコンテナ化された環境で継続的かつ自律的に実行されるソフトウェアです。インフラストラクチャとアプリケーションからメトリクス、ログ、トレースを収集し、CloudWatch と X-Ray に送信します。
CloudWatch エージェントの詳細については、「[CloudWatch エージェントを使用してメトリクス、ログ、トレースを収集する](Install-CloudWatch-Agent.md)」を参照してください。
このソリューションのエージェント設定では、NVIDIA GPU のモニタリングと観測を開始するのに役立つ一連のメトリクスを収集します。CloudWatch エージェントは、ダッシュボードにデフォルトで表示されるよりも多くの NVIDIA GPU メトリクスを収集するように設定できます。収集できるすべての NVIDIA GPU メトリクスのリストについては、「[NVIDIA GPU メトリクスを収集する](CloudWatch-Agent-NVIDIA-GPU.md)」を参照してください。
### このソリューションのエージェント設定
エージェントによって収集されるメトリクスは、エージェント設定で定義されます。このソリューションには、ソリューションのダッシュボードに適したディメンションで推奨メトリクスを収集するためのエージェント設定が用意されています。
NVIDIA GPU を組み込んだ EC2 インスタンスで次の CloudWatch エージェント設定を使用します。設定は、「[ステップ 2: 推奨 CloudWatch エージェント設定ファイルを Systems Manager パラメータストアに保存する](#Solution-NVIDIA-GPU-Agent-Step2)」で後述するように、SSM のパラメータストアにパラメータとして保存されます。
```
{
"metrics": {
"namespace": "CWAgent",
"append_dimensions": {
"InstanceId": "${aws:InstanceId}"
},
"metrics_collected": {
"nvidia_gpu": {
"measurement": [
"utilization_gpu",
"temperature_gpu",
"power_draw",
"utilization_memory",
"fan_speed",
"memory_total",
"memory_used",
"memory_free",
"pcie_link_gen_current",
"pcie_link_width_current",
"encoder_stats_session_count",
"encoder_stats_average_fps",
"encoder_stats_average_latency",
"clocks_current_graphics",
"clocks_current_sm",
"clocks_current_memory",
"clocks_current_video"
],
"metrics_collection_interval": 60
}
}
},
"force_flush_interval": 60
}
```
## ソリューションにエージェントをデプロイする
ユースケースに応じて、CloudWatch エージェントをインストールするためのいくつかのアプローチがあります。このソリューションには Systems Manager を使用することをお勧めします。これにより、コンソール操作機能が提供され、1 つの AWS アカウント内のマネージドサーバーのフリートの管理が簡単になります。このセクションの手順では Systems Manager を使用し、CloudWatch エージェントを既存の設定で実行していない場合を対象としています。CloudWatch エージェントが実行されているかどうかは、「[CloudWatch エージェントが実行されていることを確認する](troubleshooting-CloudWatch-Agent.md#CloudWatch-Agent-troubleshooting-verify-running)」の手順に従って確認できます。
ワークロードがデプロイされている EC2 ホストで CloudWatch エージェントを既に実行していて、エージェント設定を管理している場合は、このセクションの手順をスキップし、既存のデプロイメカニズムに従って設定を更新できます。NVIDIA GPU のエージェント設定を既存のエージェント設定とマージしてから、マージされた設定をデプロイするようにしてください。Systems Manager を使用して CloudWatch エージェントの設定を保存および管理している場合は、設定を既存のパラメータ値にマージできます。詳細については、「[CloudWatch エージェント設定ファイルの管理](https://docs.aws.amazon.com/prescriptive-guidance/latest/implementing-logging-monitoring-cloudwatch/create-store-cloudwatch-configurations.html)」を参照してください。
**注記**
Systems Manager を使用して次の CloudWatch エージェント設定をデプロイすると、EC2 インスタンスの既存の CloudWatch エージェント設定がある場合は置き換えられるか、上書きされます。独自の環境やユースケースに合わせてこの設定を変更できます。設定で定義されているメトリクスは、ソリューションを提供するダッシュボードに最小限必要なものです。
このデプロイプロセスには、以下のステップが含まれます。
+ ステップ 1: ターゲット EC2 インスタンスに必要な IAM アクセス許可があることを確認します。
+ ステップ 2: 推奨エージェント設定ファイルを Systems Manager パラメータストアに保存します。
+ ステップ 3: CloudFormation スタックを使用して 1 つまたは複数の EC2 インスタンスに CloudWatch エージェントをインストールします。
+ ステップ 4: エージェントのセットアップが正しく設定されていることを確認します。
### ステップ 1: ターゲット EC2 インスタンスに必要な IAM アクセス許可があることを確認する
CloudWatch エージェントをインストールして設定するためのアクセス許可を Systems Manager に付与する必要があります。また、EC2 インスタンスから CloudWatch にテレメトリを発行するアクセス許可を CloudWatch エージェントに付与する必要もあります。インスタンスにアタッチされた IAM ロールに **CloudWatchAgentServerPolicy** と **AmazonSSMManagedInstanceCore** の IAM ポリシーがアタッチされていることを確認します。
+ ロールを作成したら、ロールを EC2 インスタンスにアタッチします。EC2 インスタンスにロールをアタッチするには、「[インスタンスへの IAM ロールのアタッチ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/attach-iam-role.html)」の手順に従います。
### ステップ 2: 推奨 CloudWatch エージェント設定ファイルを Systems Manager パラメータストアに保存する
パラメータストアでは、設定パラメータを安全に保存および管理することで EC2 インスタンスへの CloudWatch エージェントのインストールが簡素化され、ハードコーディングされた値が不要になります。これにより、デプロイプロセスがより安全で柔軟になり、集中管理が可能になり、複数のインスタンスで設定を簡単に更新できるようになります。
以下の手順を使用して、パラメータストアに推奨 CloudWatch エージェント設定ファイルをパラメータとして保存します。
**CloudWatch エージェント設定ファイルをパラメータとして作成するには**
1. AWS Systems Manager コンソール ([https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)) を開きます。
1. コンソールで選択したリージョンが、NVIDIA GPU ワークロードが実行されているリージョンであることを確認します。
1. ナビゲーションペインで **[アプリケーション管理]**、**[パラメータストア]** を選択します。
1. 以下の手順に従って、設定の新しいパラメータを作成します。
1. **[パラメータの作成]** を選択します。
1. **[名前]** ボックスに、後のステップで CloudWatch エージェント設定ファイルを参照するために使用する名前を入力します。例えば、**AmazonCloudWatch-NVIDIA-GPU-Configuration**。
1. (オプション) **[説明]** ボックスにパラメータの説明を入力します。
1. **[パラメータ階層]** で、**[標準]** を選択します。
1. **[型]** で、**[文字列]** を選択します。
1. **[データ型]** で、**[テキスト]** を選択します。
1. **[値]** ボックスに、[このソリューションのエージェント設定](#Solution-NVIDIA-GPU-Agent-Config) にリストされた対応する JSON ブロックを貼り付けます。
1. **[パラメータの作成]** を選択します。
### ステップ 3: CloudWatch エージェントをインストールし、CloudFormation テンプレートを使用して設定を適用する
AWS CloudFormation を使用してエージェントをインストールし、これまでの手順で作成した CloudWatch エージェント設定を使用するように設定できます。
**このソリューションの CloudWatch エージェントをインストールして設定するには**
1. 次のリンクを使用して、CloudFormation **[スタックのクイック作成]** ウィザードを開きます: [https://console.aws.amazon.com/cloudformation/home?\$1/stacks/quickcreate?templateURL=https://aws-observability-solutions-prod-us-east-1.s3.us-east-1.amazonaws.com/CloudWatchAgent/CFN/v1.0.0/cw-agent-installation-template-1.0.0.json](https://console.aws.amazon.com/cloudformation/home?#/stacks/quickcreate?templateURL=https://aws-observability-solutions-prod-us-east-1.s3.us-east-1.amazonaws.com/CloudWatchAgent/CFN/v1.0.0/cw-agent-installation-template-1.0.0.json)。
1. コンソールで選択したリージョンが、NVIDIA GPU ワークロードが実行されているリージョンであることを確認します。
1. **[スタック名]** にこのスタックを識別する名前 (**CWAgentInstallationStack** など) を入力します。
1. **[パラメータ]** セクションで、以下を指定します。
1. **[CloudWatchAgentConfigSSM]** に、**AmazonCloudWatch-NVIDIA-GPU-Configuration** など、前に作成したエージェント設定の Systems Manager パラメータの名前を入力します。
1. ターゲットインスタンスを選択するには、2 つのオプションがあります。
1. **[InstanceIds]** に、この設定で CloudWatch エージェントをインストールするインスタンス ID のカンマ区切りリストを指定します。1 つのインスタンスまたは複数のインスタンスを一覧表示できます。
1. 大規模にデプロイする場合は、**[TagKey]** とそれに対応する **[TagValue]** を指定して、このタグと値を持つすべての EC2 インスタンスをターゲットにできます。**[TagKey]** を指定する場合は、対応する **[TagValue]** を指定する必要があります。(Auto Scaling グループの場合、Auto Scaling グループ内のすべてのインスタンスにデプロイするには、**[TagKey]** に **aws:autoscaling:groupName** を指定し、**[TagValue]** に Auto Scaling グループ名を指定します。)
1. 設定を確認し、**[スタックの作成]** を選択します。
まずテンプレートファイルを編集してカスタマイズする場合は、**[スタックの作成ウィザード]** の **[テンプレートファイルのアップロード]** オプションを選択して、編集したテンプレートをアップロードします。詳細については、「[CloudFormation コンソールからスタックを作成する](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-console-create-stack.html)」を参照してください。
**注記**
このステップが完了すると、この Systems Manager パラメータは、ターゲットインスタンスで実行されている CloudWatch エージェントに関連付けられます。これにより、以下のように処理されます。
Systems Manager パラメータが削除されると、エージェントは停止します。
Systems Manager パラメータを編集すると、設定の変更はスケジュールされた頻度 (デフォルトで 30 日) でエージェントに自動的に適用されます。
この Systems Manager パラメータに変更をすぐに適用する場合は、このステップを再度実行する必要があります。関連付けの詳細については、「[Systems Manager の関連付けの使用](https://docs.aws.amazon.com/systems-manager/latest/userguide/state-manager-associations.html)」を参照してください。
### ステップ 4: エージェントのセットアップが正しく設定されていることを確認する
CloudWatch エージェントがインストールされているかどうかは、「[CloudWatch エージェントが実行されていることを確認する](troubleshooting-CloudWatch-Agent.md#CloudWatch-Agent-troubleshooting-verify-running)」の手順に従って確認できます。CloudWatch エージェントがインストールされておらず、実行されていない場合は、すべてが正しく設定されていることを確認してください。
+ 「[ステップ 1: ターゲット EC2 インスタンスに必要な IAM アクセス許可があることを確認する](#Solution-NVIDIA-GPU-Agent-Step1)」の説明に従って、EC2 インスタンスに正しいアクセス許可を持つロールがアタッチされていることを確認してください。
+ Systems Manager パラメータの JSON が正しく設定されていることを確認してください。「[CloudFormation での CloudWatch エージェントのインストールのトラブルシューティング](Install-CloudWatch-Agent-New-Instances-CloudFormation.md#CloudWatch-Agent-CloudFormation-troubleshooting)」のステップを実行してください。
すべてが正しく設定されている場合は、NVIDIA GPU メトリクスが CloudWatch に公開されているはずです。CloudWatch コンソールをチェックして、公開されていることを確認します。
**NVIDIA GPU メトリクスが CloudWatch に公開されていることを確認するには**
1. CloudWatch コンソールの [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/) を開いてください。
1. **[メトリクス]**、**[すべてのメトリクス]** を選択します。
1. ソリューションをデプロイしたリージョンを選択したことを確認し、**[カスタム名前空間]**、**[CWAgent]** を選択します。
1. `nvidia_smi_utilization_gpu` など、「[このソリューションのエージェント設定](#Solution-NVIDIA-GPU-Agent-Config)」で説明されているメトリクスを検索します。これらのメトリクスの結果が表示された場合、メトリクスは CloudWatch に公開されています。
## NVIDIA GPU ソリューションダッシュボードを作成する
このソリューションが提供するダッシュボードは、すべてのインスタンスでメトリクスを集約して表示することで、NVIDIA GPU メトリクスを表示します。ダッシュボードには、各メトリクスに寄与する上位の要因 (メトリクスウィジェットあたり上位 10 件) の内訳が表示されます。これにより、観測されたメトリクスに大きく寄与する外れ値やインスタンスをすばやく特定できます。
ダッシュボードを作成するには、以下のオプションを使用できます。
+ CloudWatch コンソールを使用してダッシュボードを作成します。
+ AWS CloudFormation コンソールを使用してダッシュボードをデプロイします。
+ AWS CloudFormation インフラストラクチャをコードとしてダウンロードし、継続的インテグレーション (CI) オートメーションの一部として統合します。
CloudWatch コンソールを使用してダッシュボードを作成すると、実際に作成して課金される前にダッシュボードをプレビューできます。
**注記**
このソリューションで CloudFormation を使用して作成されたダッシュボードには、ソリューションがデプロイされたリージョンのメトリクスが表示されます。NVIDIA GPU メトリクスが公開されるリージョンに CloudFormation スタックを必ず作成してください。
CloudWatch エージェント設定で CWAgent 以外のカスタム名前空間を指定した場合は、ダッシュボードの CloudFormation テンプレートを変更して、CWAgent を、使用しているカスタマイズされた名前空間に置き換える必要があります。
**CloudWatch コンソールを使用してダッシュボードを作成するには**
1. 次のリンクを使用して CloudWatch コンソール **[ダッシュボードの作成]** を開きます: [https://console.aws.amazon.com/cloudwatch/home?\$1dashboards?dashboardTemplate=NvidiaGpuOnEc2&referrer=os-catalog](https://console.aws.amazon.com/cloudwatch/home?#dashboards?dashboardTemplate=NvidiaGpuOnEc2&referrer=os-catalog)。
1. コンソールで選択したリージョンが、NVIDIA GPU ワークロードが実行されているリージョンであることを確認します。
1. ダッシュボードの名前を入力し、**[ダッシュボードの作成]** を選択します。
このダッシュボードを他のリージョンの類似のダッシュボードと簡単に区別するために、**NVIDIA-GPU-Dashboard-us-east-1** のように、ダッシュボード名にリージョン名を含めることをお勧めします。
1. ダッシュボードをプレビューし、**[保存]** を選択してダッシュボードを作成します。
**CloudFormation を使用してダッシュボードを作成するには**
1. 次のリンクを使用して、CloudFormation **[スタックのクイック作成]** ウィザードを開きます: [https://console.aws.amazon.com/cloudformation/home?\$1/stacks/quickcreate?templateURL=https://aws-observability-solutions-prod-us-east-1.s3.us-east-1.amazonaws.com/NVIDIA\$1GPU\$1EC2/CloudWatch/CFN/v1.0.0/dashboard-template-1.0.0.json](https://console.aws.amazon.com/cloudformation/home?#/stacks/quickcreate?templateURL=https://aws-observability-solutions-prod-us-east-1.s3.us-east-1.amazonaws.com/NVIDIA_GPU_EC2/CloudWatch/CFN/v1.0.0/dashboard-template-1.0.0.json)。
1. コンソールで選択したリージョンが、NVIDIA GPU ワークロードが実行されているリージョンであることを確認します。
1. **[スタック名]** にこのスタックを識別する名前 (**NVIDIA-GPU-DashboardStack** など) を入力します。
1. **[パラメータ]** セクションで、**[DashboardName]** パラメータにダッシュボードの名前を指定します。
1. このダッシュボードを他のリージョンの類似のダッシュボードと簡単に区別するために、**NVIDIA-GPU-Dashboard-us-east-1** のように、ダッシュボード名にリージョン名を含めることをお勧めします。
1. **[機能と変換]** で、変換のためのアクセス機能を承認します。CloudFormation は IAM リソースを追加しないことに注意してください。
1. 設定を確認し、**[スタックの作成]** を選択します。
1. スタックステータスが **CREATE\$1COMPLETE** になったら、作成したスタックの **[リソース]** タブを選択し、**[物理 ID]** のリンクを選択してダッシュボードに移動します。コンソールの左側のナビゲーションペインで **[ダッシュボード]** を選択し、**[カスタムダッシュボード]** でダッシュボード名を検索することで、CloudWatch コンソールでダッシュボードにアクセスすることもできます。
何らかの目的でテンプレートファイルを編集してカスタマイズする場合は、**[スタックの作成ウィザード]** の **[テンプレートファイルのアップロード]** オプションを使用して、編集したテンプレートをアップロードできます。詳細については、「[CloudFormation コンソールからスタックを作成する](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-console-create-stack.html)」を参照してください。次のリンクを使用して、テンプレートをダウンロードできます: [https://aws-observability-solutions-prod-us-east-1.s3.us-east-1.amazonaws.com/NVIDIA\$1GPU\$1EC2/CloudWatch/CFN/v1.0.0/dashboard-template-1.0.0.json](https://aws-observability-solutions-prod-us-east-1.s3.us-east-1.amazonaws.com/NVIDIA_GPU_EC2/CloudWatch/CFN/v1.0.0/dashboard-template-1.0.0.json)。
### NVIDIA GPU ダッシュボードの使用を開始する
新しい NVIDIA GPU ダッシュボードで試すことができるタスクをいくつか示します。これらのタスクにより、ダッシュボードが正しく機能していることの検証が可能になり、NVIDIA GPU をモニタリングするためにダッシュボードを実際に使用する経験ができます。これらを試すと、ダッシュボードの操作に慣れ、可視化されたメトリクスを解釈できるようになっていきます。
**GPU 使用率を確認する**
**[使用率]** セクションから、**[GPU 使用率]** ウィジェットと **[メモリ使用率]** ウィジェットを見つけます。これらはそれぞれ、GPU が計算にアクティブに使用されている時間の割合と、読み書きされるグローバルメモリの割合を示しています。使用率が高い場合、潜在的なパフォーマンスのボトルネックや追加の GPU リソースの必要性を示している可能性があります。
**GPU メモリ使用率を分析する**
**[メモリ]** セクションで、**[合計メモリ]**、**[使用済みメモリ]**、および **[空きメモリ]** の各ウィジェットを見つけます。これらによって、GPU の全体的なメモリ容量と、現在消費されているメモリまたは利用可能なメモリの量に関するインサイトが得られます。メモリのプレッシャーにより、パフォーマンスの問題やメモリ不足のエラーが発生する可能性があるため、これらのメトリクスをモニタリングし、ワークロードに十分なメモリが使用可能であることを確認することが重要です。
**温度と消費電力をモニタリングする**
**[温度/電力]** セクションで、**[GPU 温度]** ウィジェットと **[消費電力]** ウィジェットを見つけます。これらのメトリクスは、GPU が安全な熱と電力の範囲内で動作することを確実にするために不可欠です。
**エンコーダーのパフォーマンスを特定する**
**[エンコーダー]** セクションで、**[エンコーダーセッション数]**、**[平均 FPS]**、および **[平均レイテンシー]** の各ウィジェットを見つけます。GPU でビデオエンコーディングワークロードを実行している場合にこれらのメトリクスが関連します。これらのメトリクスをモニタリングして、エンコーダーが最適に実行されていることを確認するとともに、潜在的なボトルネックやパフォーマンスの問題を特定します。
**PCIe リンクステータスを確認する**
**[PCIe]** セクションで、**[PCIe リンク世代]** ウィジェットと **[PCIe リンク幅]** ウィジェットを見つけます。これらのメトリクスは、GPU をホストシステムに接続する PCIe リンクに関する情報を提供します。PCIe のボトルネックによってパフォーマンスが制限される可能性を避けるため、リンクが期待される世代と幅で動作していることを確認します。
**GPU クロックを確認する**
**[クロック]** セクションで、**[グラフィックスクロック]**、**[SM クロック]**、**[メモリクロック]**、および **[ビデオクロック]** の各ウィジェットを見つけます。これらのメトリクスは、さまざまな GPU コンポーネントの現在の動作周波数を示しています。これらのクロックのモニタリングは、パフォーマンスに影響を与える可能性がある GPU クロックのスケーリングや周波数スロットリングの潜在的な問題を特定するのに役立ちます。
# CloudWatch ソリューション: Amazon EC2 での Kafka ワークロード
このソリューションは、EC2 インスタンスで実行されている Kafka ワークロード (ブローカー、プロデューサー、コンシューマー) の CloudWatch エージェントを使用して、すぐに使用できるメトリクス収集を設定するのに役立ちます。さらに、事前設定された CloudWatch ダッシュボードを設定するのに役立ちます。すべての CloudWatch オブザーバビリティソリューションの一般的な情報については、「[CloudWatch オブザーバビリティソリューション](Monitoring-Solutions.md)」を参照してください。
**Topics**
+ [要件](#Solution-Kafka-On-EC2-Requirements)
+ [利点](#Solution-Kafka-On-EC2-Benefits)
+ [コスト](#Solution-Kafka-On-EC2-Costs)
+ [このソリューションの CloudWatch エージェント設定](#Solution-Kafka-CloudWatch-Agent)
+ [ソリューションにエージェントをデプロイする](#Solution-Kafka-Agent-Deploy)
+ [Kafka ソリューションダッシュボードを作成する](#Solution-Kafka-Dashboard)
+ [同じインスタンスで複数の Kafka ロールのエージェントを設定する](#Kafka-Multiple-Roles)
## 要件
このソリューションは、以下の条件に適しています。
+ ワークロード: Kafka v0.8.2.x 以降
+ コンピューティング: Amazon EC2
+ 特定の AWS リージョン内の Kafka ワークロード全体で最大 500 個の EC2 インスタンスをサポート
+ CloudWatch エージェントの最新バージョン
+ EC2 インスタンスにインストールされた SSM エージェント
**注記**
AWS Systems Manager (SSM エージェント) は、AWS および信頼できるサードパーティーが提供している一部の [Amazon マシンイメージ (AMI)](https://docs.aws.amazon.com/systems-manager/latest/userguide/ami-preinstalled-agent.html) にプリインストールされています。エージェントがインストールされていない場合は、使用しているオペレーティングシステムタイプの手順を使用して、手動でインストールできます。
[Linux 用 EC2 インスタンスに SSM Agent を手動でインストールおよびアンインストールする](https://docs.aws.amazon.com/systems-manager/latest/userguide/manually-install-ssm-agent-linux.html)
[macOS 用の EC2 インスタンスに SSM Agent を手動でインストールおよびアンインストールする](https://docs.aws.amazon.com/systems-manager/latest/userguide/manually-install-ssm-agent-macos.html)
[Windows Server 用の EC2 インスタンスに SSM Agent を手動でインストールおよびアンインストールする](https://docs.aws.amazon.com/systems-manager/latest/userguide/manually-install-ssm-agent-windows.html)
## 利点
このソリューションでは Kafka サーバーをモニタリングしているため、以下のユースケースに役立つインサイトが得られます。
+ レプリケーションメトリクスと同期メトリクスを使用して Kafka クラスターのヘルスをモニタリングします。
+ ネットワークトラフィックとともに、リクエストの失敗とレイテンシーを通じてブローカーのパフォーマンスを追跡します。
+ プロデューサー/コンシューマーのエラー、レイテンシー、コンシューマー遅延をモニタリングします。
+ Kafka クラスターに対する基盤となる JVM パフォーマンスを分析します。
+ 同じアカウントでソリューションを介して設定された複数の Kafka クラスター、プロデューサー、コンシューマーを切り替えます。
ソリューションの主な利点を以下に示します。
+ CloudWatch エージェント設定を使用して Kafka と基盤となる JVM のメトリクス収集を自動化し、手動計測をなくします。
+ Kafka メトリクスと JVM メトリクス用の事前設定済みの統合 CloudWatch ダッシュボードが用意されています。ダッシュボードは、ダッシュボードを初めて作成するときにメトリクスが存在しない場合でも、ソリューションを使用して設定された新しい Kafka EC2 インスタンスからのメトリクスを自動的に処理します。また、メトリクスを論理アプリケーションにグループ化して、重点の絞り込みと管理を容易にすることもできます。
以下の画像は、このソリューションのダッシュボードの例です。
![\[Kafka クラスター dashboard showing metrics for partitions, producer/consumer performance, and broker status.\]](http://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/images/KafkaDashboard.png)
## コスト
このソリューションは、アカウントでリソースを作成して使用します。標準使用には料金がかかります。これには以下を含みます。
+ CloudWatch エージェントによって収集されたすべてのメトリクスは、カスタムメトリクスとして課金されます。このソリューションで使用されるメトリクスの数は、EC2 ホストの数によって異なります。
+ ソリューション用に設定された各ブローカーホストは、33 個のメトリクスと、そのホストのディスクパス数によって各 EC2 ホストのメトリクス数が異なる 1 つのメトリクス (`disk_used_percent`) を公開します。
+ ソリューション用に設定された各プロデューサーホストは、`topic` ディメンションを持つ 3 つのメトリクスと、`topic` ディメンションを持たない 3 つのメトリクスを公開します。`topic` ディメンションを持つメトリクスの場合、各トピックは個別のメトリクスとしてカウントされます。
+ ソリューション用に設定された各コンシューマーホストは、`topic` ディメンションを持つ 2 つのメトリクスと、`topic` ディメンションを持たない 3 つのメトリクスを公開します。トピックディメンションを持つメトリクスの場合、各トピックは個別のメトリクスとしてカウントされます。
+ 1 つのカスタムダッシュボード。
+ CloudWatch エージェントによってメトリクスの公開がリクエストされた API オペレーション。このソリューションのデフォルト設定では、CloudWatch エージェントは EC2 ホストごとに毎分 1 回 **PutMetricData** を呼び出します。つまり、**PutMetricData** API は EC2 ホストごとに 30 日の月には `30*24*60=43,200` 回呼び出されます。
CloudWatch の料金の詳細については、「[Amazon CloudWatch の料金](https://aws.amazon.com/cloudwatch/pricing/)」をご覧ください。
料金計算ツールを使用すると、このソリューションを使用するためのおよその月額コストを見積もることができます。
**料金計算ツールを使用して毎月のソリューションのコストを見積もるには**
1. [Amazon CloudWatch 料金計算ツール](https://calculator.aws/#/createCalculator/CloudWatch)を開きます。
1. **[メトリクス]** セクションの **[メトリクスの数]** に **broker\$1metrics\$1count \$1 producer\$1metrics\$1count \$1 consumer\$1metrics\$1count** を入力します。これらを次のように計算します。
+ `broker_metrics_count` = (33 \$1 EC2 ホストあたりのディスクパスの平均数) \$1 number\$1of\$1ec2\$1broker\$1hosts
+ `producer_metrics_count` = (3 \$1 average\$1number\$1of\$1topics\$1per\$1producer\$1host \$1 3) \$1 number\$1of\$1ec2\$1producer\$1hosts
+ `consumer_metrics_count` = (2 \$1 average\$1number\$1of\$1topics\$1per\$1consumer\$1host \$1 3) \$1 number\$1of\$1ec2\$1consumer\$1hosts
1. **[API]** セクションの **[API リクエストの数]** に **43200 \$1 number of EC2 instances configured for this solution** を入力します。
デフォルトでは、CloudWatch エージェントは EC2 ホストごとに毎分 1 回 **PutMetricData** オペレーションを実行します。
1. **[ダッシュボードとアラーム]** セクションの **[ダッシュボードの数]** に「**1**」と入力します。
1. 毎月の見積コストは、料金計算ツールの下部に表示されます。
## このソリューションの CloudWatch エージェント設定
CloudWatch エージェントは、サーバー上およびコンテナ化された環境で継続的かつ自律的に実行されるソフトウェアです。インフラストラクチャとアプリケーションからメトリクス、ログ、トレースを収集し、CloudWatch と X-Ray に送信します。
CloudWatch エージェントの詳細については、「[CloudWatch エージェントを使用してメトリクス、ログ、トレースを収集する](Install-CloudWatch-Agent.md)」を参照してください。
このソリューションのエージェント設定では、Kafka、JVM、EC2 の基本的なメトリクスを収集します。CloudWatch エージェントは、ダッシュボードにデフォルトで表示されるよりも多くの Kafka メトリクスと JVM メトリクスを収集するように設定できます。収集できるすべての Kafka メトリクスのリストについては、「[Kafka メトリクスの収集](CloudWatch-Agent-JMX-metrics.md#CloudWatch-Agent-Kafka-metrics)」を参照してください。収集できるすべての JVM メトリクスのリストについては、「[JVM メトリクスの収集](CloudWatch-Agent-JMX-metrics.md#CloudWatch-Agent-JVM-metrics)」を参照してください。EC2 メトリクスのリストについては、「[Linux および macOS インスタンスで CloudWatch エージェントにより収集されるメトリクス](metrics-collected-by-CloudWatch-agent.md#linux-metrics-enabled-by-CloudWatch-agent)」を参照してください。
**Kafka ブローカーロール、プロデューサーロール、コンシューマーロールの JMX ポートを公開する**
CloudWatch エージェントは、JMX に依存して Kafka ブローカー、プロデューサー、コンシューマーに関連するメトリクスを収集します。これを実現するには、サーバーとアプリケーションの JMX ポートを公開する必要があります。
Kafka ブローカーの場合は、`JMX_PORT` 環境変数を使用してポートを設定する必要があります。この環境変数を設定した後、ブローカーを再起動する必要があります。アプリケーションの開始スクリプトと設定ファイルを確認して、これらの引数を追加する最適な場所を見つけます。
例えば、Linux および macOS システムでは、次のコマンドを使用して JMX ポートを設定できます。必ず未使用のポート番号を指定してください。
```
export JMX_PORT=port-number
```
Kafka プロデューサーとコンシューマーの場合、JMX ポートを公開する手順は、プロデューサーまたはコンシューマーの JVM アプリケーションに使用するワークロードタイプによって異なります。これらの手順については、アプリケーションのドキュメントを参照してください。
通常、モニタリングと管理のために JMX ポートを有効にするには、JVM アプリケーションに次のシステムプロパティを設定します。次の例では、認証されていない JMX を設定します。セキュリティポリシー/要件で、JMX を有効にするためにパスワード認証やリモートアクセスで SSL を有効にすることが必須の場合は、[JMX のドキュメント](https://docs.oracle.com/en/java/javase/17/management/monitoring-and-management-using-jmx-technology.html)を参照して必要なプロパティを設定します。
```
-Dcom.sun.management.jmxremote
-Dcom.sun.management.jmxremote.port=port-number
-Dcom.sun.management.jmxremote.authenticate=false
-Dcom.sun.management.jmxremote.ssl=false
```
JMX ポートを確認するには、`ps aux | grep jmxremote.port` を実行します。結果は、JMX ポートが JVM プロセスで設定されたことを示すはずです。
**このソリューションのエージェント設定**
エージェントによって収集されるメトリクスは、エージェント設定で定義されます。このソリューションには、ソリューションのダッシュボードに適したディメンションで推奨メトリクスを収集するためのエージェント設定が用意されています。ブローカー、プロデューサー、コンシューマーなどの各 Kafka ロールには、Kafka メトリクスと基盤となる JVM および EC2 メトリクスの収集を可能にする独自のエージェント設定があります。
ソリューションをデプロイする手順については、「[ソリューションにエージェントをデプロイする](#Solution-Kafka-Agent-Deploy)」で後述します。以下の情報は、環境に合わせてエージェント設定をカスタマイズする方法を理解するのに役立ちます。
環境に合わせて、次のエージェント設定の一部をカスタマイズする必要があります。
+ JMX ポート番号は、このドキュメントの前のセクションで設定したポート番号です。ポート番号は設定の `endpoint` 行にあります。
+ `ClusterName`– これは、収集されたブローカーメトリクスのディメンションとして使用されます。Kafka ブローカーを実行するインスタンスのクラスターグループを表す意味のある名前を指定します。
+ `ProcessGroupName`– これは、ブローカー用に収集された JVM メトリクスのディメンションとして使用されます。`ClusterName` に指定した値と同じ値を指定します。これにより、ソリューションダッシュボードのブローカーメトリクスと同じ Kafka ブローカーグループの JVM メトリクスを表示できます。
+ `ProducerGroupName`– これは、収集されたプロデューサーメトリクスのディメンションとして使用されます。プロデューサーインスタンスのグループを表す意味のある名前を指定します。この値には、ソリューションダッシュボードのプロデューサーメトリクスの統合ビューに使用するプロデューサーアプリケーションまたはサービスを指定できます。
+ `ConsumerGroupName`– これは、収集されたコンシューマーメトリクスのディメンションとして使用されます。コンシューマーインスタンスのグループを表す意味のある名前を指定します。これは Kafka でのコンシューマーグループの概念とは異なります。これは、ソリューションダッシュボードのコンシューマーメトリクスの統合ビューに使用するコンシューマーアプリケーションまたはサービスを指定できる単なるグループ化ディメンションです。
例えば、同じアカウントで実行されている Kafka クラスターが 2 つあり、1 つは `order-processing` アプリケーション用、もう 1 つは `inventory-management` アプリケーション用である場合、それに応じてブローカーインスタンスのエージェント設定で `ClusterName` と `ProcessGroupName` ディメンションを設定する必要があります。
+ `order-processing` クラスターブローカーインスタンスには、`ClusterName=order-processing` と `ProcessGroupName=order-processing` を設定します。
+ `inventory-management` クラスターブローカーインスタンスには、`ClusterName=inventory-management` と `ProcessGroupName=inventory-management` を設定します。
+ 同様に、それぞれのアプリケーションに基づいて、プロデューサーインスタンスには `ProducerGroupName` を、コンシューマーインスタンスには `ConsumerGroupName` を設定します。
上記のディメンションを正しく設定すると、ソリューションダッシュボードは、`ClusterName`、`ProducerGroupName`、および `ConsumerGroupName` の各ディメンションに基づいてメトリクスを自動的にグループ化します。ダッシュボードには、特定のクラスターとグループのメトリクスを選択および表示するドロップダウンオプションが含まれており、個々のクラスターとグループのパフォーマンスを個別にモニタリングできます。
関連するエージェント設定を正しい EC2 インスタンスにデプロイしてください。各設定は、「[ステップ 2: 推奨 CloudWatch エージェント設定ファイルを Systems Manager パラメータストアに保存する](#Solution-Kafka-Agent-Step2)」で後述するように、SSM のパラメータストアに別々のパラメータとして保存されます。
次の手順では、プロデューサー、コンシューマー、ブローカーの各ロールが重複することなく別々の EC2 インスタンスにデプロイされる状況について説明します。同じ EC2 インスタンスで複数の Kafka ロールを実行している場合、詳細については、「[同じインスタンスで複数の Kafka ロールのエージェントを設定する](#Kafka-Multiple-Roles)」を参照してください。
### Kafka ブローカーエージェントのエージェント設定
Kafka ブローカーエージェントがデプロイされている EC2 インスタンスでは、次の CloudWatch エージェント設定を使用します。*ClusterName* を、これらのメトリクスをグループ化して統一された表示にするために使用するクラスターの名前に置き換えます。*ClusterName* に指定した値は、`ClusterName` ディメンションと `ProcessGroupName` ディメンションの両方として使用されます。*port-number* を Kafka サーバーの JMX ポートに置き換えます。JMX がリモートアクセス用のパスワード認証または SSL で有効になっている場合は、必要に応じて、TLS または認可を設定する方法について「[Java Management Extensions (JMX) メトリクスの収集](CloudWatch-Agent-JMX-metrics.md)」を参照してください。
この設定 (JMX ブロックの外部に示される設定) に示される EC2 メトリクスは、Linux インスタンスと macOS インスタンスでのみ機能します。Windows インスタンスを使用している場合は、設定でこれらのメトリクスを省略できます。Windows インスタンスで収集されたメトリクスについては、「[Windows Server インスタンスで CloudWatch エージェントにより収集されるメトリクス](metrics-collected-by-CloudWatch-agent.md#windows-metrics-enabled-by-CloudWatch-agent)」を参照してください。
```
{
"metrics": {
"namespace": "CWAgent",
"append_dimensions": {
"InstanceId": "${aws:InstanceId}"
},
"metrics_collected": {
"jmx": [
{
"endpoint": "localhost:port-number",
"kafka": {
"measurement": [
"kafka.request.time.avg",
"kafka.request.failed",
"kafka.request.count",
"kafka.purgatory.size",
"kafka.partition.under_replicated",
"kafka.partition.offline",
"kafka.network.io",
"kafka.leader.election.rate",
"kafka.isr.operation.count"
]
},
"append_dimensions": {
"ClusterName": "ClusterName"
}
},
{
"endpoint": "localhost:port-number",
"jvm": {
"measurement": [
"jvm.classes.loaded",
"jvm.gc.collections.count",
"jvm.gc.collections.elapsed",
"jvm.memory.heap.committed",
"jvm.memory.heap.max",
"jvm.memory.heap.used",
"jvm.memory.nonheap.committed",
"jvm.memory.nonheap.max",
"jvm.memory.nonheap.used",
"jvm.threads.count"
]
},
"append_dimensions": {
"ProcessGroupName": "ClusterName"
}
}
],
"disk": {
"measurement": [
"used_percent"
]
},
"mem": {
"measurement": [
"used_percent"
]
},
"swap": {
"measurement": [
"used_percent"
]
},
"netstat": {
"measurement": [
"tcp_established",
"tcp_time_wait"
]
}
}
}
}
```
### Kafka プロデューサーのエージェント設定
Kafka プロデューサーがデプロイされている Amazon EC2 インスタンスでは、次の CloudWatch エージェント設定を使用します。*ProducerGroupName* を、メトリクスをグループ化して統一された表示にするために使用するアプリケーションまたはグループの名前に置き換えます。*port-number* を Kafka プロデューサーアプリケーションの JMX ポートに置き換えます。
ソリューションダッシュボードにプロデューサーの JVM に関連する JVM メトリクスが表示されないため、このソリューションでは Kafka プロデューサーの JVM メトリクスは有効になりません。エージェント設定をカスタマイズして JVM メトリクスを出力することもできますが、プロデューサーに関連する JVM メトリクスはソリューションダッシュボードに表示されません。
```
{
"metrics": {
"namespace": "CWAgent",
"append_dimensions": {
"InstanceId": "${aws:InstanceId}"
},
"metrics_collected": {
"jmx": [
{
"endpoint": "localhost:port-number",
"kafka-producer": {
"measurement": [
"kafka.producer.request-rate",
"kafka.producer.byte-rate",
"kafka.producer.request-latency-avg",
"kafka.producer.response-rate",
"kafka.producer.record-error-rate",
"kafka.producer.record-send-rate"
]
},
"append_dimensions": {
"ProducerGroupName": "ProducerGroupName"
}
}
]
}
}
}
```
### Kafka コンシューマーのエージェント設定
Kafka コンシューマーが実行されている EC2 インスタンスでは、次の CloudWatch エージェント設定を使用します。*ConsumerGroupName* を、これらのメトリクスをグループ化して統一された表示にするために使用するアプリケーションまたはグループの名前に置き換えます。*port-number* を Kafka コンシューマーアプリケーションの JMX ポートに置き換えます。
ソリューションダッシュボードにコンシューマーの JVM に関連する JVM メトリクスが表示されないため、このソリューションでは Kafka コンシューマーの JVM メトリクスは有効になりません。エージェント設定をカスタマイズして JVM メトリクスを出力することもできますが、コンシューマーに関連する JVM メトリクスはソリューションダッシュボードに表示されません。
```
{
"metrics": {
"append_dimensions": {
"InstanceId": "${aws:InstanceId}"
},
"metrics_collected": {
"jmx": [
{
"endpoint": "localhost:port-number",
"kafka-consumer": {
"measurement": [
"kafka.consumer.fetch-rate",
"kafka.consumer.total.bytes-consumed-rate",
"kafka.consumer.records-consumed-rate",
"kafka.consumer.bytes-consumed-rate",
"kafka.consumer.records-lag-max"
]
},
"append_dimensions": {
"ConsumerGroupName": "ConsumerGroupName"
}
}
]
}
}
}
```
## ソリューションにエージェントをデプロイする
ユースケースに応じて、CloudWatch エージェントをインストールするためのいくつかのアプローチがあります。このソリューションには Systems Manager を使用することをお勧めします。これにより、コンソール操作機能が提供され、1 つの AWS アカウント内のマネージドサーバーのフリートの管理が簡単になります。このセクションの手順では Systems Manager を使用し、CloudWatch エージェントを既存の設定で実行していない場合を想定しています。CloudWatch エージェントが実行されているかどうかは、「[CloudWatch エージェントが実行されていることを確認する](troubleshooting-CloudWatch-Agent.md#CloudWatch-Agent-troubleshooting-verify-running)」の手順に従って確認できます。
ワークロードがデプロイされている EC2 ホストで CloudWatch エージェントを既に実行していて、エージェント設定を管理している場合は、このセクションの手順をスキップし、既存のデプロイメカニズムに従って設定を更新できます。ロール (ブローカー、プロデューサー、コンシューマー) に従ってエージェント設定を既存のエージェント設定とマージしてから、マージされた設定をデプロイします。Systems Manager を使用して CloudWatch エージェントの設定を保存および管理している場合は、設定を既存のパラメータ値にマージできます。詳細については、「[CloudWatch エージェント設定ファイルの管理](https://docs.aws.amazon.com/prescriptive-guidance/latest/implementing-logging-monitoring-cloudwatch/create-store-cloudwatch-configurations.html)」を参照してください。
**注記**
Systems Manager を使用して次の CloudWatch エージェント設定をデプロイすると、EC2 インスタンスの既存の CloudWatch エージェント設定がある場合は置き換えられるか、上書きされます。独自の環境やユースケースに合わせてこの設定を変更できます。このソリューションで定義されているメトリクスは、推奨されるダッシュボードに最小限必要なものです。
このデプロイプロセスには、以下のステップが含まれます。
+ ステップ 1: ターゲット EC2 インスタンスに必要な IAM アクセス許可があることを確認します。
+ ステップ 2: 推奨エージェント設定ファイルを Systems Manager パラメータストアに保存します。
+ ステップ 3: CloudFormation スタックを使用して 1 つまたは複数の EC2 インスタンスに CloudWatch エージェントをインストールします。
+ ステップ 4: エージェントのセットアップが正しく設定されていることを確認します。
ブローカー、プロデューサー、コンシューマーが同じ EC2 インスタンスにデプロイされているか、異なるインスタンスにデプロイされているかに基づいて、この手順を繰り返す必要があります。例えば、Kafka ブローカー、プロデューサー、コンシューマーが重複することなく別々のインスタンスにデプロイされている場合は、ブローカー、プロデューサー、コンシューマーの各 EC2 インスタンスの適切なエージェント設定でこの手順を 3 回繰り返す必要があります。
### ステップ 1: ターゲット EC2 インスタンスに必要な IAM アクセス許可があることを確認する
CloudWatch エージェントをインストールして設定するためのアクセス許可を Systems Manager に付与する必要があります。また、EC2 インスタンスから CloudWatch にテレメトリを発行するアクセス許可を CloudWatch エージェントに付与する必要もあります。インスタンスにアタッチされた IAM ロールに **CloudWatchAgentServerPolicy** と **AmazonSSMManagedInstanceCore** の IAM ポリシーがアタッチされていることを確認します。
+ ロールを作成したら、ロールを EC2 インスタンスにアタッチします。新しい EC2 インスタンスの起動中にロールをアタッチするには、[IAM ロールを持つインスタンスの起動](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html#launch-instance-with-role)に関するページの手順に従います。既存の EC2 インスタンスにロールをアタッチするには、[インスタンスへの IAM ロールのアタッチ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html#attach-iam-role)に関するページの手順に従います。
### ステップ 2: 推奨 CloudWatch エージェント設定ファイルを Systems Manager パラメータストアに保存する
パラメータストアでは、設定パラメータを安全に保存および管理することで EC2 インスタンスへの CloudWatch エージェントのインストールが簡素化され、ハードコーディングされた値が不要になります。これにより、デプロイプロセスがより安全で柔軟になり、集中管理が可能になり、複数のインスタンスで設定を簡単に更新できるようになります。
以下の手順を使用して、パラメータストアに推奨 CloudWatch エージェント設定ファイルをパラメータとして保存します。
**CloudWatch エージェント設定ファイルをパラメータとして作成するには**
1. AWS Systems Manager コンソール ([https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)) を開きます。
1. ナビゲーションペインで **[アプリケーション管理]**、**[パラメータストア]** を選択します。
1. 以下の手順に従って、設定の新しいパラメータを作成します。
1. **[パラメータの作成]** を選択します。
1. プロデューサーには **AmazonCloudWatch-Kafka-Producer-Configuration**、コンシューマーには **AmazonCloudWatch-Kafka-Consumer-Configuration**、ブローカーには **AmazonCloudWatch-Kafka-Broker-Configuration** など、CloudWatch エージェント設定を保存するパラメータの名前を指定します。単一の EC2 に複数の Kafka ロールがある場合は、識別しやすいように、それに応じてロールに名前を付けます。この値は、EC2 インスタンスで実行されているエージェントにこの設定を配布するために後で使用されます。
1. **[パラメータ階層]** で、**[標準]** を選択します。
1. **[型]** で、**[文字列]** を選択します。
1. **[データ型]** で、**[テキスト]** を選択します。
1. **[値]** ボックスに、CloudWatch エージェント設定の全文を貼り付けます。このインスタンスがホストしている Kafka ロールの JSON ブロックを必ず選択してください。ブローカー、プロデューサー、コンシューマーの設定を保存する場合は、それぞれ「[Kafka ブローカーエージェントのエージェント設定](#Solution-Kafka-Agent-Broker)」、「[Kafka プロデューサーのエージェント設定](#Solution-Kafka-Agent-Producer)」、「[Kafka コンシューマーのエージェント設定](#Solution-Kafka-Agent-Consumer)」に記載されている設定を参照してください。同じ EC2 インスタンスで複数の Kafka ロールを実行している場合は、「[同じインスタンスで複数の Kafka ロールのエージェントを設定する](#Kafka-Multiple-Roles)」で同じインスタンスについて説明されているように、必要に応じて設定をマージしてください。
1. **[パラメータの作成]** を選択します。
### ステップ 3: CloudWatch エージェントをインストールし、CloudFormation テンプレートを使用して設定を適用する
AWS CloudFormation を使用してエージェントをインストールし、これまでの手順で作成した CloudWatch エージェント設定を使用するように設定できます。
**このソリューションの CloudWatch エージェントをインストールして設定するには**
1. 次のリンクを使用して、CloudFormation **[スタックのクイック作成]** ウィザードを開きます: [https://console.aws.amazon.com/cloudformation/home?\$1/stacks/quickcreate?templateURL=https://aws-observability-solutions-prod-us-east-1.s3.us-east-1.amazonaws.com/CloudWatchAgent/CFN/v1.0.0/cw-agent-installation-template-1.0.0.json](https://console.aws.amazon.com/cloudformation/home?#/stacks/quickcreate?templateURL=https://aws-observability-solutions-prod-us-east-1.s3.us-east-1.amazonaws.com/CloudWatchAgent/CFN/v1.0.0/cw-agent-installation-template-1.0.0.json)。
1. コンソールで選択したリージョンが Kafka ワークロードが実行されているリージョンであることを確認します。
1. **[スタック名]** にこのスタックを識別する名前 (**CWAgentInstallationStack** など) を入力します。
1. **[パラメータ]** セクションで、以下を指定します。
1. **CloudWatchAgentConfigSSM** に、ブローカーには **AmazonCloudWatch-Kafka-Broker-Configuration**、プロデューサーには **AmazonCloudWatch-Kafka-Producer-Configuration**、コンシューマーには **AmazonCloudWatch-Kafka-Consumer-Configuration** など、前に作成したエージェント設定の Systems Manager パラメータの名前を入力します。
1. ターゲットインスタンスを選択するには、2 つのオプションがあります。
1. **[InstanceIds]** に、この設定で CloudWatch エージェントをインストールするインスタンス ID のカンマ区切りリストを指定します。1 つのインスタンスまたは複数のインスタンスを一覧表示できます。
1. 大規模にデプロイする場合は、**[TagKey]** とそれに対応する **[TagValue]** を指定して、このタグと値を持つすべての EC2 インスタンスをターゲットにできます。**[TagKey]** を指定する場合は、対応する **[TagValue]** を指定する必要があります。(Auto Scaling グループの場合、Auto Scaling グループ内のすべてのインスタンスにデプロイするには、**[TagKey]** に **aws:autoscaling:groupName** を指定し、**[TagValue]** に Auto Scaling グループ名を指定します。)
**[InstanceIds]** パラメータと **[TagKeys]** パラメータの両方を指定すると、**[InstanceIds]** が優先され、タグは無視されます。
1. 設定を確認し、**[スタックの作成]** を選択します。
まずテンプレートファイルを編集してカスタマイズする場合は、**[スタックの作成ウィザード]** の **[テンプレートファイルのアップロード]** オプションを選択して、編集したテンプレートをアップロードします。詳細については、「[CloudFormation コンソールからスタックを作成する](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-console-create-stack.html)」を参照してください。次のリンクを使用して、テンプレートをダウンロードできます: [https://aws-observability-solutions-prod-us-east-1.s3.us-east-1.amazonaws.com/CloudWatchAgent/CFN/v1.0.0/cw-agent-installation-template-1.0.0.json](https://aws-observability-solutions-prod-us-east-1.s3.us-east-1.amazonaws.com/CloudWatchAgent/CFN/v1.0.0/cw-agent-installation-template-1.0.0.json)。
**注記**
このステップが完了すると、この Systems Manager パラメータは、ターゲットインスタンスで実行されている CloudWatch エージェントに関連付けられます。これにより、以下のように処理されます。
Systems Manager パラメータが削除されると、エージェントは停止します。
Systems Manager パラメータを編集すると、設定の変更はスケジュールされた頻度 (デフォルトで 30 日) でエージェントに自動的に適用されます。
この Systems Manager パラメータに変更をすぐに適用する場合は、このステップを再度実行する必要があります。関連付けの詳細については、「[Systems Manager の関連付けの使用](https://docs.aws.amazon.com/systems-manager/latest/userguide/state-manager-associations.html)」を参照してください。
### ステップ 4: エージェントのセットアップが正しく設定されていることを確認する
CloudWatch エージェントがインストールされているかどうかは、「[CloudWatch エージェントが実行されていることを確認する](troubleshooting-CloudWatch-Agent.md#CloudWatch-Agent-troubleshooting-verify-running)」の手順に従って確認できます。CloudWatch エージェントがインストールされておらず、実行されていない場合は、すべてが正しく設定されていることを確認してください。
+ 「[ステップ 1: ターゲット EC2 インスタンスに必要な IAM アクセス許可があることを確認する](Solution-Tomcat-On-EC2.md#Solution-Tomcat-Agent-Step1)」の説明に従って、EC2 インスタンスに正しいアクセス許可を持つロールがアタッチされていることを確認してください。
+ Systems Manager パラメータの JSON が正しく設定されていることを確認してください。「[CloudFormation での CloudWatch エージェントのインストールのトラブルシューティング](Install-CloudWatch-Agent-New-Instances-CloudFormation.md#CloudWatch-Agent-CloudFormation-troubleshooting)」のステップを実行してください。
すべてが正しく設定されている場合は、Kafka メトリクスが CloudWatch に公開されているはずです。CloudWatch コンソールをチェックして、公開されていることを確認します。
**Kafka メトリクスが CloudWatch に公開されていることを確認するには**
1. CloudWatch コンソールの [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/) を開いてください。
1. **[メトリクス]**、**[すべてのメトリクス]** を選択します。
1. ソリューションをデプロイしたリージョンを選択したことを確認し、**[カスタム名前空間]**、**[CWAgent]** を選択します。
1. ブローカーには `kafka.partition.offline`、コンシューマーには `kafka.consumer.fetch.rate`、プロデューサーには `kafka.producer.request-rate` など、このドキュメントのエージェント設定セクションに記載されているメトリクスを検索します。これらのメトリクスの結果が表示された場合、メトリクスは CloudWatch に公開されています。
## Kafka ソリューションダッシュボードを作成する
このダッシュボードには、Kafka と基盤となる JVM の両方に対して新しく出力されるメトリクスが表示されます。このダッシュボードには、プロデューサー、ブローカー、コンシューマー全体にわたる Kafka ワークロードのヘルスに寄与する上位の要因が表示されます。寄与する上位の要因のビューには、メトリクスウィジェットあたり上位 10 件が表示されます。これにより、外れ値を一目で特定できます。
ソリューションダッシュボードには EC2 メトリクスは表示されません。EC2 メトリクスを表示するには、EC2 自動ダッシュボードを使用して EC2 からのメトリクスを表示し、EC2 コンソールダッシュボードを使用して CloudWatch エージェントによって収集された EC2 メトリクスを表示する必要があります。AWS サービスの自動ダッシュボードの詳細については、「[単一の AWS サービスの CloudWatch ダッシュボードの表示](CloudWatch_Automatic_Dashboards_Focus_Service.md)」を参照してください。
ダッシュボードを作成するには、以下のオプションを使用できます。
+ CloudWatch コンソールを使用してダッシュボードを作成します。
+ AWS CloudFormation コンソールを使用してダッシュボードをデプロイします。
+ AWS CloudFormation インフラストラクチャをコードとしてダウンロードし、継続的インテグレーション (CI) オートメーションの一部として統合します。
CloudWatch コンソールを使用してダッシュボードを作成すると、実際に作成して課金される前にダッシュボードをプレビューできます。
**注記**
このソリューションで CloudFormation を使用して作成されたダッシュボードには、ソリューションがデプロイされたリージョンのメトリクスが表示されます。JVM メトリクスと Kafka メトリクスが公開されるリージョンに CloudFormation スタックを必ず作成してください。
CloudWatch エージェント設定で `CWAgent` 以外のカスタム名前空間を指定した場合は、ダッシュボードの CloudFormation テンプレートを変更して、`CWAgent` を、使用しているカスタマイズされた名前空間に置き換える必要があります。
**CloudWatch コンソールを使用してダッシュボードを作成するには**
**注記**
現在、ソリューションダッシュボードには、最新の Java バージョンのデフォルトコレクターである G1 ガベージコレクターのガベージコレクション関連のメトリクスのみが表示されます。別のガベージコレクションアルゴリズムを使用している場合、ガベージコレクションに関連するウィジェットは空です。ただし、ダッシュボードの CloudFormation テンプレートを変更し、適切なガベージコレクションタイプをガベージコレクション関連のメトリクスの名前ディメンションに適用することで、これらのウィジェットをカスタマイズできます。例えば、並列ガベージコレクションを使用している場合は、ガベージコレクション数メトリクス `jvm.gc.collections.count` の **name=\$1"G1 Young Generation\$1"** を **name=\$1"Parallel GC\$1"** に変更します。
1. 次のリンクを使用して CloudWatch コンソールの **[ダッシュボードの作成]** を開きます: [https://console.aws.amazon.com/cloudwatch/home?\$1dashboards?dashboardTemplate=ApacheKafkaOnEc2&referrer=os-catalog](https://console.aws.amazon.com/cloudwatch/home?#dashboards?dashboardTemplate=ApacheKafkaOnEc2&referrer=os-catalog)。
1. コンソールで選択したリージョンが Kafka ワークロードが実行されているリージョンであることを確認します。
1. ダッシュボードの名前を入力し、**[ダッシュボードの作成]** を選択します。
このダッシュボードを他のリージョンの類似のダッシュボードと簡単に区別するために、**KafkaDashboard-us-east-1** のように、ダッシュボード名にリージョン名を含めることをお勧めします。
1. ダッシュボードをプレビューし、**[保存]** を選択してダッシュボードを作成します。
**CloudFormation を使用してダッシュボードを作成するには**
1. 次のリンクを使用して、CloudFormation **[スタックのクイック作成]** ウィザードを開きます: [https://console.aws.amazon.com/cloudformation/home?\$1/stacks/quickcreate?templateURL=https://aws-observability-solutions-prod-us-east-1.s3.us-east-1.amazonaws.com/Kafka\$1EC2/CloudWatch/CFN/v1.0.0/dashboard-template-1.0.0.json](https://console.aws.amazon.com/cloudformation/home?#/stacks/quickcreate?templateURL=https://aws-observability-solutions-prod-us-east-1.s3.us-east-1.amazonaws.com/Kafka_EC2/CloudWatch/CFN/v1.0.0/dashboard-template-1.0.0.json)。
1. コンソールで選択したリージョンが Kafka ワークロードが実行されているリージョンであることを確認します。
1. **[スタック名]** にこのスタックを識別する名前 (**KafkaDashboardStack** など) を入力します。
1. **[パラメータ]** セクションで、**[DashboardName]** パラメータにダッシュボードの名前を指定します。
このダッシュボードを他のリージョンの類似のダッシュボードと簡単に区別するために、**KafkaDashboard-us-east-1** のように、ダッシュボード名にリージョン名を含めることをお勧めします。
1. **[機能と変換]** で、変換のためのアクセス機能を承認します。CloudFormation は IAM リソースを追加しないことに注意してください。
1. 設定を確認し、**[スタックの作成]** を選択します。
1. スタックステータスが **CREATE\$1COMPLETE** になったら、作成したスタックの **[リソース]** タブを選択し、**[物理 ID]** のリンクを選択してダッシュボードに移動します。コンソールの左側のナビゲーションペインで **[ダッシュボード]** を選択し、**[カスタムダッシュボード]** でダッシュボード名を検索することで、CloudWatch コンソールでダッシュボードにアクセスすることもできます。
何らかの目的でテンプレートファイルを編集してカスタマイズする場合は、**[スタックの作成ウィザード]** の **[テンプレートファイルのアップロード]** オプションを使用して、編集したテンプレートをアップロードできます。詳細については、「[CloudFormation コンソールからスタックを作成する](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-console-create-stack.html)」を参照してください。次のリンクを使用して、テンプレートをダウンロードできます: [https://aws-observability-solutions-prod-us-east-1.s3.us-east-1.amazonaws.com/Kafka\$1EC2/CloudWatch/CFN/v1.0.0/dashboard-template-1.0.0.json](https://aws-observability-solutions-prod-us-east-1.s3.us-east-1.amazonaws.com/Kafka_EC2/CloudWatch/CFN/v1.0.0/dashboard-template-1.0.0.json)。
**注記**
現在、ソリューションダッシュボードには、最新の Java バージョンのデフォルトコレクターである G1 ガベージコレクターのガベージコレクション関連のメトリクスのみが表示されます。別のガベージコレクションアルゴリズムを使用している場合、ガベージコレクションに関連するウィジェットは空です。ただし、ダッシュボードの CloudFormation テンプレートを変更し、適切なガベージコレクションタイプをガベージコレクション関連のメトリクスの名前ディメンションに適用することで、これらのウィジェットをカスタマイズできます。例えば、並列ガベージコレクションを使用している場合は、ガベージコレクション数メトリクス `jvm.gc.collections.count` の **name=\$1"G1 Young Generation\$1"** を **name=\$1"Parallel GC\$1"** に変更します。
### Kafka ダッシュボードの使用を開始する
新しい Kafka ダッシュボードで試すことができるタスクをいくつか示します。これらのタスクにより、ダッシュボードが正しく機能していることの検証が可能になり、Kafka クラスターをモニタリングするためにダッシュボードを実際に使用する経験ができます。これらを試すと、ダッシュボードの操作に慣れ、可視化されたメトリクスを解釈できるようになっていきます。
**ドロップダウンリストの使用**
ダッシュボードの上部には、モニタリングする特定の Kafka クラスター、プロデューサー、コンシューマーの各グループをフィルタリングして選択するために使用できるドロップダウンリストが表示されます。
+ 特定の Kafka クラスターのメトリクスを表示するには、**[Kafka クラスター]** ドロップダウンリストでそのクラスター名を選択します。
+ 特定の Kafka プロデューサーグループのメトリクスを表示するには、**[Kafka プロデューサー]** ドロップダウンリストでそのプロデューサーグループ名を選択します。
+ 特定の Kafka コンシューマーグループのメトリクスを表示するには、**[Kafka コンシューマーグループ]** ドロップダウンリストでそのコンシューマーグループ名を選択します。
**クラスターのヘルスを確認する**
**[クラスターの概要]** セクションから、**[レプリケートされているパーティション]** ウィジェットと **[同期しているレプリカ]** ウィジェットを見つけます。これらは、理想的にはゼロまたは少数である必要があります。これらのメトリクスの値が大きい場合は、調査が必要な Kafka クラスターの問題を示している可能性があります。
**ブローカーのパフォーマンスを調査する**
**[ブローカー]** セクションで、**[失敗したフェッチリクエスト数]** ウィジェットと **[失敗したプロデューサーリクエスト数]** ウィジェットを見つけます。これらはそれぞれ、フェッチオペレーションとプロデュースオペレーションの失敗したリクエストの数を示しています。失敗の率が高い場合は、さらに調査が必要なブローカーやネットワーク接続の問題を示している可能性があります。
**プロデューサーのパフォーマンスをモニタリングする**
**[プロデューサーグループの概要]** セクションで、**[平均リクエスト率]**、**[平均リクエストレイテンシー]**、および **[平均レコード送信/エラー率]** の各ウィジェットを見つけます。これらは、選択したグループのプロデューサーのパフォーマンスの概要を示します。**[プロデューサー]** セクションで特定のプロデューサーとトピックのメトリクスを表示して詳細を確認することもできます。
**コンシューマーの遅延をモニタリングする**
**[コンシューマーグループの概要]** セクションで、**[コンシューマー遅延]** ウィジェットを見つけます。これは、サブスクライブしているパーティション内の最新のオフセットからのメッセージ処理においてコンシューマーが遅れている時間差を示しています。理想的には、コンシューマーの遅延は低いかゼロである必要があります。コンシューマーの遅延が大きい場合は、コンシューマーがデータ生成速度に追いつくことができないことを示している可能性があり、データの損失や処理の遅延につながる可能性があります。**[コンシューマー]** セクションで特定のコンシューマーとトピックのメトリクスを表示して詳細を確認することもできます。
## 同じインスタンスで複数の Kafka ロールのエージェントを設定する
[このソリューションの CloudWatch エージェント設定](#Solution-Kafka-CloudWatch-Agent) にリストされている Kafka ロールの個々の設定は、プロデューサー、コンシューマー、ブローカーの各ロールが重複することなく別々の EC2 インスタンスにデプロイされている場合にのみ適用されます。同じ Amazon EC2 インスタンスで複数の Kafka ロールを実行している場合は、次の 2 つのオプションがあります。
+ そのインスタンスにデプロイされたすべての Kafka ロールのすべてのメトリクスを一覧表示して設定する単一のエージェント設定ファイルを作成します。Systems Manager を使用してエージェント設定を管理する場合は、これが推奨オプションです。
このオプションを選択し、複数の Kafka ロールが同じ JVM プロセスの一部である場合は、エージェント設定で各 Kafka ロールに同じエンドポイントを指定する必要があります。複数の Kafka ロールが異なる JVM プロセスの一部である場合、そのプロセスの JMX ポートセットに応じて、各ロールのエンドポイントが異なる場合があります。
+ Kafka ロールごとに別々のエージェント設定ファイルを作成し、両方の設定ファイルを適用するようにエージェントを設定します。複数の設定ファイルを適用する手順については、「[複数の CloudWatch エージェント設定ファイルを作成する](create-cloudwatch-agent-configuration-file.md#CloudWatch-Agent-multiple-config-files)」を参照してください。
次の例は、プロデューサーロールとコンシューマーロールが 1 つのインスタンスで同じ JVM プロセスの一部として実行されている CloudWatch エージェント設定を示しています。この場合、ポート番号は、以下の設定のプロデューサー部分とコンシューマー部分の両方で同じである必要があります。一方、2 つのロールが異なる JVM プロセスの一部として実行されていた場合は、個々の JVM プロセスの JMX ポートに従って、それぞれに異なるポート番号を指定できます。
```
{
"metrics": {
"namespace": "CWAgent",
"append_dimensions": {
"InstanceId": "${aws:InstanceId}"
},
"metrics_collected": {
"jmx": [
{
"endpoint": "localhost:port-number",
"kafka-producer": {
"measurement": [
"kafka.producer.request-rate",
"kafka.producer.byte-rate",
"kafka.producer.request-latency-avg",
"kafka.producer.response-rate",
"kafka.producer.record-error-rate",
"kafka.producer.record-send-rate"
]
},
"append_dimensions": {
"ProducerGroupName": "ProducerGroupName"
}
},
{
"endpoint": "localhost:port-number",
"kafka-consumer": {
"measurement": [
"kafka.consumer.fetch-rate",
"kafka.consumer.total.bytes-consumed-rate",
"kafka.consumer.records-consumed-rate",
"kafka.consumer.bytes-consumed-rate",
"kafka.consumer.records-lag-max"
]
},
"append_dimensions": {
"ConsumerGroupName": "ConsumerGroupName"
}
}
]
}
}
}
```
# CloudWatch ソリューション: Amazon EC2 での Tomcat ワークロード
このソリューションは、EC2 インスタンスで実行されている Tomcat サーバー用の CloudWatch エージェントを使用して、すぐに使用できるメトリクス収集を設定するのに役立ちます。さらに、事前設定された CloudWatch ダッシュボードを設定するのに役立ちます。すべての CloudWatch オブザーバビリティソリューションの一般的な情報については、「[CloudWatch オブザーバビリティソリューション](Monitoring-Solutions.md)」を参照してください。
**Topics**
+ [要件](#Solution-Tomcat-On-EC2-Requirements)
+ [利点](#Solution-Tomcat-On-EC2-Benefits)
+ [コスト](#Solution-Tomcat-On-EC2-Costs)
+ [このソリューションの CloudWatch エージェント設定](#Solution-Tomcat-CloudWatch-Agent)
+ [ソリューションにエージェントをデプロイする](#Solution-Tomcat-Agent-Deploy)
+ [Tomcat ソリューションダッシュボードを作成する](#Solution-Tomcat-Dashboard)
## 要件
このソリューションは、以下の条件に適しています。
+ サポートされているバージョン: Tomcat バージョン 9、10.1、および 11 (ベータ)
+ コンピューティング: Amazon EC2
+ 特定の AWS リージョン内の Tomcat ワークロード全体で最大 500 個の EC2 インスタンスをサポート
+ CloudWatch エージェントの最新バージョン
+ EC2 インスタンスにインストールされた SSM エージェント
**注記**
AWS Systems Manager (SSM エージェント) は、AWS および信頼できるサードパーティーが提供している一部の [Amazon マシンイメージ (AMI)](https://docs.aws.amazon.com/systems-manager/latest/userguide/ami-preinstalled-agent.html) にプリインストールされています。エージェントがインストールされていない場合は、使用しているオペレーティングシステムタイプの手順を使用して、手動でインストールできます。
[Linux 用 EC2 インスタンスに SSM Agent を手動でインストールおよびアンインストールする](https://docs.aws.amazon.com/systems-manager/latest/userguide/manually-install-ssm-agent-linux.html)
[macOS 用の EC2 インスタンスに SSM Agent を手動でインストールおよびアンインストールする](https://docs.aws.amazon.com/systems-manager/latest/userguide/manually-install-ssm-agent-macos.html)
[Windows Server 用の EC2 インスタンスに SSM Agent を手動でインストールおよびアンインストールする](https://docs.aws.amazon.com/systems-manager/latest/userguide/manually-install-ssm-agent-windows.html)
## 利点
このソリューションでは Tomcat サーバーをモニタリングしているため、以下のユースケースに役立つインサイトが得られます。
+ Tomcat サーバーのエラーとパフォーマンスの問題を検出します。
+ データ転送の問題がないかネットワークトラフィックをモニタリングします。
+ スレッドの使用状況とアクティブなユーザーセッションを追跡します。
+ Tomcat サーバーの基盤となる JVM のパフォーマンスを分析します。
ソリューションの主な利点を以下に示します。
+ CloudWatch エージェント設定を使用して Apache Tomcat と基盤となる JVM のメトリクス収集を自動化し、手動計測をなくします。
+ Apache Tomcat メトリクスと JVM メトリクス用の事前設定済みの統合 CloudWatch ダッシュボードが用意されています。ダッシュボードは、ダッシュボードを初めて作成するときにメトリクスが存在しない場合でも、ソリューションを使用して設定された新しい Tomcat EC2 インスタンスからのメトリクスを自動的に処理します。また、メトリクスを論理アプリケーションにグループ化して、重点の絞り込みと管理を容易にすることもできます。
以下の画像は、このソリューションのダッシュボードの例です。
![\[Apache Tomcat ソリューションのダッシュボードの例。\]](http://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/images/TomcatDashboard.png)
## コスト
このソリューションは、アカウントでリソースを作成して使用します。標準使用には料金がかかります。これには以下を含みます。
+ CloudWatch エージェントによって収集されたすべてのメトリクスは、カスタムメトリクスとして課金されます。このソリューションで使用されるメトリクスの数は、EC2 ホストの数によって異なります。
+ ソリューション用に設定された各 Tomcat ホストは、合計 27 個のメトリクスと、そのホストのディスクパスの数によってメトリクス数が異なる 1 つのメトリクス (`disk_used_percent`) を公開します。
+ 1 つのカスタムダッシュボード。
+ CloudWatch エージェントによってメトリクスの公開がリクエストされた API オペレーション。このソリューションのデフォルト設定では、CloudWatch エージェントは毎分 1 回 **PutMetricData** を呼び出します。つまり、**PutMetricData** API は EC2 ホストごとに 30 日の月には `30*24*60=43,200` 回呼び出されます。
CloudWatch の料金の詳細については、「[Amazon CloudWatch の料金](https://aws.amazon.com/cloudwatch/pricing/)」をご覧ください。
料金計算ツールを使用すると、このソリューションを使用するためのおよその月額コストを見積もることができます。
**料金計算ツールを使用して毎月のソリューションのコストを見積もるには**
1. [Amazon CloudWatch 料金計算ツール](https://calculator.aws/#/createCalculator/CloudWatch)を開きます。
1. **[メトリクス]** セクションの **[メトリクスの数]** に **(27 \$1 average number of disk paths per EC2 host) \$1 number of EC2 instances configured for this solution** を入力します。
1. **[API]** セクションの **[API リクエストの数]** に **43200 \$1 number of EC2 instances configured for this solution** を入力します。
デフォルトでは、ソリューションは EC2 ホストごとに毎分 1 回 **PutMetricData** オペレーションを実行します。
1. **[ダッシュボードとアラーム]** セクションの **[ダッシュボードの数]** に「**1**」と入力します。
1. 毎月の見積コストは、料金計算ツールの下部に表示されます。
## このソリューションの CloudWatch エージェント設定
CloudWatch エージェントは、サーバー上およびコンテナ化された環境で継続的かつ自律的に実行されるソフトウェアです。インフラストラクチャとアプリケーションからメトリクス、ログ、トレースを収集し、CloudWatch と X-Ray に送信します。
CloudWatch エージェントの詳細については、「[CloudWatch エージェントを使用してメトリクス、ログ、トレースを収集する](Install-CloudWatch-Agent.md)」を参照してください。
このソリューションのエージェント設定では、Tomcat、JVM、EC2 の基本的なメトリクスを収集します。CloudWatch エージェントは、ダッシュボードのデフォルトで表示されるよりも多くの JVM メトリクスを収集するように設定できます。収集できるすべての Tomcat メトリクスのリストについては、「[Tomcat メトリクスの収集](CloudWatch-Agent-JMX-metrics.md#CloudWatch-Agent-Tomcat-metrics)」を参照してください。収集できるすべての JVM メトリクスのリストについては、「[JVM メトリクスの収集](CloudWatch-Agent-JMX-metrics.md#CloudWatch-Agent-JVM-metrics)」を参照してください。Amazon EC2 メトリクスのリストについては「[Linux および macOS インスタンスで CloudWatch エージェントにより収集されるメトリクス](metrics-collected-by-CloudWatch-agent.md#linux-metrics-enabled-by-CloudWatch-agent)」を参照してください。
**Tomcat サーバーの JMX ポートを公開する**
CloudWatch エージェントは、JMX に依存して Tomcat サーバーと JVM プロセスに関連するメトリクスを収集します。これを実現するには、サーバーから JMX ポートを公開する必要があります。モニタリングと管理のために JMX ポートを有効にするには、Tomcat サーバーのシステムプロパティを設定します。環境変数 `CATALINA_OPTS ` を使用して、Tomcat に必要なシステムプロパティを設定できます。環境変数を設定する最適な場所について、Tomcat サーバーの開始スクリプトと設定ファイルを確認します。必ず未使用のポート番号を指定してください。変更後にサーバーを再起動する必要があります。
```
export CATALINA_OPTS="-Dcom.sun.management.jmxremote -Dcom.sun.management.jmxremote.port=<> -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false"
```
この例では、認証されていない JMX を設定します。セキュリティポリシー/要件で、JMX を有効にするためにパスワード認証やリモートアクセスで SSL を有効にすることが必須の場合は、[JMX のドキュメント](https://docs.oracle.com/en/java/javase/17/management/monitoring-and-management-using-jmx-technology.html)を参照して必要なプロパティを設定します。
JMX ポートを確認するには、`ps aux | grep jmxremote.port` を実行します。結果は、JMX ポートが JVM プロセスで設定されたことを示すはずです。
### Tomcat ソリューションのエージェント設定
エージェントによって収集されるメトリクスは、エージェント設定で定義されます。このソリューションには、ソリューションのダッシュボードに適したディメンションで推奨メトリクスを収集するためのエージェント設定が用意されています。
ソリューションをデプロイする手順については、「[ソリューションにエージェントをデプロイする](#Solution-Tomcat-Agent-Deploy)」で後述します。以下の情報は、環境に合わせてエージェント設定をカスタマイズする方法を理解するのに役立ちます。
環境に合わせて、次のエージェント設定の一部をカスタマイズする必要があります。
+ JMX ポート番号は、このドキュメントの前のセクションで設定したポート番号です。ポート番号は設定の `endpoint` 行にあります。
+ `AppName` – これは、収集された Tomcat アプリケーションメトリクスのディメンションとして使用されます。Tomcat アプリケーションを実行するインスタンスのグループを表す意味のある名前を指定します。
+ `ProcessGroupName` – これは、Tomcat ホスト用に収集された JVM メトリクスのディメンションとして使用されます。上記の `AppName` と同じ値を指定します。これは、ソリューションダッシュボードのサーバーメトリクスとして、同じ Tomcat アプリケーショングループの JVM メトリクスを表示できるようにするためです。
例えば、同じ AWS アカウント で実行されている Tomcat アプリケーションが 2 つあり、1 つは `billing-system` アプリケーション用、もう 1 つは `order-system` アプリケーション用である場合、それに応じて各インスタンスのエージェント設定で `AppName` と `ProcessGroupName` ディメンションを設定できます。
+ `billing-system` アプリケーションインスタンスには、`AppName=billing-system` と `ProcessGroupName=billing-system` を設定します。
+ `order-system` アプリケーションインスタンスには、`AppName=order-system` と `ProcessGroupName=order-system` を設定します。
これらのガイドラインに従うと、ソリューションによって `AppName` ディメンションと `ProcessGroupName` ディメンションに基づいてメトリクスが自動的にグループ化されます。ダッシュボードには、特定の Tomcat アプリケーションのメトリクスを選択および表示するドロップダウンオプションが含まれており、個々のアプリケーションのパフォーマンスを個別にモニタリングできます。
### Tomcat ホストのエージェント設定
Tomcat アプリケーションがデプロイされている EC2 インスタンスでは、次の CloudWatch エージェント設定を使用します。設定は、「[ステップ 2: 推奨 CloudWatch エージェント設定ファイルを Systems Manager パラメータストアに保存する](#Solution-Tomcat-Agent-Step2)」で後述するように、SSM のパラメータストアにパラメータとして保存されます。
*AppName* を、インスタンスが属する Tomcat アプリケーションを表す意味のある名前に置き換えます。*port-number* を Tomcat サーバーの JMX ポートに置き換えます。JMX がリモートアクセス用のパスワード認証または SSL で有効になっている場合は、必要に応じて、エージェント設定で TLS または認証を設定する方法について「[Java Management Extensions (JMX) メトリクスの収集](CloudWatch-Agent-JMX-metrics.md)」を参照してください。
この設定 (JMX ブロックの外部に示される設定) に示される EC2 メトリクスは、Linux インスタンスと macOS インスタンスでのみ機能します。Windows インスタンスを使用している場合は、設定でこれらのメトリクスを省略できます。Windows インスタンスで収集されたメトリクスについては、「[Windows Server インスタンスで CloudWatch エージェントにより収集されるメトリクス](metrics-collected-by-CloudWatch-agent.md#windows-metrics-enabled-by-CloudWatch-agent)」を参照してください。
```
{
"metrics": {
"namespace": "CWAgent",
"append_dimensions": {
"InstanceId": "${aws:InstanceId}"
},
"metrics_collected": {
"jmx": [
{
"endpoint": "localhost:port-number",
"tomcat": {
"measurement": [
"tomcat.sessions",
"tomcat.errors",
"tomcat.processing_time",
"tomcat.traffic",
"tomcat.max_time",
"tomcat.request_count",
"tomcat.threads"
]
},
"append_dimensions": {
"AppName": "AppName"
}
},
{
"endpoint": "localhost:port-number",
"jvm": {
"measurement": [
"jvm.classes.loaded",
"jvm.gc.collections.count",
"jvm.gc.collections.elapsed",
"jvm.memory.heap.committed",
"jvm.memory.heap.max",
"jvm.memory.heap.used",
"jvm.memory.nonheap.committed",
"jvm.memory.nonheap.max",
"jvm.memory.nonheap.used",
"jvm.threads.count"
]
},
"append_dimensions": {
"ProcessGroupName": "AppName"
}
}
],
"disk": {
"measurement": [
"used_percent"
]
},
"mem": {
"measurement": [
"used_percent"
]
},
"swap": {
"measurement": [
"used_percent"
]
},
"netstat": {
"measurement": [
"tcp_established",
"tcp_time_wait"
]
}
}
}
}
```
## ソリューションにエージェントをデプロイする
ユースケースに応じて、CloudWatch エージェントをインストールするためのいくつかのアプローチがあります。このソリューションには Systems Manager を使用することをお勧めします。これにより、コンソール操作機能が提供され、1 つの AWS アカウント内のマネージドサーバーのフリートの管理が簡単になります。このセクションの手順では Systems Manager を使用し、CloudWatch エージェントを既存の設定で実行していない場合を想定しています。CloudWatch エージェントが実行されているかどうかは、「[CloudWatch エージェントが実行されていることを確認する](troubleshooting-CloudWatch-Agent.md#CloudWatch-Agent-troubleshooting-verify-running)」の手順に従って確認できます。
JVM アプリケーションがデプロイされている EC2 ホストで CloudWatch エージェントを既に実行していて、エージェント設定を管理している場合は、このセクションの手順をスキップし、既存のデプロイメカニズムに従って設定を更新できます。JVM のエージェント設定を既存のエージェント設定とマージしてから、マージされた設定をデプロイするようにしてください。Systems Manager を使用して CloudWatch エージェントの設定を保存および管理している場合は、設定を既存のパラメータ値にマージできます。詳細については、「[CloudWatch エージェント設定ファイルの管理](https://docs.aws.amazon.com/prescriptive-guidance/latest/implementing-logging-monitoring-cloudwatch/create-store-cloudwatch-configurations.html)」を参照してください。
**注記**
Systems Manager を使用して次の CloudWatch エージェント設定をデプロイすると、EC2 インスタンスの既存の CloudWatch エージェント設定がある場合は置き換えられるか、上書きされます。独自の環境やユースケースに合わせてこの設定を変更できます。このソリューションで定義されているメトリクスは、推奨されるダッシュボードに最小限必要なものです。
このデプロイプロセスには、以下のステップが含まれます。
+ ステップ 1: ターゲット EC2 インスタンスに必要な IAM アクセス許可があることを確認します。
+ ステップ 2: 推奨エージェント設定ファイルを Systems Manager パラメータストアに保存します。
+ ステップ 3: CloudFormation スタックを使用して 1 つまたは複数の EC2 インスタンスに CloudWatch エージェントをインストールします。
+ ステップ 4: エージェントのセットアップが正しく設定されていることを確認します。
### ステップ 1: ターゲット EC2 インスタンスに必要な IAM アクセス許可があることを確認する
CloudWatch エージェントをインストールして設定するためのアクセス許可を Systems Manager に付与する必要があります。また、EC2 インスタンスから CloudWatch にテレメトリを発行するアクセス許可を CloudWatch エージェントに付与する必要もあります。インスタンスにアタッチされた IAM ロールに **CloudWatchAgentServerPolicy** と **AmazonSSMManagedInstanceCore** の IAM ポリシーがアタッチされていることを確認します。
+ ロールを作成したら、ロールを EC2 インスタンスにアタッチします。新しい EC2 インスタンスの起動中にロールをアタッチするには、[IAM ロールを持つインスタンスの起動](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html#launch-instance-with-role)に関するページの手順に従います。既存の EC2 インスタンスにロールをアタッチするには、[インスタンスへの IAM ロールのアタッチ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/iam-roles-for-amazon-ec2.html#attach-iam-role)に関するページの手順に従います。
### ステップ 2: 推奨 CloudWatch エージェント設定ファイルを Systems Manager パラメータストアに保存する
パラメータストアでは、設定パラメータを安全に保存および管理することで EC2 インスタンスへの CloudWatch エージェントのインストールが簡素化され、ハードコーディングされた値が不要になります。これにより、デプロイプロセスがより安全で柔軟になり、集中管理が可能になり、複数のインスタンスで設定を簡単に更新できるようになります。
以下の手順を使用して、パラメータストアに推奨 CloudWatch エージェント設定ファイルをパラメータとして保存します。
**CloudWatch エージェント設定ファイルをパラメータとして作成するには**
1. AWS Systems Manager コンソール ([https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)) を開きます。
1. ナビゲーションペインで **[アプリケーション管理]**、**[パラメータストア]** を選択します。
1. 以下の手順に従って、設定の新しいパラメータを作成します。
1. **[パラメータの作成]** を選択します。
1. **[名前]** ボックスに、後のステップで CloudWatch エージェント設定ファイルを参照するために使用する名前を入力します。例えば、**AmazonCloudWatch-Tomcat-Configuration**。
1. (オプション) **[説明]** ボックスにパラメータの説明を入力します。
1. **[パラメータ階層]** で、**[標準]** を選択します。
1. **[型]** で、**[文字列]** を選択します。
1. **[データ型]** で、**[テキスト]** を選択します。
1. **[値]** ボックスに、[Tomcat ホストのエージェント設定](#Solution-Agent-Configuration-Tomcat-Host) にリストされた対応する JSON ブロックを貼り付けます。説明に従って、グループ化ディメンション値とポート番号を必ずカスタマイズしてください。
1. **[パラメータの作成]** を選択します。
### ステップ 3: CloudWatch エージェントをインストールし、CloudFormation テンプレートを使用して設定を適用する
AWS CloudFormation を使用してエージェントをインストールし、これまでの手順で作成した CloudWatch エージェント設定を使用するように設定できます。
**このソリューションの CloudWatch エージェントをインストールして設定するには**
1. 次のリンクを使用して、CloudFormation **[スタックのクイック作成]** ウィザードを開きます: [https://console.aws.amazon.com/cloudformation/home?\$1/stacks/quickcreate?templateURL=https://aws-observability-solutions-prod-us-east-1.s3.us-east-1.amazonaws.com/CloudWatchAgent/CFN/v1.0.0/cw-agent-installation-template-1.0.0.json](https://console.aws.amazon.com/cloudformation/home?#/stacks/quickcreate?templateURL=https://aws-observability-solutions-prod-us-east-1.s3.us-east-1.amazonaws.com/CloudWatchAgent/CFN/v1.0.0/cw-agent-installation-template-1.0.0.json)。
1. コンソールで選択したリージョンが Tomcat ワークロードが実行されているリージョンであることを確認します。
1. **[スタック名]** にこのスタックを識別する名前 (**CWAgentInstallationStack** など) を入力します。
1. **[パラメータ]** セクションで、以下を指定します。
1. **[CloudWatchAgentConfigSSM]** に、**AmazonCloudWatch-Tomcat-Configuration** など、前に作成したエージェント設定の Systems Manager パラメータの名前を入力します。
1. ターゲットインスタンスを選択するには、2 つのオプションがあります。
1. **[InstanceIds]** に、この設定で CloudWatch エージェントをインストールするインスタンス ID のカンマ区切りリストを指定します。1 つのインスタンスまたは複数のインスタンスを一覧表示できます。
1. 大規模にデプロイする場合は、**[TagKey]** とそれに対応する **[TagValue]** を指定して、このタグと値を持つすべての EC2 インスタンスをターゲットにできます。**[TagKey]** を指定する場合は、対応する **[TagValue]** を指定する必要があります。(Auto Scaling グループの場合、Auto Scaling グループ内のすべてのインスタンスにデプロイするには、**[TagKey]** に **aws:autoscaling:groupName** を指定し、**[TagValue]** に Auto Scaling グループ名を指定します。)
**[InstanceIds]** パラメータと **[TagKeys]** パラメータの両方を指定すると、**[InstanceIds]** が優先され、タグは無視されます。
1. 設定を確認し、**[スタックの作成]** を選択します。
まずテンプレートファイルを編集してカスタマイズする場合は、**[スタックの作成ウィザード]** の **[テンプレートファイルのアップロード]** オプションを選択して、編集したテンプレートをアップロードします。詳細については、「[CloudFormation コンソールからスタックを作成する](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-console-create-stack.html)」を参照してください。次のリンクを使用して、テンプレートをダウンロードできます: [https://aws-observability-solutions-prod-us-east-1.s3.us-east-1.amazonaws.com/CloudWatchAgent/CFN/v1.0.0/cw-agent-installation-template-1.0.0.json](https://aws-observability-solutions-prod-us-east-1.s3.us-east-1.amazonaws.com/CloudWatchAgent/CFN/v1.0.0/cw-agent-installation-template-1.0.0.json)。
**注記**
このステップが完了すると、この Systems Manager パラメータは、ターゲットインスタンスで実行されている CloudWatch エージェントに関連付けられます。これにより、以下のように処理されます。
Systems Manager パラメータが削除されると、エージェントは停止します。
Systems Manager パラメータを編集すると、設定の変更はスケジュールされた頻度 (デフォルトで 30 日) でエージェントに自動的に適用されます。
この Systems Manager パラメータに変更をすぐに適用する場合は、このステップを再度実行する必要があります。関連付けの詳細については、「[Systems Manager の関連付けの使用](https://docs.aws.amazon.com/systems-manager/latest/userguide/state-manager-associations.html)」を参照してください。
### ステップ 4: エージェントのセットアップが正しく設定されていることを確認する
CloudWatch エージェントがインストールされているかどうかは、「[CloudWatch エージェントが実行されていることを確認する](troubleshooting-CloudWatch-Agent.md#CloudWatch-Agent-troubleshooting-verify-running)」の手順に従って確認できます。CloudWatch エージェントがインストールされておらず、実行されていない場合は、すべてが正しく設定されていることを確認してください。
+ 「[ステップ 1: ターゲット EC2 インスタンスに必要な IAM アクセス許可があることを確認する](#Solution-Tomcat-Agent-Step1)」の説明に従って、EC2 インスタンスに正しいアクセス許可を持つロールがアタッチされていることを確認してください。
+ Systems Manager パラメータの JSON が正しく設定されていることを確認してください。「[CloudFormation での CloudWatch エージェントのインストールのトラブルシューティング](Install-CloudWatch-Agent-New-Instances-CloudFormation.md#CloudWatch-Agent-CloudFormation-troubleshooting)」のステップを実行してください。
すべてが正しく設定されている場合は、Tomcat メトリクスが CloudWatch に公開されているはずです。CloudWatch コンソールをチェックして、公開されていることを確認します。
**Tomcat メトリクスが CloudWatch に公開されていることを確認するには**
1. CloudWatch コンソールの [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/) を開いてください。
1. **[メトリクス]**、**[すべてのメトリクス]** を選択します。
1. ソリューションをデプロイしたリージョンを選択したことを確認し、**[カスタム名前空間]**、**[CWAgent]** を選択します。
1. `tomcat.errors` など、このドキュメントのエージェント設定セクションに記載されているメトリクスを検索します。これらのメトリクスの結果が表示された場合、メトリクスは CloudWatch に公開されています。
## Tomcat ソリューションダッシュボードを作成する
このダッシュボードには、Tomcat アプリケーションサーバーと基盤となる JVM の両方を示す、新しく出力されるメトリクスが表示されます。このダッシュボードには、Tomcat ワークロードのヘルスに寄与する上位の要因が表示されます。寄与する上位の要因のビューには、メトリクスウィジェットあたり上位 10 件が表示されます。これにより、外れ値を一目で特定できます。ダッシュボードには、すべてのインスタンスのメトリクスを集約して表示するクラスターの概要も含まれており、クラスターの全体的なヘルスと運用状態の概要が表示されます。
ソリューションダッシュボードには EC2 メトリクスは表示されません。EC2 メトリクスを表示するには、EC2 自動ダッシュボードを使用して EC2 からのメトリクスを表示し、EC2 コンソールダッシュボードを使用して CloudWatch エージェントによって収集された EC2 メトリクスを表示する必要があります。AWS のサービス の自動ダッシュボードの詳細については、「[単一の AWS サービスの CloudWatch ダッシュボードの表示](CloudWatch_Automatic_Dashboards_Focus_Service.md)」を参照してください。
ダッシュボードを作成するには、以下のオプションを使用できます。
+ CloudWatch コンソールを使用してダッシュボードを作成します。
+ AWS CloudFormation コンソールを使用してダッシュボードをデプロイします。
+ AWS CloudFormation インフラストラクチャをコードとしてダウンロードし、継続的インテグレーション (CI) オートメーションの一部として統合します。
CloudWatch コンソールを使用してダッシュボードを作成すると、実際に作成して課金される前にダッシュボードをプレビューできます。
**注記**
このソリューションで CloudFormation を使用して作成されたダッシュボードには、ソリューションがデプロイされたリージョンのメトリクスが表示されます。Tomcat メトリクスが公開されるリージョンに CloudFormation スタックを必ず作成してください。
CloudWatch エージェント設定で `CWAgent` 以外のカスタム名前空間を指定した場合は、ダッシュボードの CloudFormation テンプレートを変更して、`CWAgent` を、使用しているカスタマイズされた名前空間に置き換える必要があります。
**CloudWatch コンソールを使用してダッシュボードを作成するには**
**注記**
現在、ソリューションダッシュボードには、最新の Java バージョンのデフォルトコレクターである G1 ガベージコレクターのガベージコレクション関連のメトリクスのみが表示されます。別のガベージコレクションアルゴリズムを使用している場合、ガベージコレクションに関連するウィジェットは空です。ただし、ダッシュボードの CloudFormation テンプレートを変更し、適切なガベージコレクションタイプをガベージコレクション関連のメトリクスの名前ディメンションに適用することで、これらのウィジェットをカスタマイズできます。例えば、並列ガベージコレクションを使用している場合は、ガベージコレクション数メトリクス `jvm.gc.collections.count` の **name=\$1"G1 Young Generation\$1"** を **name=\$1"Parallel GC\$1"** に変更します。
1. 次のリンクを使用して CloudWatch コンソールの **[ダッシュボードの作成]** を開きます: [https://console.aws.amazon.com/cloudwatch/home?\$1dashboards?dashboardTemplate=ApacheTomcatOnEc2&referrer=os-catalog](https://console.aws.amazon.com/cloudwatch/home?#dashboards?dashboardTemplate=ApacheTomcatOnEc2&referrer=os-catalog)。
1. コンソールで選択したリージョンが Tomcat ワークロードが実行されているリージョンであることを確認します。
1. ダッシュボードの名前を入力し、**[ダッシュボードの作成]** を選択します。
このダッシュボードを他のリージョンの類似のダッシュボードと簡単に区別するために、**TomcatDashboard-us-east-1** のように、ダッシュボード名にリージョン名を含めることをお勧めします。
1. ダッシュボードをプレビューし、**[保存]** を選択してダッシュボードを作成します。
**CloudFormation を使用してダッシュボードを作成するには**
1. 次のリンクを使用して、CloudFormation **[スタックのクイック作成]** ウィザードを開きます: [https://console.aws.amazon.com/cloudformation/home?\$1/stacks/quickcreate?templateURL=https://aws-observability-solutions-prod-us-east-1.s3.us-east-1.amazonaws.com/Tomcat\$1EC2/CloudWatch/CFN/v1.0.0/dashboard-template-1.0.0.json](https://console.aws.amazon.com/cloudformation/home?#/stacks/quickcreate?templateURL=https://aws-observability-solutions-prod-us-east-1.s3.us-east-1.amazonaws.com/Tomcat_EC2/CloudWatch/CFN/v1.0.0/dashboard-template-1.0.0.json)。
1. コンソールで選択したリージョンが Tomcat ワークロードが実行されているリージョンであることを確認します。
1. **[スタック名]** にこのスタックを識別する名前 (**TomcatDashboard-us-east-1** など) を入力します。
1. **[パラメータ]** セクションで、**[DashboardName]** パラメータにダッシュボードの名前を指定します。
1. このダッシュボードを他のリージョンの類似のダッシュボードと簡単に区別するために、**TomcatDashboard-us-east-1** のように、ダッシュボード名にリージョン名を含めることをお勧めします。
1. **[機能と変換]** で、変換のためのアクセス機能を承認します。CloudFormation は IAM リソースを追加しないことに注意してください。
1. 設定を確認し、**[スタックの作成]** を選択します。
1. スタックステータスが **CREATE\$1COMPLETE** になったら、作成したスタックの **[リソース]** タブを選択し、**[物理 ID]** のリンクを選択してダッシュボードに移動します。コンソールの左側のナビゲーションペインで **[ダッシュボード]** を選択し、**[カスタムダッシュボード]** でダッシュボード名を検索することで、CloudWatch コンソールでダッシュボードにアクセスすることもできます。
何らかの目的でテンプレートファイルを編集してカスタマイズする場合は、**[スタックの作成ウィザード]** の **[テンプレートファイルのアップロード]** オプションを使用して、編集したテンプレートをアップロードできます。詳細については、「[CloudFormation コンソールからスタックを作成する](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-console-create-stack.html)」を参照してください。次のリンクを使用して、テンプレートをダウンロードできます: [https://aws-observability-solutions-prod-us-east-1.s3.us-east-1.amazonaws.com/Tomcat\$1EC2/CloudWatch/CFN/v1.0.0/dashboard-template-1.0.0.json](https://aws-observability-solutions-prod-us-east-1.s3.us-east-1.amazonaws.com/Tomcat_EC2/CloudWatch/CFN/v1.0.0/dashboard-template-1.0.0.json)。
**注記**
現在、ソリューションダッシュボードには、最新の Java バージョンのデフォルトコレクターである G1 ガベージコレクターのガベージコレクション関連のメトリクスのみが表示されます。別のガベージコレクションアルゴリズムを使用している場合、ガベージコレクションに関連するウィジェットは空です。ただし、ダッシュボードの CloudFormation テンプレートを変更し、適切なガベージコレクションタイプをガベージコレクション関連のメトリクスの名前ディメンションに適用することで、これらのウィジェットをカスタマイズできます。例えば、並列ガベージコレクションを使用している場合は、ガベージコレクション数メトリクス `jvm.gc.collections.count` の **name=\$1"G1 Young Generation\$1"** を **name=\$1"Parallel GC\$1"** に変更します。
### Tomcat モニタリングダッシュボードの使用を開始する
新しい Tomcat ダッシュボードで試すことができるタスクをいくつか示します。これらのタスクにより、ダッシュボードが正しく機能していることの検証が可能になり、Tomcat アプリケーションをモニタリングするためにダッシュボードを実際に使用する経験ができます。これらを試すと、ダッシュボードの操作に慣れ、可視化されたメトリクスを解釈できるようになっていきます。
**ドロップダウンリストの使用**
ダッシュボードの上部には、モニタリングする特定の Tomcat アプリケーションのフィルタリングと選択に使用できるドロップダウンリストが表示されます。特定の Tomcat アプリケーションのメトリクスを表示するには、**[Tomcat アプリケーション]** ドロップダウンリストでそのアプリケーション名を選択します。
**アプリケーションのヘルスを確認する**
**[アプリケーションの概要]** セクションから、**[リクエスト]**、**[エラー]**、および **[エラー率]** の各ウィジェットを見つけます。これらは、アプリケーションのリクエスト処理パフォーマンスの概要を示します。異常に多いエラー数やエラー率がないか調べます。これは、調査が必要な問題を示している可能性があります。
**リクエスト処理をモニタリングする**
**[リクエスト処理時間]** セクションで、**[最大時間]** ウィジェットと **[すべてのリクエストを処理する合計時間]** ウィジェットを見つけます。これらのメトリクスは、リクエスト処理における潜在的なパフォーマンスのボトルネックを特定するのに役立ちます。最大処理時間が他のサーバーよりも大幅に長いサーバーがないか探します。
**ネットワークトラフィックを分析する**
**[ネットワークトラフィック]** セクションで、**[送信されたトラフィック]** ウィジェットと **[受信したトラフィック]** ウィジェットを見つけます。これらは、アプリケーションがネットワーク経由で送受信するデータの量を示します。想定外にトラフィックレベルが高い場合は、ネットワーク飽和や非効率なデータ転送の問題が発生する可能性があります。
**スレッドの使用状況を調査する**
**[セッションとスレッド]** セクションで、**[ビジースレッド数]**、**[スレッド数] **、および **[セッション]** の各ウィジェットを見つけます。これらのメトリクスからは、アプリケーションのスレッド管理とアクティブなユーザーセッションに関するインサイトが得られます。ビジースレッド数またはセッション数が異常に多いサーバーを探します。これは、リソースが制約されている可能性を示します。
# CloudWatch ソリューション: Amazon EC2 ヘルス
このソリューションは、EC2 インスタンスで実行されているワークロードの CloudWatch エージェントを使用して、すぐに使用できるメトリクス収集を設定するのに役立ちます。さらに、事前設定された CloudWatch ダッシュボードを設定するのに役立ちます。
**Topics**
+ [要件](#Solution-EC2-Health-Requirements)
+ [利点](#Solution-EC2-Health-Benefits)
+ [コスト](#Solution-EC2-Health-Costs)
+ [このソリューションの CloudWatch エージェント設定](#Solution-EC2-Health-Agent-Config)
+ [ソリューションにエージェントをデプロイする](#Solution-EC2-Health-Deploy)
+ [EC2 Health ソリューションダッシュボードを作成する](#Solution-EC2-Health-Dashboard)
+ [EC2 Health ソリューションダッシュボードの使用を開始する](#Solution-EC2-Health-Dashboard-Usage)
## 要件
このソリューションは、以下の条件に適しています。
+ コンピューティング: Amazon EC2
+ プラットフォーム: Linux と macOS
+ 特定の AWS リージョン内で最大 500 個の EC2 インスタンスをサポート
+ CloudWatch エージェントの最新バージョン
+ EC2 インスタンスにインストールされた SSM エージェント
**注記**
AWS Systems Manager (SSM エージェント) は、AWS および信頼できるサードパーティーが提供している一部の [Amazon マシンイメージ (AMI)](https://docs.aws.amazon.com/systems-manager/latest/userguide/ami-preinstalled-agent.html) にプリインストールされています。エージェントがインストールされていない場合は、使用しているオペレーティングシステムタイプの手順を使用して、手動でインストールできます。
[Linux 用 EC2 インスタンスに SSM Agent を手動でインストールおよびアンインストールする](https://docs.aws.amazon.com/systems-manager/latest/userguide/manually-install-ssm-agent-linux.html)
[macOS 用の EC2 インスタンスに SSM Agent を手動でインストールおよびアンインストールする](https://docs.aws.amazon.com/systems-manager/latest/userguide/manually-install-ssm-agent-macos.html)
[Windows Server 用の EC2 インスタンスに SSM Agent を手動でインストールおよびアンインストールする](https://docs.aws.amazon.com/systems-manager/latest/userguide/manually-install-ssm-agent-windows.html)
## 利点
このソリューションでは、CloudWatch Agent を使用して EC2 サーバーをモニタリングしているため、次のユースケースについて、標準の EC2 名前空間メトリクスに加えて追加のシステムレベルのメトリクスが得られます。
+ CPU パフォーマンスの問題とリソースの制約を検出します。
+ EC2 インスタンス全体のさまざまなディスクのディスク使用率とストレージ容量をモニタリングします。
+ メモリ使用率パターンと潜在的なメモリリークを追跡します。
+ I/O オペレーションとその全体的なパフォーマンスへの影響を分析します。
+ ネットワークトラフィックパターンと異常の可能性を観測します。
ソリューションの主な利点を以下に示します。
+ EC2 インスタンスのメトリクス収集を自動化し、手動計測をなくします。
+ EC2 インスタンスメトリクス用の事前設定済みの統合 CloudWatch ダッシュボードが用意されています。ダッシュボードは、ダッシュボードを初めて作成するときにメトリクスが存在しない場合でも、ソリューションを使用して設定された新しい EC2 インスタンスからのメトリクスを自動的に処理します。また、Auto Scaling グループを介して管理される EC2 インスタンスを観測することもできます。
以下の画像は、このソリューションのダッシュボードの例です。
![\[EC2 Health ダッシュボードの例\]](http://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/images/EC2HealthDashboard.png)
## コスト
このソリューションは、アカウントでリソースを作成して使用します。標準使用には料金がかかります。これには以下を含みます。
+ CloudWatch エージェントによって収集されたすべてのメトリクスは、カスタムメトリクスとして課金されます。このソリューションで使用されるメトリクスの数は、EC2 ホストの数によって異なります。
CloudWatch エージェントメトリクスの合計数は、ディスクの設定によって異なります。ディスクメトリクスと diskio メトリクス以外に、ソリューションは 6 つのメトリクスを公開します。ディスクメトリクス (`disk_used_percent`、`disk_inodes_free`) の数は `device/fstype/path` ディメンションの数によって異なります。diskio メトリクス (`diskio_io_time`) は `name` ディメンションの数によって異なります。例えば、EC2 コンソール操作機能のデフォルト設定での単一の t2.micro では、合計 22 個の CloudWatch エージェントメトリクス (4 CPU、12 ディスク、4 diskio、1 メモリ、1 スワップ) が生成されます。`AWS/EC2` などの公開メトリクスは無料で提供されます。
+ 1 つのカスタムダッシュボード。
+ CloudWatch エージェントによってメトリクスの公開がリクエストされた API オペレーション。このソリューションのデフォルト設定では、CloudWatch エージェントは毎分 1 回 **PutMetricData** を呼び出します。つまり、**PutMetricData** API は EC2 ホストごとに 30 日の月には `30*24*60=43,200` 回呼び出されます。
CloudWatch の料金の詳細については、「[Amazon CloudWatch の料金](https://aws.amazon.com/cloudwatch/pricing/)」をご覧ください。
料金計算ツールを使用すると、このソリューションを使用するためのおよその月額コストを見積もることができます。
**料金計算ツールを使用して毎月のソリューションのコストを見積もるには**
1. [Amazon CloudWatch 料金計算ツール](https://calculator.aws/#/createCalculator/CloudWatch)を開きます。
1. **[メトリクス]** セクションの **[メトリクスの数]** に **(6 \$1 total count of disk and diskio metrics per EC2 host as described above) \$1 number of EC2 instances configured for this solution** を入力します。
1. **[API]** セクションの **[API リクエストの数]** に **43200 \$1 number of EC2 instances configured for this solution** を入力します。
1. デフォルトでは、ソリューションは EC2 ホストごとに毎分 1 回 **PutMetricData** オペレーションを実行します。
1. **[ダッシュボードとアラーム]** セクションの **[ダッシュボードの数]** に「**1**」と入力します。
1. 毎月の見積コストは、料金計算ツールの下部に表示されます。
## このソリューションの CloudWatch エージェント設定
CloudWatch エージェントは、サーバー上およびコンテナ化された環境で継続的かつ自律的に実行されるソフトウェアです。インフラストラクチャとアプリケーションからメトリクス、ログ、トレースを収集し、CloudWatch と X-Ray に送信します。
Amazon CloudWatch エージェントの詳細については「[CloudWatch エージェントを使用してメトリクス、ログ、トレースを収集する](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Install-CloudWatch-Agent.html)」を参照してください。
このソリューションのエージェント設定では、EC2 インスタンスのモニタリングと観測を開始するのに役立つ一連のメトリクスを収集します。CloudWatch エージェントは、ダッシュボードのデフォルトで表示されるよりも多くの EC2 メトリクスを収集するように設定できます。Amazon EC2 メトリクスのリストについては、「[Linux および macOS インスタンスで CloudWatch エージェントにより収集されるメトリクス](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/metrics-collected-by-CloudWatch-agent.html#linux-metrics-enabled-by-CloudWatch-agent)」を参照してください。Windows インスタンスで収集されるメトリクスについては、「[Windows Server インスタンスで CloudWatch エージェントにより収集されるメトリクス](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/metrics-collected-by-CloudWatch-agent.html#windows-metrics-enabled-by-CloudWatch-agent)」を参照してください。
### EC2 Health ソリューションのエージェント設定
エージェントによって収集されるメトリクスは、エージェント設定で定義されます。このソリューションには、ソリューションのダッシュボードに適したディメンションで推奨メトリクスを収集するためのエージェント設定が用意されています。
ソリューションをデプロイする手順については、「[ソリューションにエージェントをデプロイする](#Solution-EC2-Health-Deploy)」で後述します。以下の情報は、環境に合わせてエージェント設定をカスタマイズする方法を理解するのに役立ちます。
**注記**
EC2 インスタンスが Auto Scaling グループの一部でない場合、CloudWatch エージェントは `AutoScalingGroupName` ディメンションをすべて削除します。この動作は、null 値や空の値を持つディメンション名を防ぐのに役立ちます。ソリューションダッシュボードに含まれる各メトリクスウィジェットは、`AutoScalingGroup` ディメンションを含むメトリクスと含まないメトリクスを検索します。これにより、ソリューションが適用されるすべての EC2 インスタンスが同じダッシュボードでサポートされるようになります。
エージェント設定に何らかの変更を加える場合は、ソリューションに付随するダッシュボードに同じ変更を適用する必要があります。例えば、ImageId ディメンションを省略する場合は、ダッシュボードウィジェットで使用されるメトリクス検索式から同じディメンションを削除する必要があります。
### EC2 インスタンスのエージェント設定
ワークロードがデプロイされている Amazon EC2 インスタンスでは、次の CloudWatch エージェント設定を使用します。
```
{
"agent": {
"metrics_collection_interval": 60,
"run_as_user": "cwagent"
},
"metrics": {
"append_dimensions": {
"InstanceId": "${aws:InstanceId}",
"InstanceType": "${aws:InstanceType}",
"ImageId": "${aws:ImageId}",
"AutoScalingGroupName": "${aws:AutoScalingGroupName}"
},
"metrics_collected": {
"cpu": {
"measurement": [
"cpu_usage_idle",
"cpu_usage_iowait",
"cpu_usage_user",
"cpu_usage_system"
],
"totalcpu": true
},
"disk": {
"measurement": [
"used_percent",
"inodes_free"
],
"resources": [
"*"
],
"dimensions": [
["device", "fstype", "path"]
]
},
"diskio": {
"measurement": [
"io_time"
],
"resources": [
"*"
]
},
"mem": {
"measurement": [
"used_percent"
]
},
"swap": {
"measurement": [
"used_percent"
]
}
}
}
}
```
## ソリューションにエージェントをデプロイする
ユースケースに応じて、CloudWatch エージェントをインストールするためのいくつかのアプローチがあります。このソリューションには Systems Manager を使用することをお勧めします。これにより、コンソール操作機能が提供され、1 つの AWS アカウント内のマネージドサーバーのフリートの管理が簡単になります。このセクションの手順では Systems Manager を使用し、CloudWatch エージェントを既存の設定で実行していない場合を対象としています。CloudWatch エージェントが実行されているかどうかは、「[CloudWatch エージェントが実行されていることを確認する](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/troubleshooting-CloudWatch-Agent.html#CloudWatch-Agent-troubleshooting-verify-running)」の手順に従って確認できます。
EC2 ホストで CloudWatch エージェントを既に実行していて、エージェント設定を管理している場合は、このセクションの手順をスキップし、既存のデプロイメカニズムに従って設定を更新できます。EC2 Health エージェント設定を既存のエージェント設定とマージしてから、マージされた設定をデプロイするようにしてください。Systems Manager を使用して CloudWatch エージェントの設定を保存および管理している場合は、設定を既存のパラメータ値にマージできます。詳細については、「[CloudWatch エージェント設定ファイルの管理](https://docs.aws.amazon.com/prescriptive-guidance/latest/implementing-logging-monitoring-cloudwatch/create-store-cloudwatch-configurations.html)」を参照してください。
**注記**
Systems Manager を使用して次の CloudWatch エージェント設定をデプロイすると、EC2 インスタンスの既存の CloudWatch エージェント設定がある場合は置き換えられるか、上書きされます。独自の環境やユースケースに合わせてこの設定を変更できます。設定で定義されているメトリクスは、ソリューションを提供するダッシュボードに最小限必要なものです。
このデプロイプロセスには、以下のステップが含まれます。
+ ステップ 1: ターゲット EC2 インスタンスに必要な IAM アクセス許可があることを確認します。
+ ステップ 2: 推奨エージェント設定ファイルを Systems Manager パラメータストアに保存します。
+ ステップ 3: CloudFormation スタックを使用して 1 つまたは複数の EC2 インスタンスに CloudWatch エージェントをインストールします。
+ ステップ 4: エージェントのセットアップが正しく設定されていることを確認します。
### ステップ 1: ターゲット EC2 インスタンスに必要な IAM アクセス許可があることを確認する
CloudWatch エージェントをインストールして設定するためのアクセス許可を Systems Manager に付与する必要があります。また、EC2 インスタンスから CloudWatch にテレメトリを発行するアクセス許可を CloudWatch エージェントに付与する必要もあります。インスタンスにアタッチされた IAM ロールに **CloudWatchAgentServerPolicy** と **AmazonSSMManagedInstanceCore** の IAM ポリシーがアタッチされていることを確認します。
+ ロールを作成したら、ロールを EC2 インスタンスにアタッチします。EC2 インスタンスにロールをアタッチするには、「[インスタンスへの IAM ロールのアタッチ](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/attach-iam-role.html)」の手順に従います。
### ステップ 2: 推奨 CloudWatch エージェント設定ファイルを Systems Manager パラメータストアに保存する
パラメータストアでは、設定パラメータを安全に保存および管理することで EC2 インスタンスへの CloudWatch エージェントのインストールが簡素化され、ハードコーディングされた値が不要になります。これにより、デプロイプロセスがより安全で柔軟になり、集中管理が可能になり、複数のインスタンスで設定を簡単に更新できるようになります。
以下の手順を使用して、パラメータストアに推奨 CloudWatch エージェント設定ファイルをパラメータとして保存します。
**CloudWatch エージェント設定ファイルをパラメータとして作成するには**
1. AWS Systems Manager コンソール ([https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)) を開きます。
1. コンソールで選択したリージョンが EC2 インスタンスが実行されているリージョンであることを確認します。
1. ナビゲーションペインで **[アプリケーション管理]**、**[パラメータストア]** を選択します。
1. 以下の手順に従って、設定の新しいパラメータを作成します。
1. **[パラメータの作成]** を選択します。
1. **[名前]** ボックスに、後のステップで CloudWatch エージェント設定ファイルを参照するために使用する名前を入力します。例えば、**AmazonCloudWatch-EC2Health-Configuration**。
1. (オプション) **[説明]** ボックスにパラメータの説明を入力します。
1. **[パラメータ階層]** で、**[標準]** を選択します。
1. **[型]** で、**[文字列]** を選択します。
1. **[データ型]** で、**[テキスト]** を選択します。
1. **[値]** ボックスに、このドキュメントで前述したエージェント設定 JSON を貼り付けます。
1. **[パラメータの作成]** を選択します。
### ステップ 3: CloudWatch エージェントをインストールし、CloudFormation テンプレートを使用して設定を適用する
CloudFormation を使用してエージェントをインストールし、これまでの手順で作成した CloudWatch エージェント設定を使用するように設定できます。
**このソリューションの CloudWatch エージェントをインストールして設定するには**
1. 次のリンクを使用して、CloudFormation **[スタックのクイック作成]** ウィザードを開きます: [https://console.aws.amazon.com/cloudformation/home?\$1/stacks/quickcreate?templateURL=https://aws-observability-solutions-prod-us-east-1.s3.us-east-1.amazonaws.com/CloudWatchAgent/CFN/v1.0.0/cw-agent-installation-template-1.0.0.json](https://console.aws.amazon.com/cloudformation/home?#/stacks/quickcreate?templateURL=https://aws-observability-solutions-prod-us-east-1.s3.us-east-1.amazonaws.com/CloudWatchAgent/CFN/v1.0.0/cw-agent-installation-template-1.0.0.json)。
1. コンソールで選択したリージョンが EC2 インスタンスが実行されているリージョンであることを確認します。
1. **[スタック名]** にこのスタックを識別する名前 (**CWAgentInstallationStack** など) を入力します。
1. **[パラメータ]** セクションで、以下を指定します。
1. **[CloudWatchAgentConfigSSM]** に、**AmazonCloudWatch-EC2Health-Configuration** など、前に作成したエージェント設定の Systems Manager パラメータの名前を入力します。
1. ターゲットインスタンスを選択するには、2 つのオプションがあります。
1. **[InstanceIds]** に、この設定で CloudWatch エージェントをインストールするインスタンス ID のカンマ区切りリストを指定します。1 つのインスタンスまたは複数のインスタンスを一覧表示できます。
1. 大規模にデプロイする場合は、**[TagKey]** とそれに対応する **[TagValue]** を指定して、このタグと値を持つすべての EC2 インスタンスをターゲットにできます。**[TagKey]** を指定する場合は、対応する **[TagValue]** を指定する必要があります。(Auto Scaling グループの場合、Auto Scaling グループ内のすべてのインスタンスにデプロイするには、**[TagKey]** に **aws:autoscaling:groupName** を指定し、**[TagValue]** に Auto Scaling グループ名を指定します。)
**[InstanceIds]** パラメータと **[TagKeys]** パラメータの両方を指定すると、**[InstanceIds]** が優先され、タグは無視されます。
1. 設定を確認し、**[スタックの作成]** を選択します。
まずテンプレートファイルを編集してカスタマイズする場合は、**[スタックの作成ウィザード]** の **[テンプレートファイルのアップロード]** オプションを選択して、編集したテンプレートをアップロードします。詳細については、「[CloudFormation コンソールからスタックを作成する](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-console-create-stack.html)」を参照してください。次のリンクを使用して、テンプレートをダウンロードできます: [https://aws-observability-solutions-prod-us-east-1.s3.us-east-1.amazonaws.com/CloudWatchAgent/CFN/v1.0.0/cw-agent-installation-template-1.0.0.json](https://aws-observability-solutions-prod-us-east-1.s3.us-east-1.amazonaws.com/CloudWatchAgent/CFN/v1.0.0/cw-agent-installation-template-1.0.0.json)。
**注記**
このステップが完了すると、この Systems Manager パラメータは、ターゲットインスタンスで実行されている CloudWatch エージェントに関連付けられます。これにより、以下のように処理されます。
Systems Manager パラメータが削除されると、エージェントは停止します。
Systems Manager パラメータを編集すると、設定の変更はスケジュールされた頻度 (デフォルトで 30 日) でエージェントに自動的に適用されます。
この Systems Manager パラメータに変更をすぐに適用する場合は、このステップを再度実行する必要があります。関連付けの詳細については、「[AWS Systems Manager の関連付けの使用](https://docs.aws.amazon.com/systems-manager/latest/userguide/state-manager-associations.html)」を参照してください。
### ステップ 4: エージェントのセットアップが正しく設定されていることを確認する
CloudWatch エージェントがインストールされているかどうかは、[CloudWatch エージェントが実行されていることを確認する](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/troubleshooting-CloudWatch-Agent.html#CloudWatch-Agent-troubleshooting-verify-running)」の手順に従って確認できます。CloudWatch エージェントがインストールされておらず、実行されていない場合は、すべてが正しく設定されていることを確認してください。
+ 「[ステップ 1: ターゲット EC2 インスタンスに必要な IAM アクセス許可があることを確認する](#Solution-EC2-Health-Deploy-Step1)」の説明に従って、EC2 インスタンスに正しいアクセス許可を持つロールがアタッチされていることを確認してください。
+ Systems Manager パラメータの JSON が正しく設定されていることを確認してください。「[CloudFormation での CloudWatch エージェントのインストールのトラブルシューティング](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/Install-CloudWatch-Agent-New-Instances-CloudFormation.html#CloudWatch-Agent-CloudFormation-troubleshooting)」の手順に従います。
**EC2 ヘルスメトリクスが CloudWatch に公開されていることを確認するには**
1. CloudWatch コンソールの [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/) を開いてください。
1. **[メトリクス]**、**[すべてのメトリクス]** を選択します。
1. ソリューションをデプロイしたリージョンを選択したことを確認し、**[カスタム名前空間]**、**[CWAgent]** を選択します。
1. `mem_used_percent` など、このドキュメントのエージェント設定セクションに記載されているメトリクスを検索します。これらのメトリクスの結果が表示された場合、メトリクスは CloudWatch に公開されています。
## EC2 Health ソリューションダッシュボードを作成する
このダッシュボードには、EC2 Health メトリクスを示す、新しく出力されるメトリクスが表示されます。このダッシュボードには、1 つのリージョンの EC2 インスタンスのヘルスに寄与する上位の要因が表示されます。寄与する上位の要因のビューには、メトリクスウィジェットあたり上位 10 件が表示されます。これにより、外れ値を一目で特定できます。
ダッシュボードを作成するには、以下のオプションを使用できます。
+ CloudWatch コンソールを使用してダッシュボードを作成します。
+ AWS CloudFormation コンソールを使用してダッシュボードをデプロイします。
+ AWS CloudFormation インフラストラクチャをコードとしてダウンロードし、継続的インテグレーション (CI) オートメーションの一部として統合します。
CloudWatch コンソールを使用してダッシュボードを作成すると、実際に作成して課金される前にダッシュボードをプレビューできます。
**注記**
このソリューションで CloudFormation を使用して作成されたダッシュボードには、ソリューションがデプロイされたリージョンのメトリクスが表示されます。EC2 メトリクスが公開されるリージョンに CloudFormation スタックを必ず作成してください。
CloudWatch エージェント設定で `CWAgent` 以外のカスタム名前空間を指定した場合は、ダッシュボードの CloudFormation テンプレートを変更して、`CWAgent` を、使用しているカスタマイズされた名前空間に置き換える必要があります。
**CloudWatch コンソールを使用してダッシュボードを作成するには**
1. 次のリンクを使用して CloudWatch コンソール **[ダッシュボードの作成]** を開きます: [https://console.aws.amazon.com/cloudwatch/home?\$1dashboards?dashboardTemplate=Ec2LinuxMacOsHealth&referrer=os-catalog](https://console.aws.amazon.com/cloudwatch/home?#dashboards?dashboardTemplate=Ec2LinuxMacOsHealth&referrer=os-catalog)。
1. コンソールで選択したリージョンが EC2 インスタンスが実行されているリージョンであることを確認します。
1. ダッシュボードの名前を入力し、**[ダッシュボードの作成]** を選択します。
このダッシュボードを他のリージョンの類似のダッシュボードと簡単に区別するために、**EC2HealthDashboard-us-east-1** のように、ダッシュボード名にリージョン名を含めることをお勧めします。
1. ダッシュボードをプレビューし、**[保存]** を選択してダッシュボードを作成します。
**CloudFormation を使用してダッシュボードを作成するには**
1. 次のリンクを使用して、CloudFormation **[スタックのクイック作成]** ウィザードを開きます: [https://console.aws.amazon.com/cloudformation/home?\$1/stacks/quickcreate?templateURL=https://aws-observability-solutions-prod-us-east-1.s3.us-east-1.amazonaws.com/EC2\$1Health/CloudWatch/CFN/v1.0.0/dashboard-template-linux-macos-1.0.0.json](https://console.aws.amazon.com/cloudformation/home?#/stacks/quickcreate?templateURL=https://aws-observability-solutions-prod-us-east-1.s3.us-east-1.amazonaws.com/EC2_Health/CloudWatch/CFN/v1.0.0/dashboard-template-linux-macos-1.0.0.json)。
1. コンソールで選択したリージョンが EC2 インスタンスが実行されているリージョンであることを確認します。
1. **[スタック名]** にこのスタックを識別する名前 (`EC2HealthDashboardStack` など) を入力します。
1. **[パラメータ]** セクションで、**[DashboardName]** パラメータにダッシュボードの名前を指定します。
このダッシュボードを他のリージョンの類似のダッシュボードと簡単に区別するために、**EC2HealthDashboard-us-east-1** のように、ダッシュボード名にリージョン名を含めることをお勧めします。
1. **[機能と変換]** で、変換のためのアクセス機能を承認します。CloudFormation は IAM リソースを追加しないことに注意してください。
1. 設定を確認し、**[スタックの作成]** を選択します。
1. スタックステータスが **CREATE\$1COMPLETE** になったら、作成したスタックの **[リソース]** タブを選択し、**[物理 ID]** のリンクを選択してダッシュボードに移動します。コンソールの左側のナビゲーションペインで **[ダッシュボード]** を選択し、**[カスタムダッシュボード]** でダッシュボード名を検索することで、CloudWatch コンソールでダッシュボードにアクセスすることもできます。
何らかの目的でテンプレートファイルを編集してカスタマイズする場合は、**[スタックの作成ウィザード]** の **[テンプレートファイルのアップロード]** オプションを使用して、編集したテンプレートをアップロードできます。詳細については、「[CloudFormation コンソールからスタックを作成する](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/cfn-console-create-stack.html)」を参照してください。次のリンクを使用してテンプレートをダウンロードできます: [https://aws-observability-solutions-prod-us-east-1.s3.us-east-1.amazonaws.com/EC2\$1Health/CloudWatch/CFN/v1.0.0/dashboard-template-linux-macos-1.0.0.json](https://aws-observability-solutions-prod-us-east-1.s3.us-east-1.amazonaws.com/EC2_Health/CloudWatch/CFN/v1.0.0/dashboard-template-linux-macos-1.0.0.json)
## EC2 Health ソリューションダッシュボードの使用を開始する
新しい EC2 モニタリングダッシュボードで試すことができるタスクをいくつか示します。これらのタスクにより、ダッシュボードが正しく機能していることの検証が可能になり、EC2 インスタンスをモニタリングするためにダッシュボードを実際に使用する経験ができます。これらを試すと、ダッシュボードの操作に慣れ、可視化されたメトリクスを解釈できるようになっていきます。
さまざまな CPU 使用率メトリクスをモニタリングする
**[CPU]** セクションで、CPU 使用率メトリクスの配列を調べます。これらは、ユーザープロセス、システムタスク、I/O オペレーションなど、さまざまなアクティビティで CPU リソースがどのように使用されているかに関するインサイトを提供します。一貫して使用率が高いインスタンスや異常なパターンがあるインスタンスがあるか探します。これは、スケーリングや最適化の必要性を示している可能性があります。
さまざまなデバイス間でディスク使用率を分析する
**[ディスク]** セクションに移動して、ストレージ使用量と inode 可用性メトリクスを見つけます。これらは、ストレージスペースまたはファイルシステムリソースが不足しているインスタンスを特定するのに役立ちます。ディスク使用率が高くなっているインスタンスには注意してください。パフォーマンスの問題やサービスの中断につながる可能性があります。
メモリ使用率パターンを調査する
**[メモリ]** セクションで、メモリ使用率を経時的にプロットするグラフを観察します。これは、各インスタンスで使用可能なメモリがどれだけ使用されているかを示しています。特定の時間やイベントと相関する可能性のある、メモリ使用量のパターンや急増を探します。メモリ使用率が高い場合は、インスタンスのサイズ変更やアプリケーションの最適化が必要になる可能性があります。
コア使用率メトリクス間のパターンの相関を見る
関連する使用率パターンを比較して注意を払います。例えば、ログローテーションプロセスを実行するワークロードでは、定期的に **CPU** と**メモリ**の使用率が増加した後に**ディスク**の使用率が低下する可能性があります。
ネットワークアクティビティを検査する
**[ネットワーク]** セクションで、インバウンドおよびアウトバウンドのネットワークトラフィックメトリクスを、データボリュームとパケット数の両方の観点から調べます。これらは、EC2 インスタンスのネットワークアクティビティに関するインサイトを提供します。ネットワークトラフィックの定期的な急増や通常と異なる急増、またはインバウンドデータとアウトバウンドデータの不均衡に注意します。