# 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 \+ average number of disk paths per EC2 host) \* number of EC2 instances configured for this solution** を入力します。 1. **[API]** セクションの **[API リクエストの数]** に **43200 \* 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?\#/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=\\"G1 Young Generation\\"** を **name=\\"Parallel GC\\"** に変更します。 1. 次のリンクを使用して CloudWatch コンソール **[ダッシュボードの作成]** を開きます: [https://console.aws.amazon.com/cloudwatch/home?\#dashboards?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?\#/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](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\_COMPLETE** になったら、作成したスタックの **[リソース]** タブを選択し、**[物理 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\_EC2/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=\\"G1 Young Generation\\"** を **name=\\"Parallel GC\\"** に変更します。 ### JVM ダッシュボードの使用を開始する 新しい JVM ダッシュボードで試すことができるタスクをいくつか示します。これらのタスクにより、ダッシュボードが正しく機能していることの検証が可能になり、JVM プロセスグループをモニタリングするためにダッシュボードを実際に使用する経験ができます。これらを試すと、ダッシュボードの操作に慣れ、可視化されたメトリクスを解釈できるようになっていきます。 **プロセスグループを選択する** **[JVM プロセスグループ名]** ドロップダウンリストを使用して、モニタリングするプロセスグループを選択します。ダッシュボードは自動的に更新されて、選択したプロセスグループのメトリクスが表示されます。複数の Java アプリケーションまたは環境がある場合、それぞれが別々のプロセスグループとして表される場合があります。適切なプロセスグループを選択すると、分析するアプリケーションまたは環境に固有のメトリクスを表示できます。 **メモリ使用率を確認する** ダッシュボードの概要セクションから、**[ヒープメモリ使用率 (%)]** ウィジェットと **[非ヒープメモリ使用率 (%)]** ウィジェットを見つけます。これらは、選択したプロセスグループ内のすべての JVM で使用されているヒープメモリと非ヒープメモリの使用率を示しています。使用率が高いと、メモリにプレッシャーがかかっている可能性があります。これはパフォーマンスの問題や `OutOfMemoryError` 例外につながる可能性があります。また、**[ホスト別のメモリ使用率]** でホスト別のヒープ使用率の内訳を確認して、使用率の高いホストをチェックすることもできます。 **スレッドとロードされたクラスを分析する** **[ホスト別のスレッドとロードされたクラス]** セクションで、**[上位 10 のスレッド数]** ウィジェットと **[ロードされた上位 10 のクラス]** ウィジェットを見つけます。スレッド数またはクラス数が他と比較して異常に多い JVM がないか探します。スレッドが多すぎることは、スレッドリークや過剰な同時実行を示している可能性があり、ロードされたクラスが多いことは、クラスローダーリークや非効率的な動的クラス生成を示している可能性があります。 **ガベージコレクションの問題を特定する** **[ガベージコレクション]** セクションで、**Young**、**Concurrent**、**Mixed** の各ガベージコレクタータイプに対して、**[1 分あたりのガベージコレクションの呼び出し上位 10 件]** ウィジェットと、**[ガベージコレクションの持続時間上位 10 件**] ウィジェットを見つけます。他と比較して非常にコレクションが多い JVM やコレクションの持続時間が長い JVM がないか探します。これは、設定の問題やメモリリークを示している可能性があります。