# CloudWatch エージェントを使用してメトリクス、ログ、トレースを収集する
CloudWatch エージェントは、Amazon EC2 インスタンス、オンプレミスサーバー、コンテナ化されたアプリケーションからメトリクス、ログ、トレースを収集するソフトウェアコンポーネントです。このエージェントにより、デフォルトで提供される基本的なモニタリングよりもさらに包括的にインフラストラクチャとアプリケーションをモニタリングできます。
**主な利点**
+ システムレベルのメトリクス (CPU、メモリ、ディスク、ネットワーク) を収集する
+ お使いのアプリケーションからカスタムメトリクスを収集する
+ さまざまなソースからログを収集し、一元化する
+ 単一のツールで AWS とオンプレミス環境の両方をモニタリングする
+ 収集したデータに基づいてアラームおよび通知を設定する
CloudWatch エージェントを使用すると、以下のことを実行できます。
+ オペレーティングシステム全体で Amazon EC2 インスタンスから内部システムレベルのメトリクスを収集します。このメトリクスには、EC2 インスタンスのメトリクスに加えて、ゲスト内メトリクスを含めることができます。収集することができる追加のメトリクスについては、「[CloudWatch エージェントにより収集されるメトリクス](metrics-collected-by-CloudWatch-agent.md)」を参照してください。
+ オンプレミスサーバーからシステムレベルのメトリクスを収集します。これには、ハイブリッド環境のサーバーや AWS によって管理されていないサーバーも含まれる可能性があります。
+ カスタムメトリクスは、`StatsD` および `collectd` プロトコルを使用して、アプリケーションまたはサービスから取得します。`StatsD` は、Linux サーバーと、Windows Server を実行するサーバーの両方でサポートされています。`collectd` は、Linux サーバーでのみサポートされています。
+ Linux または Windows Server を実行している Amazon EC2 インスタンスおよびオンプレミスサーバーから､ログを収集します。
**注記**
CloudWatch エージェントは、FIFO パイプからのログの収集をサポートしていません。
+ メトリクスを CloudWatch または Amazon Managed Service for Prometheus、またはその両方に送信します。CloudWatch エージェント設定ファイルには、`metrics` セクションに `metrics_destinations` パラメータが含まれています。このパラメータでは、`cloudwatch`、`amp`、またはその両方を指定できます。
+ バージョン 1.300031.0 以降を使用すると、CloudWatch Application Signals が使用可能になります。詳細については、「[Application Signals](CloudWatch-Application-Monitoring-Sections.md)」を参照してください。
+ バージョン 1.300025.0 以降では、[OpenTelemetry](https://docs.aws.amazon.com/xray/latest/devguide/xray-instrumenting-your-app.html#xray-instrumenting-opentel) または [X-Ray](https://docs.aws.amazon.com/xray/latest/devguide/xray-instrumenting-your-app.html#xray-instrumenting-xray-sdk) クライアント SDK からトレースを収集し、それらを X-Ray に送信できます。
CloudWatch エージェントを使用すると、別途トレース収集デーモンを実行しなくてもトレースを収集できるため、実行および管理するエージェントの数を減らすことができます。
CloudWatch に送信されたメトリクスは、他の CloudWatch メトリクスと同様に CloudWatch で表示できます。CloudWatch エージェントにより収集されるメトリクスのデフォルトの CloudWatch 名前空間は `CWAgent` ですが、エージェントを設定するときに別の名前空間を指定することもできます。
CloudWatch エージェントによって収集されたログは、古い CloudWatch Logs エージェントによって収集されたログと同様に、Amazon CloudWatch Logs に処理され、保存されます。CloudWatch Logs の料金の詳細については、[Amazon CloudWatch の料金](https://aws.amazon.com/cloudwatch/pricing)をご覧ください。
CloudWatch エージェントによって収集されたメトリクスは、カスタムメトリクスとして請求されます。CloudWatch メトリクスの料金の詳細については、「[Amazon CloudWatch の料金](https://aws.amazon.com/cloudwatch/pricing)」を参照してください。
CloudWatch エージェントは MIT ライセンスの下でオープンソースであり、[GitHub でホスト](https://github.com/aws/amazon-cloudwatch-agent/)されています。CloudWatch エージェントの構築、カスタマイズ、または貢献をご希望の場合は、最新の手順について GitHub リポジトリを参照してください。セキュリティの問題の兆候を見つけても、GitHub などの公開フォーラムに投稿しないでください。代わりに、[脆弱性レポート](https://aws.amazon.com/security/vulnerability-reporting/)または [AWS セキュリティに直接 E メールを送信する](mailto:aws-security@amazon.com)の手順に従ってください。
CloudWatch エージェントは、コマンドラインを使用して手動でダウンロードおよびインストールできます。あるいは、AWS Systems Manager と統合することもできます。CloudWatch エージェントをインストールする一般的な流れは次のとおりです。
1. IAM ロールまたはユーザーを作成し、エージェントでサーバーからメトリクスを収集するか、必要に応じて AWS Systems Manager と統合できるようにします。
1. エージェントパッケージをダウンロードします。
1. CloudWatch エージェント設定ファイルを変更して、収集するメトリクスを指定します。
1. サーバーにエージェントをインストールして起動します。
**Topics**
+ [
# サポートされるオペレーティングシステム
](supported-operating-systems.md)
+ [
# 前提条件
](prerequisites.md)
+ [
# CloudWatch エージェントパッケージをダウンロードする
](download-CloudWatch-Agent-on-EC2-Instance-commandline-first.md)
+ [
# CloudWatch エージェントパッケージの署名の検証
](verify-CloudWatch-Agent-Package-Signature.md)
+ [
# CloudWatch エージェントのインストール
](install-CloudWatch-Agent-on-EC2-Instance.md)
+ [
# Security-Enhanced Linux (SELinux) で CloudWatch エージェントをセットアップする
](CloudWatch-Agent-SELinux.md)
+ [
# CloudWatch エージェント設定ファイルを作成する
](create-cloudwatch-agent-configuration-file.md)
+ [
# CloudWatch エージェントの起動
](start-CloudWatch-Agent-on-premise-SSM-onprem.md)
+ [
# CloudWatch エージェントにより収集されるメトリクス
](metrics-collected-by-CloudWatch-agent.md)
+ [
# 関連するテレメトリで CloudWatch エージェントの使用
](CloudWatch-Agent-RelatedEntities.md)
+ [
# CloudWatch エージェントの一般的なシナリオ
](CloudWatch-Agent-common-scenarios.md)
+ [
# CloudWatch エージェント認証情報の優先設定
](CloudWatch-Agent-Credentials-Preference.md)
+ [
# CloudWatch エージェントのトラブルシューティング
](troubleshooting-CloudWatch-Agent.md)
# サポートされるオペレーティングシステム
CloudWatch エージェントは、以下のオペレーティングシステムでサポートされています。
## x86-64 アーキテクチャ
+ Amazon Linux 2023
+ Amazon Linux 2
+ Ubuntu Server バージョン 25.04、24.04 および 22.04
+ Red Hat Enterprise Linux (RHEL) バージョン 10、9、および 8
+ Debian バージョン 12
+ SUSE Linux Enterprise Server (SLES) バージョン 15
+ Oracle Linux バージョン 9 および 8
+ AlmaLinux バージョン 10、9、および 8
+ Rocky Linux バージョン 10、9、および 8
+ macOS コンピュータ: EC2 M1 Mac1 インスタンスおよび macOS 14 (Sonoma)、macOS 13 (Ventura)、macOS 12 (Monterey) で動作しているコンピュータ
+ Windows Server 2025、Windows Server 2022、Windows Server 2019、Windows Server 2016
+ Windows 11
+ 64 ビット Windows 10
## ARM64 アーキテクチャ
+ Amazon Linux 2023
+ Amazon Linux 2
+ Ubuntu Server バージョン 22.04
+ Red Hat Enterprise Linux (RHEL) バージョン 9 および 8
+ Debian バージョン 12
+ SUSE Linux Enterprise Server 15
+ macOS コンピュータ: macOS 14 (Sonoma)、macOS 13 (Ventura)、macOS 12 (Monterey)
# 前提条件
CloudWatch エージェントを初めてインストールする場合は、事前に以下の前提条件が満たされていることを確認してください。
## CloudWatch エージェント用の IAM ロールとユーザー
AWS リソースにアクセスするには、アクセス権限が必要です。IAM ロール、IAM ユーザー、またはその両方を作成して、CloudWatch エージェントが CloudWatch にメトリクスを書き込むために必要なアクセス許可を付与します。
### Amazon EC2 インスタンス用の IAM ロールを作成する
Amazon EC2 インスタンスで CloudWatch エージェントを実行する場合は、IAM ロールを作成して必要なアクセス許可を付与します。
1. [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/) で AWS マネジメントコンソールにサインインして、IAM コンソールを開きます。
1. ナビゲーションペインで、**[ロール]**、**[ロールを作成]** の順に選択します。
1. **[信頼されたエンティティタイプ]** で、**[AWS のサービス]** が選択されていることを確認します。
1. **[ユースケース]** の **[一般的なユースケース]** で、**[EC2]** を選択します。
1. [**次へ**] を選択します。
1. ポリシーのリストで、[**CloudWatchAgentServerPolicy**] の横にあるチェックボックスを選択します。必要に応じて、検索ボックスを使用してポリシーを見つけます。
1. [**次へ**] を選択します。
1. **[Role name]** (ロール名) に、このロールの名前 (`CloudWatchAgentServerRole` など) を入力します。必要に応じて説明を入力します。続いて、[**Create role**] を選択します。
(オプション) エージェントが CloudWatch Logs にログを送信する予定であり、エージェントがこれらのロググループの保持ポリシーを設定できるようにする場合は、ロールに `logs:PutRetentionPolicy` 許可を追加する必要があります。
### オンプレミスサーバー用に IAM ユーザーを作成する
オンプレミスサーバーで CloudWatch エージェントを実行する場合は、IAM ユーザーを作成して必要なアクセス許可を付与します。
**注記**
このシナリオでは、プログラムによるアクセスと長期的な認証情報を持つ IAM ユーザーが必要です。これはセキュリティ上のリスクをもたらします。このリスクを軽減するために、これらのユーザーにはタスクの実行に必要な権限のみを付与し、不要になったユーザーは削除することをお勧めします。
1. [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/) で AWS マネジメントコンソールにサインインして、IAM コンソールを開きます。
1. ナビゲーションペインで、**[ユーザー]**、**[ユーザーを追加]** の順に選択します。
1. 新しいユーザーのユーザー名を入力します。
1. **[Access key - Programmatic access]** (アクセスキー - プログラムによるアクセス)、**[Next: Permissions]** (次へ: 許可) の順に選択します。
1. **[Attach existing policies directly (既存のポリシーを直接アタッチする)**] を選択します。
1. ポリシーのリストで、[**CloudWatchAgentServerPolicy**] の横にあるチェックボックスを選択します。必要に応じて、検索ボックスを使用してポリシーを見つけます。
1. **[Next: Tags]** (次へ: タグ) を選択します。
1. 必要に応じて、新しい IAM のタグを作成し、**[次へ: 確認]** を選択します。
1. 適切なポリシーがリストされていることを確認し、**[Create user]** (ユーザーを作成) を選択します。
1. 新しいユーザーの名前の横にある [**Show**] を選択します。エージェントのイントール時に使用できるように、アクセスキーとシークレットキーをファイルにコピーします。[**閉じる**] を選択してください。
### Amazon EC2 インスタンスに IAM ロールをアタッチする
CloudWatch エージェントで、Amazon EC2 インスタンスのデータを送信できるようにするには、作成した IAM ロールをインスタンスにアタッチする必要があります。
IAM ロールをインスタンスにアタッチする方法の詳細については、「Amazon Elastic Compute Cloud ユーザーガイド」の「[Amazon EC2 の IAM ロール](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/iam-roles-for-amazon-ec2.html#attach-iam-role)」を参照してください。
### CloudWatch エージェントによるログの保持ポリシーの設定を許可
CloudWatch エージェントを構成して、ログイベントの送信先となるロググループ用の保持ポリシーを設定できます。これを実行する場合は、エージェントが使用する IAM ロールまたはユーザに `logs:PutRetentionPolicy` を付与する必要があります。エージェントは IAM ロールを使用して Amazon EC2 インスタンスで実行し、オンプレミスのサーバーに IAM ユーザーを使用します。
**CloudWatch エージェントの IAM ロールにログの保持ポリシーを設定するための許可を付与するには**
1. AWS マネジメントコンソール にサインインして、IAM コンソール [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/) を開きます。
1. 左のナビゲーションペインで、**[Roles (ロール)]** を選択してください。
1. 検索ボックスで、CloudWatch エージェントの IAM ロールの名前の先頭を入力します。この名前は、ロールの作成時に選択されました。`CloudWatchAgentServerRole` という名前が付けられる場合があります。
ロールが表示されたら、ロールの名前を選択します。
1. **[Permissions]** (許可) タブで、**[Add permissions]** (許可の追加)、**[Create inline policy]** (インラインポリシーの作成) をクリックします。
1. **[JSON]** タブを選択し、次のポリシーをボックスにコピーして、ボックスのデフォルトの JSON を置き換えます。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "logs:PutRetentionPolicy",
"Resource": "*"
}
]
}
```
------
1. **[ポリシーの確認]** を選択します。
1. **[Name]** (名前) で、**CloudWatchAgentPutLogsRetention** などと入力し、**[Create policy]** (ポリシーを作成) を選択します。
**CloudWatch エージェントの IAM ユーザーにログ保持ポリシーを設定するための許可を付与するには**
1. AWS マネジメントコンソール にサインインして、IAM コンソール [https://console.aws.amazon.com/iam/](https://console.aws.amazon.com/iam/) を開きます。
1. 左のナビゲーションペインで、**[ユーザー]** を選択します。
1. 検索ボックスで、CloudWatch エージェントの IAM ユーザーの名前の先頭を入力します。この名前は、ユーザーの作成時に選択されました。
ユーザーが表示されたら、ユーザーの名前を選択します。
1. [**アクセス許可**] タブで [**インラインポリシーの追加**] を選択します。
1. **[JSON]** タブを選択し、次のポリシーをボックスにコピーして、ボックスのデフォルトの JSON を置き換えます。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "logs:PutRetentionPolicy",
"Resource": "*"
}
]
}
```
------
1. **[ポリシーの確認]** を選択します。
1. **[Name]** (名前) で、**CloudWatchAgentPutLogsRetention** などと入力し、**[Create policy]** (ポリシーを作成) を選択します。
## ネットワークの要件
**注記**
サーバーがパブリックサブネット内にあるときは、インターネットゲートウェイにアクセスできることを確認してください。サーバーがプライベートサブネット内にあるときは、NAT ゲートウェイまたは VPC エンドポイントを介してアクセスされます。詳細については、「[https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html](https://docs.aws.amazon.com/vpc/latest/userguide/vpc-nat-gateway.html)」を参照してください。
CloudWatch または CloudWatch Logs にデータを送信するには、Amazon EC2 インスタンスにアウトバウンドインターネットアクセスが必要です。インターネットアクセスの詳しい設定方法については、「Amazon VPC ユーザーガイド」の「[インターネットゲートウェイ](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Internet_Gateway.html)」を参照してください。
### VPC エンドポイントの使用
VPC を使用しているときに、パブリックインターネットからアクセスすることなく CloudWatch エージェントを使用できるようにする場合は、CloudWatch および CloudWatch Logs 用に VPC エンドポイントを設定できます。
プロキシで設定するエンドポイントとポートは、次のとおりです。
+ エージェントを使用してメトリクスを収集する場合は、適切なリージョンの CloudWatch エンドポイントを許可リストに追加する必要があります。これらのエンドポイントは、「[Amazon CloudWatch エンドポイントとクォータ](https://docs.aws.amazon.com/general/latest/gr/cw_region.html)」に記載されています。
+ エージェントを使用してログを収集する場合は、適切なリージョンの CloudWatch Logs エンドポイントを許可リストに追加する必要があります。これらのエンドポイントは、「[Amazon CloudWatch Logs エンドポイントとクォータ](https://docs.aws.amazon.com/general/latest/gr/cwl_region.html)」に記載されています。
+ Systems Manager を使用してエージェントをインストールするか、Parameter Store を使用して設定ファイルを保存する場合は、適切なリージョンの Systems Manager エンドポイントを許可リストに追加する必要があります。これらのエンドポイントは、「[AWS Systems Manager エンドポイントとクォータ](https://docs.aws.amazon.com/general/latest/gr/ssm.html)」に記載されています。
# CloudWatch エージェントパッケージをダウンロードする
**注記**
CloudWatch エージェントをダウンロードするには、接続に TLS 1.2 以降を使用する必要があります。
CloudWatch エージェントは、Amazon Linux 2023 および Amazon Linux 2 でパッケージとして利用できます。このオペレーティングシステムを使用している場合は、以下のコマンドを入力してパッケージをインストールできます。また、インスタンスにアタッチされた IAM ロールに **CloudWatchAgentServerPolicy** がアタッチされていることを確認する必要もあります。
```
sudo yum install amazon-cloudwatch-agent
```
サポートされているすべてのオペレーティングシステムで、コマンドラインを使用して、CloudWatch エージェントをダウンロードしてインストールできます。
ダウンロードリンクごとに、全般的なリンクと各 AWS リージョンのリンクがあります。
リージョン固有のリンクを使用する場合は、デフォルトのリージョン (*us-east-1*) をアカウントに適したリージョンに置き換えます。例えば、Amazon Linux 2023、Amazon Linux 2、x86-64 アーキテクチャの場合、有効なダウンロードリンクは次の 3 つです。
+ `https://amazoncloudwatch-agent.s3.amazonaws.com/amazon_linux/amd64/latest/amazon-cloudwatch-agent.rpm`
+ `https://amazoncloudwatch-agent-us-east-1.s3.us-east-1.amazonaws.com/amazon_linux/amd64/latest/amazon-cloudwatch-agent.rpm`
+ `https://amazoncloudwatch-agent-eu-central-1.s3.eu-central-1.amazonaws.com/amazon_linux/amd64/latest/amazon-cloudwatch-agent.rpm`
エージェントに対する最新の変更に関する README ファイル、およびダウンロード可能なバージョン番号を示すファイルをダウンロードすることもできます。これらのファイルは次の場所にあります。
**注記**
リージョン固有のリンクを使用する場合は、デフォルトのリージョン (*us-east-1*) をアカウントに適したリージョンに置き換えます。
+ `https://amazoncloudwatch-agent.s3.amazonaws.com/info/latest/RELEASE_NOTES` 、、または `https://amazoncloudwatch-agent-us-east-1.s3.us-east-1.amazonaws.com/info/latest/RELEASE_NOTES`
+ `https://amazoncloudwatch-agent.s3.amazonaws.com/info/latest/CWAGENT_VERSION` 、、または `https://amazoncloudwatch-agent-us-east-1.s3.us-east-1.amazonaws.com/info/latest/CWAGENT_VERSION`
| アーキテクチャ | プラットフォーム | ダウンロードリンク | 署名ファイルリンク |
| --- | --- | --- | --- |
| x86-64 | Amazon Linux 2023 および Amazon Linux 2 | https://amazoncloudwatch-agent.s3.amazonaws.com/amazon\$1linux/amd64/latest/amazon-cloudwatch-agent.rpm https://amazoncloudwatch-agent-*us-east-1*.s3.*us-east-1*.amazonaws.com/amazon\$1linux/amd64/latest/amazon-cloudwatch-agent.rpm | https://amazoncloudwatch-agent.s3.amazonaws.com/amazon\$1linux/amd64/latest/amazon-cloudwatch-agent.rpm.sig https://amazoncloudwatch-agent-*us-east-1*.s3.*us-east-1*.amazonaws.com/amazon\$1linux/amd64/latest/amazon-cloudwatch-agent.rpm.sig |
| x86-64 | CentOS | https://amazoncloudwatch-agent.s3.amazonaws.com/centos/amd64/latest/amazon-cloudwatch-agent.rpm https://amazoncloudwatch-agent-*us-east-1*.s3.*us-east-1*.amazonaws.com/centos/amd64/latest/amazon-cloudwatch-agent.rpm | https://amazoncloudwatch-agent.s3.amazonaws.com/centos/amd64/latest/amazon-cloudwatch-agent.rpm.sig https://amazoncloudwatch-agent-*us-east-1*.s3.*us-east-1*.amazonaws.com/centos/amd64/latest/amazon-cloudwatch-agent.rpm.sig |
| x86-64 | Red Hat | https://amazoncloudwatch-agent.s3.amazonaws.com/redhat/amd64/latest/amazon-cloudwatch-agent.rpm https://amazoncloudwatch-agent-*us-east-1*.s3.*us-east-1*.amazonaws.com/redhat/amd64/latest/amazon-cloudwatch-agent.rpm | https://amazoncloudwatch-agent.s3.amazonaws.com/redhat/amd64/latest/amazon-cloudwatch-agent.rpm.sig https://amazoncloudwatch-agent-*us-east-1*.s3.*us-east-1*.amazonaws.com/redhat/amd64/latest/amazon-cloudwatch-agent.rpm.sig |
| x86-64 | SUSE | https://amazoncloudwatch-agent.s3.amazonaws.com/suse/amd64/latest/amazon-cloudwatch-agent.rpm https://amazoncloudwatch-agent-*us-east-1*.s3.*us-east-1*.amazonaws.com/suse/amd64/latest/amazon-cloudwatch-agent.rpm | https://amazoncloudwatch-agent.s3.amazonaws.com/suse/amd64/latest/amazon-cloudwatch-agent.rpm.sig https://amazoncloudwatch-agent-*us-east-1*.s3.*us-east-1*.amazonaws.com/suse/amd64/latest/amazon-cloudwatch-agent.rpm.sig |
| x86-64 | Debian | https://amazoncloudwatch-agent.s3.amazonaws.com/debian/amd64/latest/amazon-cloudwatch-agent.deb https://amazoncloudwatch-agent-*us-east-1*.s3.*us-east-1*.amazonaws.com/debian/amd64/latest/amazon-cloudwatch-agent.deb | https://amazoncloudwatch-agent.s3.amazonaws.com/debian/amd64/latest/amazon-cloudwatch-agent.deb.sig https://amazoncloudwatch-agent-*us-east-1*.s3.*us-east-1*.amazonaws.com/debian/amd64/latest/amazon-cloudwatch-agent.deb.sig |
| x86-64 | Ubuntu | https://amazoncloudwatch-agent.s3.amazonaws.com/ubuntu/amd64/latest/amazon-cloudwatch-agent.deb https://amazoncloudwatch-agent-*us-east-1*.s3.*us-east-1*.amazonaws.com/ubuntu/amd64/latest/amazon-cloudwatch-agent.deb | https://amazoncloudwatch-agent.s3.amazonaws.com/ubuntu/amd64/latest/amazon-cloudwatch-agent.deb.sig https://amazoncloudwatch-agent-*us-east-1*.s3.*us-east-1*.amazonaws.com/ubuntu/amd64/latest/amazon-cloudwatch-agent.deb.sig |
| x86-64 | Oracle | https://amazoncloudwatch-agent.s3.amazonaws.com/oracle\$1linux/amd64/latest/amazon-cloudwatch-agent.rpm https://amazoncloudwatch-agent-*us-east-1*.s3.*us-east-1*.amazonaws.com/oracle\$1linux/amd64/latest/amazon-cloudwatch-agent.rpm | https://amazoncloudwatch-agent.s3.amazonaws.com/oracle\$1linux/amd64/latest/amazon-cloudwatch-agent.rpm.sig https://amazoncloudwatch-agent-*us-east-1*.s3.*us-east-1*.amazonaws.com/oracle\$1linux/amd64/latest/amazon-cloudwatch-agent.rpm.sig |
| x86-64 | macOS | https://amazoncloudwatch-agent.s3.amazonaws.com/darwin/amd64/latest/amazon-cloudwatch-agent.pkg https://amazoncloudwatch-agent-*us-east-1*.s3.*us-east-1*.amazonaws.com/darwin/amd64/latest/amazon-cloudwatch-agent.pkg | https://amazoncloudwatch-agent.s3.amazonaws.com/darwin/amd64/latest/amazon-cloudwatch-agent.pkg.sig https://amazoncloudwatch-agent-*us-east-1*.s3.*us-east-1*.amazonaws.com/darwin/amd64/latest/amazon-cloudwatch-agent.pkg.sig |
| x86-64 | Server | https://amazoncloudwatch-agent.s3.amazonaws.com/windows/amd64/latest/amazon-cloudwatch-agent.msi https://amazoncloudwatch-agent-*us-east-1*.s3.*us-east-1*.amazonaws.com/windows/amd64/latest/amazon-cloudwatch-agent.msi | https://amazoncloudwatch-agent.s3.amazonaws.com/windows/amd64/latest/amazon-cloudwatch-agent.msi.sig https://amazoncloudwatch-agent-*us-east-1*.s3.*us-east-1*.amazonaws.com/windows/amd64/latest/amazon-cloudwatch-agent.msi.sig |
| ARM64 | Amazon Linux 2023 および Amazon Linux 2 | https://amazoncloudwatch-agent.s3.amazonaws.com/amazon\$1linux/arm64/latest/amazon-cloudwatch-agent.rpm https://amazoncloudwatch-agent-*us-east-1*.s3.*us-east-1*.amazonaws.com/amazon\$1linux/arm64/latest/amazon-cloudwatch-agent.rpm | https://amazoncloudwatch-agent.s3.amazonaws.com/amazon\$1linux/arm64/latest/amazon-cloudwatch-agent.rpm.sig https://amazoncloudwatch-agent-*us-east-1*.s3.*us-east-1*.amazonaws.com/amazon\$1linux/arm64/latest/amazon-cloudwatch-agent.rpm.sig |
| ARM64 | Red Hat | https://amazoncloudwatch-agent.s3.amazonaws.com/redhat/arm64/latest/amazon-cloudwatch-agent.rpm https://amazoncloudwatch-agent-*us-east-1*.s3.*us-east-1*.amazonaws.com/redhat/arm64/latest/amazon-cloudwatch-agent.rpm | https://amazoncloudwatch-agent.s3.amazonaws.com/redhat/arm64/latest/amazon-cloudwatch-agent.rpm.sig https://amazoncloudwatch-agent-*us-east-1*.s3.*us-east-1*.amazonaws.com/redhat/arm64/latest/amazon-cloudwatch-agent.rpm.sig |
| ARM64 | Ubuntu | https://amazoncloudwatch-agent.s3.amazonaws.com/ubuntu/arm64/latest/amazon-cloudwatch-agent.deb https://amazoncloudwatch-agent-*us-east-1*.s3.*us-east-1*.amazonaws.com/ubuntu/arm64/latest/amazon-cloudwatch-agent.deb | https://amazoncloudwatch-agent.s3.amazonaws.com/ubuntu/arm64/latest/amazon-cloudwatch-agent.deb.sig https://amazoncloudwatch-agent-*us-east-1*.s3.*us-east-1*.amazonaws.com/ubuntu/arm64/latest/amazon-cloudwatch-agent.deb.sig |
| ARM64 | Debian | https://amazoncloudwatch-agent.s3.amazonaws.com/debian/arm64/latest/amazon-cloudwatch-agent.deb https://amazoncloudwatch-agent-*us-east-1*.s3.*us-east-1*.amazonaws.com/debian/arm64/latest/amazon-cloudwatch-agent.deb | https://amazoncloudwatch-agent.s3.amazonaws.com/debian/arm64/latest/amazon-cloudwatch-agent.deb.sig https://amazoncloudwatch-agent-*us-east-1*.s3.*us-east-1*.amazonaws.com/debian/arm64/latest/amazon-cloudwatch-agent.deb.sig |
| ARM64 | SUSE | https://amazoncloudwatch-agent.s3.amazonaws.com/suse/arm64/latest/amazon-cloudwatch-agent.rpm https://amazoncloudwatch-agent-*us-east-1*.s3.*us-east-1*.amazonaws.com/suse/arm64/latest/amazon-cloudwatch-agent.rpm | https://amazoncloudwatch-agent.s3.amazonaws.com/suse/arm64/latest/amazon-cloudwatch-agent.rpm.sig https://amazoncloudwatch-agent-*us-east-1*.s3.*us-east-1*.amazonaws.com/suse/arm64/latest/amazon-cloudwatch-agent.rpm.sig |
| ARM64 | macOS | https://amazoncloudwatch-agent.s3.amazonaws.com/darwin/arm64/latest/amazon-cloudwatch-agent.pkg https://amazoncloudwatch-agent-*us-east-1*.s3.*us-east-1*.amazonaws.com/darwin/arm64/latest/amazon-cloudwatch-agent.pkg | https://amazoncloudwatch-agent.s3.amazonaws.com/darwin/arm64/latest/amazon-cloudwatch-agent.pkg.sig https://amazoncloudwatch-agent-*us-east-1*.s3.*us-east-1*.amazonaws.com/darwin/arm64/latest/amazon-cloudwatch-agent.pkg.sig |
# CloudWatch エージェントパッケージの署名の検証
GPG 署名ファイルは、Linux サーバー上の CloudWatch エージェントパッケージ用として含まれています。公開鍵を使用して、エージェントのダウンロードファイルがオリジナルであり、変更されていないことを確認できます。
Windows Server の場合は、MSI を使用して署名を検証できます。macOS コンピュータの場合、署名はエージェントのダウンロードパッケージに含まれます。
正しい署名ファイルを検索するには、次の表を使用してください。アーキテクチャおよびオペレーティングシステムごとに、全般的なリンクおよび各リージョンのリンクがあります。
リージョン固有のリンクを使用する場合は、デフォルトのリージョン (*us-east-1*) をアカウントに適したリージョンに置き換えます。例えば、Amazon Linux 2023、Amazon Linux 2、x86-64 アーキテクチャの場合、有効なリンクは次の 3 つです。
+ `https://amazoncloudwatch-agent.s3.amazonaws.com/amazon_linux/amd64/latest/amazon-cloudwatch-agent.rpm.sig`
+ `https://amazoncloudwatch-agent-us-east-1.s3.us-east-1.amazonaws.com/amazon_linux/amd64/latest/amazon-cloudwatch-agent.rpm`
+ `https://amazoncloudwatch-agent-eu-central-1.s3.eu-central-1.amazonaws.com/amazon_linux/amd64/latest/amazon-cloudwatch-agent.rpm`
**注記**
CloudWatch エージェントをダウンロードするには、接続に TLS 1.2 以降を使用する必要があります。
| アーキテクチャ | プラットフォーム | ダウンロードリンク | 署名ファイルリンク |
| --- | --- | --- | --- |
| x86-64 | Amazon Linux 2023 および Amazon Linux 2 | https://amazoncloudwatch-agent.s3.amazonaws.com/amazon\$1linux/amd64/latest/amazon-cloudwatch-agent.rpm https://amazoncloudwatch-agent-*us-east-1*.s3.*us-east-1*.amazonaws.com/amazon\$1linux/amd64/latest/amazon-cloudwatch-agent.rpm | https://amazoncloudwatch-agent.s3.amazonaws.com/amazon\$1linux/amd64/latest/amazon-cloudwatch-agent.rpm.sig https://amazoncloudwatch-agent-*us-east-1*.s3.*us-east-1*.amazonaws.com/amazon\$1linux/amd64/latest/amazon-cloudwatch-agent.rpm.sig |
| x86-64 | CentOS | https://amazoncloudwatch-agent.s3.amazonaws.com/centos/amd64/latest/amazon-cloudwatch-agent.rpm https://amazoncloudwatch-agent-*us-east-1*.s3.*us-east-1*.amazonaws.com/centos/amd64/latest/amazon-cloudwatch-agent.rpm | https://amazoncloudwatch-agent.s3.amazonaws.com/centos/amd64/latest/amazon-cloudwatch-agent.rpm.sig https://amazoncloudwatch-agent-*us-east-1*.s3.*us-east-1*.amazonaws.com/centos/amd64/latest/amazon-cloudwatch-agent.rpm.sig |
| x86-64 | Red Hat | https://amazoncloudwatch-agent.s3.amazonaws.com/redhat/amd64/latest/amazon-cloudwatch-agent.rpm https://amazoncloudwatch-agent-*us-east-1*.s3.*us-east-1*.amazonaws.com/redhat/amd64/latest/amazon-cloudwatch-agent.rpm | https://amazoncloudwatch-agent.s3.amazonaws.com/redhat/amd64/latest/amazon-cloudwatch-agent.rpm.sig https://amazoncloudwatch-agent-*us-east-1*.s3.*us-east-1*.amazonaws.com/redhat/amd64/latest/amazon-cloudwatch-agent.rpm.sig |
| x86-64 | SUSE | https://amazoncloudwatch-agent.s3.amazonaws.com/suse/amd64/latest/amazon-cloudwatch-agent.rpm https://amazoncloudwatch-agent-*us-east-1*.s3.*us-east-1*.amazonaws.com/suse/amd64/latest/amazon-cloudwatch-agent.rpm | https://amazoncloudwatch-agent.s3.amazonaws.com/suse/amd64/latest/amazon-cloudwatch-agent.rpm.sig https://amazoncloudwatch-agent-*us-east-1*.s3.*us-east-1*.amazonaws.com/suse/amd64/latest/amazon-cloudwatch-agent.rpm.sig |
| x86-64 | Debian | https://amazoncloudwatch-agent.s3.amazonaws.com/debian/amd64/latest/amazon-cloudwatch-agent.deb https://amazoncloudwatch-agent-*us-east-1*.s3.*us-east-1*.amazonaws.com/debian/amd64/latest/amazon-cloudwatch-agent.deb | https://amazoncloudwatch-agent.s3.amazonaws.com/debian/amd64/latest/amazon-cloudwatch-agent.deb.sig https://amazoncloudwatch-agent-*us-east-1*.s3.*us-east-1*.amazonaws.com/debian/amd64/latest/amazon-cloudwatch-agent.deb.sig |
| x86-64 | Ubuntu | https://amazoncloudwatch-agent.s3.amazonaws.com/ubuntu/amd64/latest/amazon-cloudwatch-agent.deb https://amazoncloudwatch-agent-*us-east-1*.s3.*us-east-1*.amazonaws.com/ubuntu/amd64/latest/amazon-cloudwatch-agent.deb | https://amazoncloudwatch-agent.s3.amazonaws.com/ubuntu/amd64/latest/amazon-cloudwatch-agent.deb.sig https://amazoncloudwatch-agent-*us-east-1*.s3.*us-east-1*.amazonaws.com/ubuntu/amd64/latest/amazon-cloudwatch-agent.deb.sig |
| x86-64 | Oracle | https://amazoncloudwatch-agent.s3.amazonaws.com/oracle\$1linux/amd64/latest/amazon-cloudwatch-agent.rpm https://amazoncloudwatch-agent-*us-east-1*.s3.*us-east-1*.amazonaws.com/oracle\$1linux/amd64/latest/amazon-cloudwatch-agent.rpm | https://amazoncloudwatch-agent.s3.amazonaws.com/oracle\$1linux/amd64/latest/amazon-cloudwatch-agent.rpm.sig https://amazoncloudwatch-agent-*us-east-1*.s3.*us-east-1*.amazonaws.com/oracle\$1linux/amd64/latest/amazon-cloudwatch-agent.rpm.sig |
| x86-64 | macOS | https://amazoncloudwatch-agent.s3.amazonaws.com/darwin/amd64/latest/amazon-cloudwatch-agent.pkg https://amazoncloudwatch-agent-*us-east-1*.s3.*us-east-1*.amazonaws.com/darwin/amd64/latest/amazon-cloudwatch-agent.pkg | https://amazoncloudwatch-agent.s3.amazonaws.com/darwin/amd64/latest/amazon-cloudwatch-agent.pkg.sig https://amazoncloudwatch-agent-*us-east-1*.s3.*us-east-1*.amazonaws.com/darwin/amd64/latest/amazon-cloudwatch-agent.pkg.sig |
| x86-64 | Server | https://amazoncloudwatch-agent.s3.amazonaws.com/windows/amd64/latest/amazon-cloudwatch-agent.msi https://amazoncloudwatch-agent-*us-east-1*.s3.*us-east-1*.amazonaws.com/windows/amd64/latest/amazon-cloudwatch-agent.msi | https://amazoncloudwatch-agent.s3.amazonaws.com/windows/amd64/latest/amazon-cloudwatch-agent.msi.sig https://amazoncloudwatch-agent-*us-east-1*.s3.*us-east-1*.amazonaws.com/windows/amd64/latest/amazon-cloudwatch-agent.msi.sig |
| ARM64 | Amazon Linux 2023 および Amazon Linux 2 | https://amazoncloudwatch-agent.s3.amazonaws.com/amazon\$1linux/arm64/latest/amazon-cloudwatch-agent.rpm https://amazoncloudwatch-agent-*us-east-1*.s3.*us-east-1*.amazonaws.com/amazon\$1linux/arm64/latest/amazon-cloudwatch-agent.rpm | https://amazoncloudwatch-agent.s3.amazonaws.com/amazon\$1linux/arm64/latest/amazon-cloudwatch-agent.rpm.sig https://amazoncloudwatch-agent-*us-east-1*.s3.*us-east-1*.amazonaws.com/amazon\$1linux/arm64/latest/amazon-cloudwatch-agent.rpm.sig |
| ARM64 | Red Hat | https://amazoncloudwatch-agent.s3.amazonaws.com/redhat/arm64/latest/amazon-cloudwatch-agent.rpm https://amazoncloudwatch-agent-*us-east-1*.s3.*us-east-1*.amazonaws.com/redhat/arm64/latest/amazon-cloudwatch-agent.rpm | https://amazoncloudwatch-agent.s3.amazonaws.com/redhat/arm64/latest/amazon-cloudwatch-agent.rpm.sig https://amazoncloudwatch-agent-*us-east-1*.s3.*us-east-1*.amazonaws.com/redhat/arm64/latest/amazon-cloudwatch-agent.rpm.sig |
| ARM64 | Ubuntu | https://amazoncloudwatch-agent.s3.amazonaws.com/ubuntu/arm64/latest/amazon-cloudwatch-agent.deb https://amazoncloudwatch-agent-*us-east-1*.s3.*us-east-1*.amazonaws.com/ubuntu/arm64/latest/amazon-cloudwatch-agent.deb | https://amazoncloudwatch-agent.s3.amazonaws.com/ubuntu/arm64/latest/amazon-cloudwatch-agent.deb.sig https://amazoncloudwatch-agent-*us-east-1*.s3.*us-east-1*.amazonaws.com/ubuntu/arm64/latest/amazon-cloudwatch-agent.deb.sig |
| ARM64 | Debian | https://amazoncloudwatch-agent.s3.amazonaws.com/debian/arm64/latest/amazon-cloudwatch-agent.deb https://amazoncloudwatch-agent-*us-east-1*.s3.*us-east-1*.amazonaws.com/debian/arm64/latest/amazon-cloudwatch-agent.deb | https://amazoncloudwatch-agent.s3.amazonaws.com/debian/arm64/latest/amazon-cloudwatch-agent.deb.sig https://amazoncloudwatch-agent-*us-east-1*.s3.*us-east-1*.amazonaws.com/debian/arm64/latest/amazon-cloudwatch-agent.deb.sig |
| ARM64 | SUSE | https://amazoncloudwatch-agent.s3.amazonaws.com/suse/arm64/latest/amazon-cloudwatch-agent.rpm https://amazoncloudwatch-agent-*us-east-1*.s3.*us-east-1*.amazonaws.com/suse/arm64/latest/amazon-cloudwatch-agent.rpm | https://amazoncloudwatch-agent.s3.amazonaws.com/suse/arm64/latest/amazon-cloudwatch-agent.rpm.sig https://amazoncloudwatch-agent-*us-east-1*.s3.*us-east-1*.amazonaws.com/suse/arm64/latest/amazon-cloudwatch-agent.rpm.sig |
**Linux サーバーで CloudWatch エージェントパッケージを確認するには**
1. 公開鍵をダウンロードします。
```
shell$ wget https://amazoncloudwatch-agent.s3.amazonaws.com/assets/amazon-cloudwatch-agent.gpg
```
1. 公開鍵をキーリングにインポートします。
```
shell$ gpg --import amazon-cloudwatch-agent.gpg
gpg: key 3B789C72: public key "Amazon CloudWatch Agent" imported
gpg: Total number processed: 1
gpg: imported: 1 (RSA: 1)
```
次の手順で必要になるため、キーの値を書きとめておきます。前述の例では、キーの値は `3B789C72` です。
1. 次のコマンドを使用してフィンガープリントを確認し、*キー値*を前述の手順の値と置き換えます。
```
shell$ gpg --fingerprint key-value
pub 2048R/3B789C72 2017-11-14
Key fingerprint = 9376 16F3 450B 7D80 6CBD 9725 D581 6730 3B78 9C72
uid Amazon CloudWatch Agent
```
フィンガープリントは、次のものと同一になる必要があります。
`9376 16F3 450B 7D80 6CBD 9725 D581 6730 3B78 9C72`
フィンガープリント文字列が一致しない場合は、エージェントをインストールしないでください。Amazon Web Services にお問い合わせください。
フィンガープリントを確認したら、それを使用して、CloudWatch エージェントパッケージの署名を確認できます。
1. **wget** を使用して、パッケージ署名ファイルをダウンロードします。正しい署名ファイルを確認するには、前の表を参照してください。
```
wget Signature File Link
```
1. 署名を確認するには、**gpg --verify** を実行します。
```
shell$ gpg --verify signature-filename agent-download-filename
gpg: Signature made Wed 29 Nov 2017 03:00:59 PM PST using RSA key ID 3B789C72
gpg: Good signature from "Amazon CloudWatch Agent"
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Primary key fingerprint: 9376 16F3 450B 7D80 6CBD 9725 D581 6730 3B78 9C72
```
出力結果に「`BAD signature`」という句が含まれる場合、手順が正しいことをもう一度確認してください。このレスポンスが続く場合は、Amazon Web Services に連絡し、ダウンロードしたファイルは使用しないでください。
信頼性に関する警告に注意します。キーは、自分や信頼する人が署名した場合にのみ信頼できます。つまり、署名が無効であるわけではなく、パブリックキーを確認していないことになります。
**Windows Server を実行するサーバーで CloudWatch エージェントパッケージを確認するには**
1. Windows 用の GnuPG を からダウンロードしてインストールします[https://gnupg.org/download/](https://gnupg.org/download/) インストールするときは、[**Shell Extension (GpgEx)**] オプションを含めます。
残りの手順は、Windows PowerShell で実行できます。
1. 公開鍵をダウンロードします。
```
PS> wget https://amazoncloudwatch-agent.s3.amazonaws.com/assets/amazon-cloudwatch-agent.gpg -OutFile amazon-cloudwatch-agent.gpg
```
1. 公開鍵をキーリングにインポートします。
```
PS> gpg --import amazon-cloudwatch-agent.gpg
gpg: key 3B789C72: public key "Amazon CloudWatch Agent" imported
gpg: Total number processed: 1
gpg: imported: 1 (RSA: 1)
```
次の手順で必要になるため、キーの値を書きとめておきます。前述の例では、キーの値は `3B789C72` です。
1. 次のコマンドを使用してフィンガープリントを確認し、*キー値*を前述の手順の値と置き換えます。
```
PS> gpg --fingerprint key-value
pub rsa2048 2017-11-14 [SC]
9376 16F3 450B 7D80 6CBD 9725 D581 6730 3B78 9C72
uid [ unknown] Amazon CloudWatch Agent
```
フィンガープリントは、次のものと同一になる必要があります。
`9376 16F3 450B 7D80 6CBD 9725 D581 6730 3B78 9C72`
フィンガープリント文字列が一致しない場合は、エージェントをインストールしないでください。Amazon Web Services にお問い合わせください。
フィンガープリントを確認したら、それを使用して、CloudWatch エージェントパッケージの署名を確認できます。
1. wget を使用して、パッケージ署名ファイルをダウンロードします。正しい署名ファイルを確認するには、「[CloudWatch エージェントダウンロードリンク](download-CloudWatch-Agent-on-EC2-Instance-commandline-first.md#agent-download-link-table)」を参照してください。
1. 署名を確認するには、**gpg --verify** を実行します。
```
PS> gpg --verify sig-filename agent-download-filename
gpg: Signature made 11/29/17 23:00:45 Coordinated Universal Time
gpg: using RSA key D58167303B789C72
gpg: Good signature from "Amazon CloudWatch Agent" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Primary key fingerprint: 9376 16F3 450B 7D80 6CBD 9725 D581 6730 3B78 9C72
```
出力結果に「`BAD signature`」という句が含まれる場合、手順が正しいことをもう一度確認してください。このレスポンスが続く場合は、Amazon Web Services に連絡し、ダウンロードしたファイルは使用しないでください。
信頼性に関する警告に注意します。キーは、自分や信頼する人が署名した場合にのみ信頼できます。つまり、署名が無効であるわけではなく、パブリックキーを確認していないことになります。
**macOS コンピュータで CloudWatch エージェントパッケージを確認するには**
+ macOS での署名の検証には 2 つの方法があります。
+ 次のコマンドを実行して、フィンガープリントを検証します。
```
pkgutil --check-signature amazon-cloudwatch-agent.pkg
```
次のような結果が表示されます。
```
Package "amazon-cloudwatch-agent.pkg":
Status: signed by a developer certificate issued by Apple for distribution
Signed with a trusted timestamp on: 2020-10-02 18:13:24 +0000
Certificate Chain:
1. Developer ID Installer: AMZN Mobile LLC (94KV3E626L)
Expires: 2024-10-18 22:31:30 +0000
SHA256 Fingerprint:
81 B4 6F AF 1C CA E1 E8 3C 6F FB 9E 52 5E 84 02 6E 7F 17 21 8E FB
0C 40 79 13 66 8D 9F 1F 10 1C
------------------------------------------------------------------------
2. Developer ID Certification Authority
Expires: 2027-02-01 22:12:15 +0000
SHA256 Fingerprint:
7A FC 9D 01 A6 2F 03 A2 DE 96 37 93 6D 4A FE 68 09 0D 2D E1 8D 03
F2 9C 88 CF B0 B1 BA 63 58 7F
------------------------------------------------------------------------
3. Apple Root CA
Expires: 2035-02-09 21:40:36 +0000
SHA256 Fingerprint:
B0 B1 73 0E CB C7 FF 45 05 14 2C 49 F1 29 5E 6E DA 6B CA ED 7E 2C
68 C5 BE 91 B5 A1 10 01 F0 24
```
+ または、.sig ファイルをダウンロードして使用する方法を使用するには、次の手順を実行します。
1. 次のコマンドを入力して、GPG アプリケーションを macOS ホストにインストールします。
```
brew install GnuPG
```
+ curl を使用して、パッケージ署名ファイルをダウンロードします。正しい署名ファイルを確認するには、「[CloudWatch エージェントダウンロードリンク](download-CloudWatch-Agent-on-EC2-Instance-commandline-first.md#agent-download-link-table)」を参照してください。
+ 署名を確認するには、**gpg --verify** を実行します。
```
PS> gpg --verify sig-filename agent-download-filename
gpg: Signature made 11/29/17 23:00:45 Coordinated Universal Time
gpg: using RSA key D58167303B789C72
gpg: Good signature from "Amazon CloudWatch Agent" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg: There is no indication that the signature belongs to the owner.
Primary key fingerprint: 9376 16F3 450B 7D80 6CBD 9725 D581 6730 3B78 9C72
```
出力結果に「`BAD signature`」という句が含まれる場合、手順が正しいことをもう一度確認してください。このレスポンスが続く場合は、Amazon Web Services に連絡し、ダウンロードしたファイルは使用しないでください。
信頼性に関する警告に注意します。キーは、自分や信頼する人が署名した場合にのみ信頼できます。つまり、署名が無効であるわけではなく、パブリックキーを確認していないことになります。
# CloudWatch エージェントのインストール
Amazon EC2 インスタンス、オンプレミスサーバー、およびコンテナ化された環境に CloudWatch エージェントをインストールして、メトリクス、ログ、トレースを収集できます。エージェントは、Linux、Windows、macOS オペレーティングシステムをサポートしています。エージェントをインストールするには、Systems Manager を使用する、CloudWatch コンソールからインストールする、コマンドラインからインストールする、設定ファイルを使用してインストールするなど、いくつかの方法があります。インストールする前に、必要な IAM アクセス許可およびネットワークアクセスが設定されていることを確認してください。
**Topics**
+ [
# CloudWatch コンソールでワークロード検出を使用して Amazon CloudWatch エージェントをインストールして設定する
](install-cloudwatch-agent-workload-detection.md)
+ [
# Amazon EC2 に手動でインストールする
](manual-installation.md)
+ [
# AWS Systems Manager を使用して CloudWatch エージェントをインストールする
](installing-cloudwatch-agent-ssm.md)
+ [
# オンプレミスサーバーに CloudWatch エージェントをインストールする
](install-CloudWatch-Agent-on-premise.md)
+ [
# CloudFormation を使用して新しいインスタンスに CloudWatch エージェントをインストールする
](Install-CloudWatch-Agent-New-Instances-CloudFormation.md)
+ [
# Amazon CloudWatch Observability EKS アドオンまたは Helm チャートを使用して CloudWatch エージェントをインストールする
](install-CloudWatch-Observability-EKS-addon.md)
# CloudWatch コンソールでワークロード検出を使用して Amazon CloudWatch エージェントをインストールして設定する
## 序章
CloudWatch 開始方法コンソールを使用して、CloudWatch エージェントを Amazon EC2 インスタンスにインストールおよび設定できます。Amazon CloudWatch エージェントは、Amazon EC2 インスタンスからシステムレベルのメトリクス、ログ、トレースを収集する軽量ソフトウェアコンポーネントです。エージェントは、モニタリングデータの収集と CloudWatch への配信を自動化することで、実用的なインサイトを取得し、リソース使用率を最適化し、最小限の設定作業でアプリケーションがスムーズに実行されるようにします。
自動ワークロード検出を活用してインスタンスで実行中のアプリケーションとサービスを特定する、事前定義されたワークロード固有の設定で CloudWatch エージェントを設定します。データ収集をカスタマイズして特定のメトリクス、ログ、トレースを対象にできるため、アプリケーションのパフォーマンスをモニタリングし、問題を効果的にトラブルシューティングできます。
## 仕組み
CloudWatch エージェントは、自動ワークロード検出機能を使用して Amazon EC2 インスタンスで実行されているワークロードを検出します。この機能は、インスタンスで実行中のアプリケーションとサービスを識別し、手動設定なしでインテリジェントなモニタリングを可能にします。
オブザーバビリティソリューションは、Apache Kafka、Apache Tomcat、Java 仮想マシン (JVM)、NGINX、NVIDIA GPU ワークロードなどの一般的なアプリケーションに合わせた事前定義されたワークロード固有の設定を提供します。これらのソリューションでは、検出された各ワークロードに固有の適切なメトリクス、ログ、トレースを自動的に収集することで、モニタリングの設定を効率化できるため、手動による計測と設定が不要になります。
ワークロード検出を有効にすると、エージェントはインスタンス環境を分析し、関連する事前設定されたモニタリングテンプレートを自動的に選択します。これらの設定は、AWS の対象分野のエキスパートによって最適化され、ワークロードタイプごとに最も重要なテレメトリデータをキャプチャするため、最初から包括的なオブザーバビリティを確保できます。
## 前提条件
### SSM エージェントのインストール (必須)
Amazon EC2 インスタンスに AWS Systems Manager (SSM) エージェントがインストールされている必要があります。SSM エージェントは、AWS が提供するほとんどの Amazon マシンイメージ (AMI) にプリインストールされています。SSM エージェントを手動でインストールまたは更新する必要がある場合は、[Systems Manager のドキュメント](https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-agent.html)を参照してください。
**注記**
デフォルトのホスト管理設定 (DHMC) は、各インスタンスに IAM インスタンスプロファイルを手動でアタッチすることなく、Systems Manager に接続するアクセス許可を Amazon EC2 インスタンスに自動的に付与する Systems Manager の機能です。Amazon EC2 インスタンスが DHMC を使用していて、CloudWatch エージェントのインストールプロセスで CloudWatch ポリシーがインスタンスにアタッチされる場合、新しいポリシーが有効になるまでに最大 30 分かかることがあります。この遅延により、メトリクス、ログ、トレースの CloudWatch への公開が延期される可能性があります。軽減策として、[AmazonSSMManagedInstanceCore](https://docs.aws.amazon.com/aws-managed-policy/latest/reference/AmazonSSMManagedInstanceCore.html) ポリシーを含む IAM ロールを使用して Amazon EC2 インスタンスを作成できます。
### ワークロード検出 (推奨)
ワークロード検出は、インスタンスで実行中のアプリケーションとサービスを自動的に識別するオプトイン機能です。事前設定されたワークロード固有のモニタリングテンプレートを利用するには、ワークロード検出を有効にすることをお勧めします。[CloudWatch コンソール設定](https://console.aws.amazon.com/cloudwatch/home#settings)でワークロード検出を有効にできます。
## 開始方法
Amazon CloudWatch コンソールの Amazon CloudWatch エージェントページ ([https://console.aws.amazon.com/cloudwatch/home\$1cloudwatch-agent](https://console.aws.amazon.com/cloudwatch/home#cloudwatch-agent)) で開始方法を開きます。
**CloudWatch エージェント用のインスタンスの手動デプロイ**
CloudWatch エージェントのインストールと設定用に最大 50 個のインスタンスを手動で選択します。このターゲットを絞ったアプローチにより、特定の Amazon EC2 インスタンスのモニタリングを強化できます。
**CloudWatch エージェントのタグベースのデプロイ**
タグベースのデプロイを使用して、Amazon EC2 インスタンスのフリートに CloudWatch エージェントをインストールして設定します。この方法は、一致するタグを持つ現在および将来のすべてのインスタンスに適用されます。
**タグベースの設定**
タグベースの設定を使用すると、設定を効率的に整理、表示、変更できるため、Amazon EC2 インスタンスのフリート間での CloudWatch エージェントとその設定の管理に役立ちます。
**CloudWatch エージェントのインストール**
CloudWatch エージェントをインストールし、Amazon EC2 インスタンスとオンプレミスホストからメトリクス、ログ、トレースを収集します。このテレメトリは、インフラストラクチャとアプリケーションに関する重要なヘルスデータとパフォーマンスデータを提供します。
**CloudWatch エージェントの設定**
事前定義されたワークロード固有の設定で CloudWatch エージェントを設定します。データ収集をカスタマイズして特定のメトリクス、ログ、トレースを対象にできるため、アプリケーションのパフォーマンスをモニタリングし、問題を効果的にトラブルシューティングできます。
## コスト
このプロセス中に追加したメトリクスはカスタムメトリクスとして課金されます。CloudWatch メトリクスの料金の詳細については「[Amazon CloudWatch の料金](https://aws.amazon.com/cloudwatch/pricing)」を参照してください。
# Amazon EC2 に手動でインストールする
**注記**
CloudWatch エージェントを初めてインストールする場合は、事前に前提条件が満たされていることを確認してください。
**Topics**
+ [
## パッケージマネージャーを使用して Amazon Linux にインストールする
](#amazon-linux-package)
+ [
## コマンドラインを使用して Amazon Linux にインストールする
](#linux-manual-install)
+ [
## Windows でのインストール
](#windows-installation)
+ [
## macOS でのインストール
](#macos-installation)
## パッケージマネージャーを使用して Amazon Linux にインストールする
CloudWatch エージェントは、Amazon Linux 2023 および Amazon Linux 2 でパッケージとして利用できます。これらのオペレーティング システムのいずれかを使用している場合は、以下のコマンドを入力してパッケージをインストールできます。
```
sudo yum install amazon-cloudwatch-agent
```
また、インスタンスにアタッチされた IAM ロールに **CloudWatchAgentServerPolicy** がアタッチされていることを確認する必要もあります。
## コマンドラインを使用して Amazon Linux にインストールする
サポートされているすべての Linux オペレーティングシステムで、コマンドラインを使用して、CloudWatch エージェントをダウンロードしてインストールできます。
1. CloudWatch エージェントをダウンロードします。Linux サーバーで、次のコマンドを入力します。`download-link` の場合、以下の表から適切なダウンロードリンクを使用します。
```
wget download-link
```
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/manual-installation.html)
1. パッケージをダウンロードしたら、オプションでパッケージの署名を確認できます。詳細については、「[CloudWatch エージェントパッケージの署名の検証](verify-CloudWatch-Agent-Package-Signature.md)」を参照してください。
1. パッケージをインストールします。Linux サーバーに RPM パッケージをダウンロードした場合は、パッケージがあるディレクトリに移動し、以下を入力します。
```
sudo rpm -U ./amazon-cloudwatch-agent.rpm
```
Linux サーバーに DEB パッケージをダウンロードした場合は、パッケージがあるディレクトリに移動し、以下を入力します。
```
sudo dpkg -i -E ./amazon-cloudwatch-agent.deb
```
## Windows でのインストール
Windows Server で、コマンドラインを使用して、CloudWatch エージェントをダウンロードしてインストールできます。
1. 次のファイルをダウンロードします。
```
https://amazoncloudwatch-agent.s3.amazonaws.com/windows/amd64/latest/amazon-cloudwatch-agent.msi
```
1. パッケージをダウンロードしたら、オプションでパッケージの署名を確認できます。詳細については、「[CloudWatch エージェントパッケージの署名の検証](verify-CloudWatch-Agent-Package-Signature.md)」を参照してください。
1. パッケージをインストールします。パッケージが含まれているディレクトリに移動し、次のように入力します。
```
msiexec /i amazon-cloudwatch-agent.msi
```
このコマンドは PowerShell 内からも使用できます。MSI コマンドオプションの詳細については、Microsoft Windows のドキュメントで「[Command-Line Options](https://docs.microsoft.com/en-us/windows/desktop/Msi/command-line-options)」を参照してください。
## macOS でのインストール
macOS コンピュータで、コマンドラインを使用して、CloudWatch エージェントをダウンロードしてインストールできます。
1. アーキテクチャに適切なパッケージをダウンロードします。
```
https://amazoncloudwatch-agent.s3.amazonaws.com/darwin/amd64/latest/amazon-cloudwatch-agent.pkg
```
ARM64 アーキテクチャの場合:
```
https://amazoncloudwatch-agent.s3.amazonaws.com/darwin/arm64/latest/amazon-cloudwatch-agent.pkg
```
1. パッケージをダウンロードしたら、オプションでパッケージの署名を確認できます。詳細については、「[CloudWatch エージェントパッケージの署名の検証](verify-CloudWatch-Agent-Package-Signature.md)」を参照してください。
1. パッケージをインストールします。パッケージが含まれているディレクトリに移動し、次のように入力します。
```
sudo installer -pkg ./amazon-cloudwatch-agent.pkg -target /
```
# AWS Systems Manager を使用して CloudWatch エージェントをインストールする
AWS Systems Manager を使用すると、Amazon EC2 インスタンスのフリートに CloudWatch エージェントを簡単にインストールできます。エージェントを 1 台のサーバーにダウンロードし、フリート内のすべてのサーバーに使用する CloudWatch エージェント設定ファイルを作成できます。その後、Systems Manager を使用し、作成した設定ファイルを使用して、エージェントを他のサーバーにインストールできます。以下のトピックに従い、AWS Systems Manager を使用して CloudWatch エージェントをインストールおよび実行します。
**Topics**
+ [
## SSM エージェントをインストールまたは更新する
](#update-SSM-Agent-EC2instance-first)
+ [
## Systems Manager の前提条件を確認する
](#install-CloudWatch-Agent-minimum-requirements-first)
+ [
## インターネットアクセスを確認する
](#install-CloudWatch-Agent-internet-access-first)
+ [
## CloudWatch エージェントパッケージを最初のインスタンスにダウンロードする
](#install-CloudWatch-Agent-EC2-first)
+ [
## エージェントの設定ファイルを作成して変更する
](#CW-Agent-Instance-Create-Configuration-File-first)
+ [
## エージェント設定を使用して追加の EC2 インスタンスに CloudWatch エージェントをインストールして起動する
](#install-CloudWatch-Agent-on-EC2-Instance-fleet)
+ [
## エージェント設定を使用して追加の EC2 インスタンスに CloudWatch エージェントをインストールする
](#install-CloudWatch-Agent-on-EC2-Instance-fleet)
+ [
## (オプション) CloudWatch エージェントの一般的な設定と名前付きプロファイルを変更する
](#CloudWatch-Agent-profile-instance-fleet)
## SSM エージェントをインストールまたは更新する
Amazon EC2 インスタンスでは、CloudWatch エージェントを使用するには、インスタンスで SSM エージェントのバージョン 2.2.93.0 以降が実行されている必要があります。CloudWatch エージェントをインストールする前に、SSM Agent を更新するか、インスタンスにインストールしてください (まだの場合)。
Linux を実行しているインスタンスでの SSM Agent のインストールまたは更新については、*AWS Systems Manager ユーザーガイド*の [Linux インスタンスでの SSM Agent のインストールおよび設定](https://docs.aws.amazon.com/systems-manager/latest/userguide/manually-install-ssm-agent-linux.html)を参照してください。
SSM Agent のインストールまたは更新の詳細については、*AWS Systems Manager ユーザーガイド*の [SSM Agent の使用](https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-agent.html)を参照してください。
## Systems Manager の前提条件を確認する
Systems Manager Run Command を使用して CloudWatch エージェントをインストールおよび設定する前に、インスタンスが Systems Manager の最低要件を満たしていることを確認してください。詳細については、*AWS Systems Manager ユーザーガイド*の [Systems Manager の前提条件](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-setting-up.html#systems-manager-prereqs)を参照してください。
## インターネットアクセスを確認する
Amazon EC2 インスタンスは CloudWatch エンドポイントに接続できる必要があります。これは、インターネットゲートウェイ、NAT ゲートウェイ、または CloudWatch Interface VPC エンドポイントによって実現できます。インターネットアクセスの詳しい設定方法については、*Amazon VPC ユーザーガイド*の「[インターネットゲートウェイ](https://docs.aws.amazon.com/vpc/latest/userguide/VPC_Internet_Gateway.html)」を参照してください。
プロキシで設定するエンドポイントとポートは、次のとおりです。
+ エージェントを使用してメトリクスを収集する場合は、適切なリージョンの CloudWatch エンドポイントのリストを許可する必要があります。これらのエンドポイントは、「Amazon Web Services 全般のリファレンス」の「[Amazon CloudWatch](https://docs.aws.amazon.com/general/latest/gr/rande.html#cw_region)」に記載されています。
+ エージェントを使用してログを収集する場合は、適切なリージョンの CloudWatch Logs エンドポイントのリストを許可する必要があります。これらのエンドポイントは、「Amazon Web Services 全般のリファレンス」の「[Amazon CloudWatch Logs](https://docs.aws.amazon.com/general/latest/gr/rande.html#cwl_region)」に記載されています。
+ Systems Manager を使用してエージェントをインストールする、または Parameter Store を使用して設定ファイルを保存する場合は、適切なリージョンの Systems Manager エンドポイントのリストを許可する必要があります。これらのエンドポイントは、「Amazon Web Services 全般のリファレンス」の「[AWS Systems Manager](https://docs.aws.amazon.com/general/latest/gr/rande.html#ssm_region)」に記載されています。
## CloudWatch エージェントパッケージを最初のインスタンスにダウンロードする
Systems Manager を使用して CloudWatch エージェントパッケージをダウンロードするには、次の手順に従います。
**Systems Manager を使用して CloudWatch エージェントをダウンロードするには**
1. Systems Manager コンソール ([https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)) を開きます。
1. ナビゲーションペインで、[**Run Command**] を選択します。
-または-
AWS Systems Manager のホームページが表示された場合は、スクロールダウンして [**Explore Run Command**] (Run Command の詳細) を選択します。
1. [**Run command (コマンドの実行)**] を選択します。
1. [**Command document**] リストで、[**AWS-ConfigureAWSPackage**] を選択します。
1. [**ターゲット**] 領域で、CloudWatch エージェントをインストールする先のインスタンスを選択します。特定のインスタンスが表示されない場合、そのインスタンスは Systems Manager で使用するマネージドインスタンスとして設定されていない可能性があります。詳細については、*AWS Systems Manager ユーザーガイド*から[ハイブリッド環境での AWS Systems Manager のセットアップ](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-managedinstances.html)を参照してください。
1. [**アクション**] リストで、[**インストール**] を選択します。
1. [**名前**] フィールドに、「*AmazonCloudWatchAgent*」と入力します。
1. エージェントの最新バージョンをインストールには、[**Version (バージョン)**] を [**latest (最新)**] に設定したままにします。
1. [**Run (実行)**] を選択します。
1. 必要に応じて、[**Targets and outputs**] 領域で、インスタンス名の横のボタンを選択して [**View output**] を選択します。Systems Manager に、エージェントが正常にインストールされたことが表示されます。
## エージェントの設定ファイルを作成して変更する
CloudWatch エージェントをダウンロードしたら、サーバーでエージェントを開始する前に設定ファイルを作成する必要があります。
エージェント設定ファイルを Systems Manager Parameter Store に保存する場合は、EC2 インスタンスを使用してParameter Store に保存する必要があります。さらに、最初にそのインスタンスに `CloudWatchAgentAdminRole` IAM ロールをアタッチする必要があります。ロールのアタッチの詳細については、「Amazon EC2 ユーザーガイド」の「[インスタンスへの IAM ロールのアタッチ](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/iam-roles-for-amazon-ec2.html#attach-iam-role)」を参照してください。
CloudWatch エージェント設定ファイルの作成の詳細については、「[CloudWatch エージェント設定ファイルを作成する](create-cloudwatch-agent-configuration-file.md)」を参照してください。
## エージェント設定を使用して追加の EC2 インスタンスに CloudWatch エージェントをインストールして起動する
CloudWatch エージェント設定を Parameter Store に保存すると、他のサーバーにエージェントをインストールするときに使用できます。
これらのサーバーごとに、このセクションで前述した手順に従って、Systems Manager の前提条件、SSM エージェントのバージョン、インターネットアクセスを確認します。次に、作成した CloudWatch エージェント設定ファイルを使用して、追加のインスタンスに CloudWatch エージェントを次の手順でインストールします。
**ステップ 1: CloudWatch エージェントをダウンロードしてインストールする**
CloudWatch データを別のリージョンに送信するには、このインスタンスにアタッチした IAM ロールに、そのリージョンで CloudWatch データを書き込むアクセス許可があることを確認してください。
次の例では、`aws configure` コマンドを使用して CloudWatch エージェントの名前付きプロファイルを作成します。この例では、`AmazonCloudWatchAgent` のデフォルトプロファイル名を使用しているものとします。
**CloudWatch エージェントの AmazonCloudWatchAgent プロファイルを作成するには**
+ Linux サーバーでは、以下のコマンドを入力し、プロンプトに従います。
```
sudo aws configure --profile AmazonCloudWatchAgent
```
Windows Server では、管理者として PowerShell を開き、以下のコマンドを入力して、プロンプトに従います。
```
aws configure --profile AmazonCloudWatchAgent
```
## エージェント設定を使用して追加の EC2 インスタンスに CloudWatch エージェントをインストールする
CloudWatch エージェント設定を Parameter Store に保存すると、他のサーバーにエージェントをインストールするときに使用できます。
これらのサーバーごとに、このセクションで前述した手順に従って、Systems Manager の前提条件、SSM エージェントのバージョン、インターネットアクセスを確認します。次に、作成した CloudWatch エージェント設定ファイルを使用して、追加のインスタンスに CloudWatch エージェントを次の手順でインストールします。
**ステップ 1: CloudWatch エージェントをダウンロードしてインストールする**
エージェントはその実行先となる各サーバーにインストールする必要があります。CloudWatch エージェントは、Amazon Linux 2023 および Amazon Linux 2 でパッケージとして利用できます。このオペレーティングシステムを使用している場合は、Systems Manager を使用して、パッケージを次の手順でインストールできます。
**注記**
また、インスタンスにアタッチされた IAM ロールに **CloudWatchAgentServerPolicy** がアタッチされていることを確認する必要もあります。詳細については、「[前提条件](prerequisites.md)」を参照してください。
**Systems Manager を使用して CloudWatch エージェントをインストールするには**
1. Systems Manager コンソール ([https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)) を開きます。
1. ナビゲーションペインで、[**Run Command**] を選択します。
-または-
AWS Systems Manager のホームページが表示された場合は、スクロールダウンして [**Explore Run Command**] (Run Command の詳細) を選択します。
1. [**Run command (コマンドの実行)**] を選択します。
1. **[コマンドドキュメント]** リストで、**[AWS-RunShellScript]** を選択します。次に、以下を **[コマンドパラメータ]** に貼り付けます。
```
sudo yum install amazon-cloudwatch-agent
```
1. **[実行]** を選択します。
サポートされているすべてのオペレーティングシステムで、Systems Manager Run Command または Amazon S3 ダウンロードリンクを使用して CloudWatch エージェントパッケージをダウンロードできます。
**注記**
CloudWatch エージェントをインストールまたは更新する場合、**アンインストールして再インストールする**オプションのみがサポートされています。**インプレースの更新**オプションを使用することはできません。
Systems Manager Run Command では、インスタンスの設定を管理できます。Systems Manager ドキュメントを指定してパラメータを指定し、1 つ以上のインスタンスでコマンドを実行します。インスタンスの SSM Agent は、コマンドを処理し、指定されたとおりにインスタンスを設定します。
**Run Command を使用して CloudWatch エージェントをダウンロードするには**
1. Systems Manager コンソール ([https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)) を開きます。
1. ナビゲーションペインで、[**Run Command**] を選択します。
-または-
AWS Systems Manager のホームページが表示された場合は、スクロールダウンして [**Explore Run Command**] (Run Command の詳細) を選択します。
1. [**Run command (コマンドの実行)**] を選択します。
1. [**Command document**] リストで、[**AWS-ConfigureAWSPackage**] を選択します。
1. [**Targets**] 領域で、CloudWatch エージェントをインストールするインスタンスを選択します。特定のインスタンスが表示されない場合、Run Command 用に設定されていない可能性があります。詳細については、*AWS Systems Manager ユーザーガイド*から[ハイブリッド環境での AWS Systems Manager のセットアップ](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-managedinstances.html)を参照してください。
1. [**アクション**] リストで、[**インストール**] を選択します。
1. [**名前**] ボックスに、「*AmazonCloudWatchAgent*」と入力します。
1. エージェントの最新バージョンをインストールには、[**Version (バージョン)**] を [**latest (最新)**] に設定したままにします。
1. [**Run (実行)**] を選択します。
1. 必要に応じて、[**Targets and outputs**] 領域で、インスタンス名の横のボタンを選択して [**View output**] を選択します。Systems Manager に、エージェントが正常にインストールされたことが表示されます。
**ステップ 2: エージェント設定ファイルを使用して CloudWatch エージェントを起動する**
Systems Manager Run Command を使用してエージェントを起動するには、次の手順に従います。
Security-Enhanced Linux (SELinux) が有効になっているシステムでエージェントを設定する方法については、「[Security-Enhanced Linux (SELinux) で CloudWatch エージェントをセットアップする](CloudWatch-Agent-SELinux.md)」を参照してください。
**コマンドの実行を使用して CloudWatch エージェントを起動するには**
1. Systems Manager コンソール ([https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)) を開きます。
1. ナビゲーションペインで、[**Run Command**] を選択します。
-または-
AWS Systems Manager のホームページが表示された場合は、スクロールダウンして [**Explore Run Command**] (Run Command の詳細) を選択します。
1. [**Run command (コマンドの実行)**] を選択します。
1. [**Command document**] リストで、[**AmazonCloudWatch-ManageAgent**] を選択します。
1. [**Targets**] 領域で、CloudWatch エージェントをインストールしたインスタンスを選択します。
1. [**Action**] リストで、[**configure**] を選択します。
1. [**Optional Configuration Source**] リストで、[**ssm**] を選択します。
1. **[オプションの設定の場所]** ボックスに、「[CloudWatch エージェント設定ファイルを作成する](create-cloudwatch-agent-configuration-file.md)」で説明されているように、作成して Systems Manager Parameter Store に保存したエージェント設定ファイルの Systems Manager パラメータ名を入力します。
1. これらのステップを完了した後、[**Optional Restart**] リストで、[**yes**] を選択してエージェントを開始します。
1. [**Run (実行)**] を選択します。
1. 必要に応じて、[**Targets and outputs**] 領域で、インスタンス名の横のボタンを選択して [**View output**] を選択します。Systems Manager に、エージェントが正常に開始されたことが表示されます。
## (オプション) CloudWatch エージェントの一般的な設定と名前付きプロファイルを変更する
CloudWatch エージェントには、`common-config.toml` と呼ばれる設定ファイルが含まれます。(オプション) このファイルを使用してプロキシおよびリージョン情報を指定できます。
Linux を実行しているサーバーでは、このファイルは `/opt/aws/amazon-cloudwatch-agent/etc` ディレクトリにあります。Windows Server を実行しているサーバーでは、このファイルは `C:\ProgramData\Amazon\AmazonCloudWatchAgent` ディレクトリにあります。
デフォルトの `common-config.toml` は次のようになります。
```
# This common-config is used to configure items used for both ssm and cloudwatch access
## Configuration for shared credential.
## Default credential strategy will be used if it is absent here:
## Instance role is used for EC2 case by default.
## AmazonCloudWatchAgent profile is used for onPremise case by default.
# [credentials]
# shared_credential_profile = "{profile_name}"
# shared_credential_file= "{file_name}"
## Configuration for proxy.
## System-wide environment-variable will be read if it is absent here.
## i.e. HTTP_PROXY/http_proxy; HTTPS_PROXY/https_proxy; NO_PROXY/no_proxy
## Note: system-wide environment-variable is not accessible when using ssm run-command.
## Absent in both here and environment-variable means no proxy will be used.
# [proxy]
# http_proxy = "{http_url}"
# https_proxy = "{https_url}"
# no_proxy = "{domain}"
```
初期状態では、すべての行がコメントアウトされています。認証情報プロファイルやプロキシ設定を設定するには、その行から `#` を削除し、値を指定します。このファイルを手動で編集するか、Systems Manager の `RunShellScript` Run Command を使用できます。
+ `shared_credential_profile` – オンプレミスサーバーの場合、このコード行では、データを CloudWatch に送信するために使用する IAM ユーザー認証情報を指定します。このコード行をコメントアウトした場合、`AmazonCloudWatchAgent` が使用されます。
EC2 インスタンスでは、このコード行を使用して、CloudWatch エージェントでこのインスタンスのデータを別の AWS リージョンの CloudWatch に送信します。そのためには、送信先のリージョンの名前を指定する `region` フィールドを含む名前付きプロファイルを指定します。
`shared_credential_profile` を指定する場合は、`[credentials]` 行の先頭から `#` を削除する必要もあります。
+ `shared_credential_file` – エージェントでデフォルトのパス以外のパスにあるファイルの認証情報を検索するには、ここで完全なパスとファイル名を指定します。デフォルトのパスは、`/root/.aws` (Linux) および `C:\\Users\\Administrator\\.aws` (Windows Server) です。
以下の最初の例は、Linux サーバーで有効な `shared_credential_file` 行の構文です。2 番目の例は、Windows Server で有効です。Windows Server では、\$1 文字をエスケープする必要があります。
```
shared_credential_file= "/usr/username/credentials"
```
```
shared_credential_file= "C:\\Documents and Settings\\username\\.aws\\credentials"
```
`shared_credential_file` を指定する場合は、`[credentials]` 行の先頭から `#` を削除する必要もあります。
+ プロキシ設定 – サーバーで HTTP プロキシまたは HTTPS プロキシを使用して AWS サービスに接続する場合は、これらのプロキシを `http_proxy` フィールドと `https_proxy` フィールドに指定します。プロキシから除外すべき URL がある場合、カンマで区切って `no_proxy` フィールドで指定します。
# オンプレミスサーバーに CloudWatch エージェントをインストールする
CloudWatch エージェントをコンピュータにダウンロードし、エージェント設定ファイルを作成した場合は、その設定ファイルを使用して他のオンプレミスサーバーにエージェントをインストールできます。
## オンプレミスサーバーに CloudWatch エージェントをダウンロードする
Systems Manager Run Command または Amazon S3 ダウンロードリンクを使用して CloudWatch エージェントパッケージをダウンロードできます。
### Systems Manager を使用してダウンロードする
Systems Manager Run Command を使用するには、オンプレミスサーバーを Amazon EC2 Systems Manager に登録する必要があります。詳細については、*AWS Systems Manager ユーザーガイド*の[ハイブリッド環境での Systems Manager のセットアップ](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-managedinstances.html)を参照してください。
既にサーバーを登録している場合、SSM Agent を最新バージョンに更新します。
Linux を実行しているサーバーでの SSM Agent の更新の詳細については、*AWS Systems Manager ユーザーガイド*の[ハイブリッド環境で SSM Agent をインストールする (Linux)](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-managedinstances.html#sysman-install-managed-linux) を参照してください。
Windows Server を実行しているサーバーで SSM Agent を更新する方法の詳細については、*AWS Systems Manager ユーザーガイド*の[ハイブリッド環境で SSM Agent をインストールする (Windows)](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-managedinstances.html#sysman-install-managed-win) を参照してください。
**SSM Agent を使用してオンプレミスサーバーで CloudWatch エージェントパッケージをダウンロードするには**
1. Systems Manager コンソール ([https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)) を開きます。
1. ナビゲーションペインで、[**Run Command**] を選択します。
-または-
AWS Systems Manager のホームページが表示された場合は、スクロールダウンして [**Explore Run Command**] (Run Command の詳細) を選択します。
1. [**Run command (コマンドの実行)**] を選択します。
1. [**Command document**] リストで、[**AWS-ConfigureAWSPackage**] の横のボタンを選択します。
1. [**ターゲット**] 領域で、CloudWatch エージェントをインストールするサーバーを選択します。特定のサーバーが表示されない場合、Run Command 用に設定されていない可能性があります。詳細については、*AWS Systems Manager ユーザーガイド*から[ハイブリッド環境での AWS Systems Manager のセットアップ](https://docs.aws.amazon.com/systems-manager/latest/userguide/systems-manager-managedinstances.html)を参照してください。
1. [**アクション**] リストで、[**インストール**] を選択します。
1. [**名前**] ボックスに、「*AmazonCloudWatchAgent*」と入力します。
1. エージェントの最新バージョンをインストールには、[**Version**] を空白のままにします。
1. [**Run (実行)**] を選択します。
エージェントパッケージがダウンロードされたら、次のステップではエージェントパッケージを設定して開始します。
## (オンプレミスサーバーへのインストール) IAM 認証情報と AWS リージョンを指定する
CloudWatch エージェントで、オンプレミスサーバーのデータを送信できるようにするには、先ほど作成した IAM ユーザーのアクセスキーおよびシークレットキーを指定する必要があります。
また、メトリクスを送信する AWS リージョンを指定する必要があります。これには、`region` フィールドを使用します。
このファイルの例を以下に示します。
```
[AmazonCloudWatchAgent]
aws_access_key_id=my_access_key
aws_secret_access_key=my_secret_key
region = us-west-1
```
*my\$1access\$1key* および *my\$1secret\$1key* で、Systems Manager Parameter Store に書き込むアクセス許可がない IAM ユーザーのキーを使用します。
このプロファイルの名前を `AmazonCloudWatchAgent` とする場合は、これ以上何もする必要はありません。必要に応じて、別の名前をつけ、`shared_credential_profile` ファイルの ` common-config.toml` の値としてその名前を指定することができます。詳細は次のセクションを参照してください。
次の例では、**aws configure** コマンドを使用して CloudWatch エージェントの名前付きプロファイルを作成します。この例では、`AmazonCloudWatchAgent` のデフォルトプロファイル名を使用しているものとします。
**CloudWatch エージェントの AmazonCloudWatchAgent プロファイルを作成するには**
1. まだの場合は、AWS Command Line Interface をサーバーにインストールしてください。詳細については、「[AWS CLI のインストール](https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-install.html)」を参照してください。
1. Linux サーバーでは、以下のコマンドを入力し、プロンプトに従います。
```
sudo aws configure --profile AmazonCloudWatchAgent
```
Windows Server では、管理者として PowerShell を開き、以下のコマンドを入力して、プロンプトに従います。
```
aws configure --profile AmazonCloudWatchAgent
```
## (オプション) CloudWatch エージェントの一般的な設定と名前付きプロファイルの変更
CloudWatch エージェントには、`common-config.toml` と呼ばれる設定ファイルが含まれます。必要に応じてこのファイルを使用して、プロキシおよびリージョン情報を指定できます。
Linux を実行しているサーバーでは、このファイルは `/opt/aws/amazon-cloudwatch-agent/etc` ディレクトリにあります。Windows Server を実行しているサーバーでは、このファイルは `C:\ProgramData\Amazon\AmazonCloudWatchAgent` ディレクトリにあります。
デフォルトの `common-config.toml` は次のようになります。
```
# This common-config is used to configure items used for both ssm and cloudwatch access
## Configuration for shared credential.
## Default credential strategy will be used if it is absent here:
## Instance role is used for EC2 case by default.
## AmazonCloudWatchAgent profile is used for onPremise case by default.
# [credentials]
# shared_credential_profile = "{profile_name}"
# shared_credential_file= "{file_name}"
## Configuration for proxy.
## System-wide environment-variable will be read if it is absent here.
## i.e. HTTP_PROXY/http_proxy; HTTPS_PROXY/https_proxy; NO_PROXY/no_proxy
## Note: system-wide environment-variable is not accessible when using ssm run-command.
## Absent in both here and environment-variable means no proxy will be used.
# [proxy]
# http_proxy = "{http_url}"
# https_proxy = "{https_url}"
# no_proxy = "{domain}"
```
初期状態では、すべての行がコメントアウトされています。認証情報プロファイルやプロキシ設定を設定するには、その行から `#` を削除し、値を指定します。このファイルを手動で編集するか、Systems Manager の `RunShellScript` Run Command を使用できます。
+ `shared_credential_profile` – オンプレミスサーバーの場合、このコード行では、データを CloudWatch に送信するために使用する IAM ユーザー認証情報を指定します。このコード行をコメントアウトした場合、`AmazonCloudWatchAgent` が使用されます。このプロファイルの作成の詳細については、「[(オンプレミスサーバーへのインストール) IAM 認証情報と AWS リージョンを指定する](#install-CloudWatch-Agent-iam_user-SSM-onprem)」を参照してください。
EC2 インスタンスでは、このコード行を使用して、CloudWatch エージェントでこのインスタンスのデータを別の AWS リージョンの CloudWatch に送信します。そのためには、送信先のリージョンの名前を指定する `region` フィールドを含む名前付きプロファイルを指定します。
`shared_credential_profile` を指定する場合は、`[credentials]` 行の先頭から `#` を削除する必要もあります。
+ `shared_credential_file` – エージェントでデフォルトのパス以外のパスにあるファイルの認証情報を検索するには、ここで完全なパスとファイル名を指定します。デフォルトのパスは、`/root/.aws` (Linux) および `C:\\Users\\Administrator\\.aws` (Windows Server) です。
以下の最初の例は、Linux サーバーで有効な `shared_credential_file` 行の構文です。2 番目の例は、Windows Server で有効です。Windows Server では、\$1 文字をエスケープする必要があります。
```
shared_credential_file= "/usr/username/credentials"
```
```
shared_credential_file= "C:\\Documents and Settings\\username\\.aws\\credentials"
```
`shared_credential_file` を指定する場合は、`[credentials]` 行の先頭から `#` を削除する必要もあります。
+ プロキシ設定 – サーバーで HTTP プロキシまたは HTTPS プロキシを使用して AWS サービスに接続する場合は、これらのプロキシを `http_proxy` フィールドと `https_proxy` フィールドに指定します。プロキシから除外すべき URL がある場合、カンマで区切って `no_proxy` フィールドで指定します。
# CloudFormation を使用して新しいインスタンスに CloudWatch エージェントをインストールする
このセクションでは、AWS CloudFormation を使用して、新しい Amazon EC2 インスタンスに CloudWatch エージェントをインストールする方法について説明します。
**注記**
Amazon は、新しい Amazon EC2 インスタンスへの CloudWatch エージェントのインストールおよび更新に役立つ複数の CloudFormation テンプレートを GitHub にアップロードしています。CloudFormation の使用の詳細については、「[AWS CloudFormation とは](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html)」を参照してください。
テンプレートの場所は、[CloudFormation を使用して Amazon CloudWatch エージェントを EC2 インスタンスにデプロイする](https://github.com/aws-cloudformation/aws-cloudformation-templates/tree/main/Solutions/AmazonCloudWatchAgent)です。この場所には、`inline` ディレクトリと `ssm` ディレクトリの両方が含まれます。各ディレクトリに Linux インスタンスと Windows インスタンスの両方のテンプレートが含まれています。
+ `inline` ディレクトリのテンプレートの場合は、CloudWatch エージェント設定が CloudFormation テンプレートに埋め込まれています。デフォルトでは、Linux テンプレートが `mem_used_percent` メトリクスと `swap_used_percent` メトリクスを収集し、Windows テンプレートが `Memory % Committed Bytes In Use` メトリクスと `Paging File % Usage` メトリクスを収集します。
さまざまなメトリクスが収集されるようにこれらのテンプレートを変更するには、テンプレートの次のセクションを変更します。Linux サーバーのテンプレートの例を次に示します。これらの変更を行うには、エージェント設定ファイルの形式と構文に従ってください。詳細については、「[CloudWatch エージェント設定ファイルを手動で作成または編集する](CloudWatch-Agent-Configuration-File-Details.md)」を参照してください。
```
{
"metrics":{
"append_dimensions":{
"AutoScalingGroupName":"${!aws:AutoScalingGroupName}",
"ImageId":"${!aws:ImageId}",
"InstanceId":"${!aws:InstanceId}",
"InstanceType":"${!aws:InstanceType}"
},
"metrics_collected":{
"mem":{
"measurement":[
"mem_used_percent"
]
},
"swap":{
"measurement":[
"swap_used_percent"
]
}
}
}
}
```
**注記**
inline テンプレートの場合、すべてのプレースホルダ変数の先頭にエスケープ文字として感嘆符 (\$1) が必要です。これは、サンプルテンプレートで確認できます。他のプレースホルダ変数を追加する場合は、変数名の前に感嘆符を追加します。
+ `ssm` ディレクトリのテンプレートでは、エージェント設定ファイルを Parameter Store からロードします。これらのテンプレートを使用するには、最初に設定ファイルを作成して Parameter Store にアップロードする必要があります。次に、このファイルの Parameter Store 名をテンプレート内で指定します。設定ファイルは手動で作成するか、ウィザードで作成できます。詳細については、「[CloudWatch エージェント設定ファイルを作成する](create-cloudwatch-agent-configuration-file.md)」を参照してください。
CloudWatch エージェントのインストールとエージェント設定の更新には、両方のタイプのテンプレートを使用できます。
Security-Enhanced Linux (SELinux) が有効になっているシステムでエージェントを設定する方法については、「[Security-Enhanced Linux (SELinux) で CloudWatch エージェントをセットアップする](CloudWatch-Agent-SELinux.md)」を参照してください。
## チュートリアル: CloudFormation inline テンプレートを使用して CloudWatch エージェントをインストールおよび設定する
このチュートリアルでは、CloudFormation を使用して新しい Amazon EC2 インスタンスに CloudWatch エージェントをインストールする手順について説明します。このチュートリアルでは、inline テンプレートを使用して Amazon Linux 2 を実行する新しいインスタンスにインストールします。この場合、JSON 設定ファイルや Parameter Store を使用する必要はありません。inline テンプレートの場合、テンプレートにエージェント設定が含まれています。このチュートリアルでは、テンプレートに含まれているデフォルトのエージェント設定を使用します。
エージェントのインストール手順を示した後で、エージェントの更新方法を示します。
**CloudFormation を使用して新しいインスタンスに CloudWatch エージェントをインストールするには**
1. GitHub からテンプレートをダウンロードします。このチュートリアルでは、次のように Amazon Linux 2 の inline テンプレートをダウンロードします。
```
curl -O https://raw.githubusercontent.com/aws-cloudformation/aws-cloudformation-templates/main/Solutions/AmazonCloudWatchAgent/inline/amazon_linux.yaml
```
1. [https://console.aws.amazon.com/cloudformation](https://console.aws.amazon.com/cloudformation/) で CloudFormation コンソール を開きます。
1. [**Create stack**] を選択します。
1. [**テンプレートの選択**] で、[**テンプレートを Amazon S3 にアップロード**] を選択し、ダウンロード済みのテンプレートを選択して [**次へ**] を選択します。
1. [**詳細の指定**] ページで、以下のパラメータを指定し、[**次へ**] を選択します。
+ **Stack name**: CloudFormation スタックのスタック名を選択します。
+ **IAMRole**: CloudWatch メトリクス、ログ、トレースを書き込むアクセス許可を持つ IAM ロールを選択します。詳細については、「[前提条件](prerequisites.md)」を参照してください。
+ **InstanceAMI**: スタックを起動するリージョンで有効な AMI を選択します。
+ **InstanceType**: 有効なインスタンスタイプを選択します。
+ **KeyName**: 新しいインスタンスへの SSH アクセスを有効にするには、既存の Amazon EC2 キーペアを選択します。Amazon EC2 キーペアをまだ持っていない場合は、AWS マネジメントコンソール で作成できます。詳細については、「Amazon EC2 ユーザーガイド」の「[Amazon EC2 キーペア](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html)」を参照してください。
+ **SSHLocation**: SSH を使用してインスタンスに接続するために使用できる IP アドレス範囲を指定します。デフォルトでは、任意の IP アドレスからのアクセスを許可します。
1. [**オプション**] ページで、スタックリソースをタグ付けできます。[**次へ**] を選択します。
1. [**レビュー**] ページで、情報を確認して、スタックで IAM リソースが作成されることを認識し、[**作成**] を選択します。
コンソールを更新すると、新しいスタックが `CREATE_IN_PROGRESS` スタータスで表示されます。
1. インスタンスが作成されると、Amazon EC2 コンソールに表示されます。必要に応じてホストに接続し、進行状況をチェックできます。
エージェントがインストールされたことを確認するには、次のコマンドを使用します。
```
rpm -qa amazon-cloudwatch-agent
```
エージェントが実行中であることを確認するには、次のコマンドを使用します。
```
ps aux | grep amazon-cloudwatch-agent
```
次の手順では、inline テンプレートを使用して CloudFormation で CloudWatch エージェントを更新する方法を示します。デフォルトの inline テンプレートでは `mem_used_percent` メトリクスを収集します。このチュートリアルでは、このメトリクスの収集を停止するようにエージェント設定を変更します。
**CloudFormation を使用して CloudWatch エージェントを更新するには**
1. 前の手順でダウンロードしたテンプレートで、以下の行を削除し、テンプレートを保存します。
```
"mem": {
"measurement": [
"mem_used_percent"
]
},
```
1. [https://console.aws.amazon.com/cloudformation](https://console.aws.amazon.com/cloudformation/) で CloudFormation コンソール を開きます。
1. CloudFormation ダッシュボードで、作成したスタックを選択後、[**スタックの更新**] を選択します。
1. [**テンプレートの選択**] で、[**テンプレートを Amazon S3 にアップロード**] を選択し、変更したテンプレートを選択して [**次へ**] を選択します。
1. [**オプション**] ページで、[**次へ**]、[**次へ**] の順に選択します。
1. [**確認**] ページで情報を確認し、[**更新**] を選択します。
しばらくすると、`UPDATE_COMPLETE` と表示されます。
## チュートリアル: CloudFormation と Parameter Store を使用して CloudWatch エージェントをインストールする
このチュートリアルでは、CloudFormation を使用して新しい Amazon EC2 インスタンスに CloudWatch エージェントをインストールする手順について説明します。このチュートリアルでは、Parameter Store で作成して保存したエージェント設定ファイルを使用して、Amazon Linux 2 を実行する新しいインスタンスにインストールします。
エージェントのインストール手順を示した後で、エージェントの更新方法を示します。
**CloudFormation を使用して、Parameter Store の設定により CloudWatch エージェントを新しいインスタンスにインストールするには**
1. まだ行っていない場合は、CloudWatch エージェントパッケージをコンピュータにダウンロードし、エージェント設定ファイルを作成できるようにします。Parameter Store を使用したエージェントの詳細とダウンロードについては、「[CloudWatch エージェントパッケージをダウンロードする](download-CloudWatch-Agent-on-EC2-Instance-commandline-first.md)」を参照してください。
1. Parameter Store でエージェント設定ファイルを作成して保存します。詳細については、「[CloudWatch エージェント設定ファイルを作成する](create-cloudwatch-agent-configuration-file.md)」を参照してください。
1. 次のように、GitHub からテンプレートをダウンロードします。
```
curl -O https://raw.githubusercontent.com/awslabs/aws-cloudformation-templates/master/aws/solutions/AmazonCloudWatchAgent/ssm/amazon_linux.template
```
1. [https://console.aws.amazon.com/cloudformation](https://console.aws.amazon.com/cloudformation/) で CloudFormation コンソール を開きます。
1. [**Create stack**] を選択します。
1. [**テンプレートの選択**] で、[**テンプレートを Amazon S3 にアップロード**] を選択し、ダウンロードしたテンプレートを選択して [**次へ**] を選択します。
1. [**詳細の指定**] ページで、必要に応じて以下のパラメータを指定し、[**次へ**] を選択します。
+ **Stack name**: CloudFormation スタックのスタック名を選択します。
+ **IAMRole**: CloudWatch メトリクス、ログ、トレースを書き込むアクセス許可を持つ IAM ロールを選択します。詳細については、「[前提条件](prerequisites.md)」を参照してください。
+ **InstanceAMI**: スタックを起動するリージョンで有効な AMI を選択します。
+ **InstanceType**: 有効なインスタンスタイプを選択します。
+ **KeyName**: 新しいインスタンスへの SSH アクセスを有効にするには、既存の Amazon EC2 キーペアを選択します。Amazon EC2 キーペアをまだ持っていない場合は、AWS マネジメントコンソール で作成できます。詳細については、「Amazon EC2 ユーザーガイド」の「[Amazon EC2 キーペア](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html)」を参照してください。
+ **SSHLocation**: SSH を使用してインスタンスに接続するために使用できる IP アドレス範囲を指定します。デフォルトでは、任意の IP アドレスからのアクセスを許可します。
+ **SSMKey**: Parameter Store で作成して保存したエージェント設定ファイルを指定します。
1. [**オプション**] ページで、スタックリソースをタグ付けできます。[**次へ**] を選択します。
1. [**レビュー**] ページで、情報を確認して、スタックで IAM リソースが作成されることを認識し、[**作成**] を選択します。
コンソールを更新すると、新しいスタックが `CREATE_IN_PROGRESS` スタータスで表示されます。
1. インスタンスが作成されると、Amazon EC2 コンソールに表示されます。必要に応じてホストに接続し、進行状況をチェックできます。
エージェントがインストールされたことを確認するには、次のコマンドを使用します。
```
rpm -qa amazon-cloudwatch-agent
```
エージェントが実行中であることを確認するには、次のコマンドを使用します。
```
ps aux | grep amazon-cloudwatch-agent
```
次の手順では、Parameter Store に保存したエージェント設定を使用して、CloudFormation により CloudWatch エージェントを更新する方法を示します。
**CloudFormation を使用して、Parameter Store の設定により CloudWatch エージェントを更新するには**
1. 必要に応じて、Parameter Store に保存したエージェント設定ファイルを新しい設定に変更します。
1. CloudFormation トピックでダウンロードした [チュートリアル: CloudFormation と Parameter Store を使用して CloudWatch エージェントをインストールする](#installing-CloudWatch-Agent-using-CloudFormation-Templates) テンプレートで、バージョン番号を変更します。たとえば、`VERSION=1.0` を `VERSION=2.0` に変更できます。
1. [https://console.aws.amazon.com/cloudformation](https://console.aws.amazon.com/cloudformation/) で CloudFormation コンソール を開きます。
1. CloudFormation ダッシュボードで、作成したスタックを選択後、[**スタックの更新**] を選択します。
1. [**テンプレートの選択**] で、[**テンプレートを Amazon S3 にアップロード**] を選択し、変更したテンプレートを選択して [**次へ**] を選択します。
1. [**オプション**] ページで、[**次へ**]、[**次へ**] の順に選択します。
1. [**確認**] ページで情報を確認し、[**更新**] を選択します。
しばらくすると、`UPDATE_COMPLETE` と表示されます。
## CloudFormation での CloudWatch エージェントのインストールのトラブルシューティング
このセクションは、 CloudFormationによる CloudWatch エージェントのインストールおよび更新に関する問題のトラブルシューティングに役立ちます。
### 更新が失敗した場合の検出
CloudFormation を使用して CloudWatch エージェントの設定を更新し、無効な設定を使用すると、エージェントは CloudWatch へのあらゆるメトリクスの送信を停止します。エージェント設定が正常に更新されたかどうかは、`cfn-init-cmd.log` ファイルで簡単に確認できます。Linux サーバーの場合、このファイルは `/var/log/cfn-init-cmd.log` にあります。Windows インスタンスの場合、このファイルは `C:\cfn\log\cfn-init-cmd.log` にあります。
### メトリクスが見つからない
エージェントのインストールまたは更新後に必要なメトリクスが表示されない場合は、そのメトリクスを収集するようにエージェントが設定されていることを確認します。そのためには、`amazon-cloudwatch-agent.json` ファイルにメトリクスが表示されていることと、正しいメトリクスの名前空間を参照していることを確認します。詳細については、「[CloudWatch エージェントファイルとロケーション](troubleshooting-CloudWatch-Agent.md#CloudWatch-Agent-files-and-locations)」を参照してください。
# Amazon CloudWatch Observability EKS アドオンまたは Helm チャートを使用して CloudWatch エージェントをインストールする
Amazon CloudWatch Observability EKS アドオンまたは Amazon CloudWatch Observability Helm チャートを使用して、Amazon EKS クラスターに CloudWatch エージェントと Fluent Bit エージェントをインストールできます。また、Helm チャートを使用して、Amazon EKS でホストされていない Kubernetes クラスターに CloudWatch エージェントと Fluent Bit エージェントをインストールすることもできます。
Amazon EKS クラスターでこのいずれかの方法を使用すると、デフォルトで Amazon EKS と [CloudWatch Application Signals](CloudWatch-Application-Monitoring-Sections.md) の両方の [Container Insights](ContainerInsights.md) がオブザーバビリティが強化されたうえで有効になります。どちらの機能を使用しても、クラスターからインフラストラクチャメトリクス、アプリケーションパフォーマンステレメトリ、コンテナログを容易に収集できます。
アドオンのバージョン `v6.0.1-eksbuild.1` 以降では、OpenTelemetry メトリクスを使用した Container Insights が有効になっています。これにより、OpenTelemetry Protocol (OTLP) を使用してメトリクスを収集し、PromQL クエリをサポートします。詳細については、「[Amazon EKS の OpenTelemetry メトリクスを使用した Container Insights](container-insights-otel-metrics.md)」を参照してください。
Amazon EKS 向けにオブザーバビリティが強化された Container Insights では、観察結果毎に Container Insights メトリクスに課金されます。保存されたメトリクスまたは取り込まれたログ単位では課金されません。Application Signals の場合、アプリケーションへのインバウンドリクエスト、アプリケーションからのアウトバウンドリクエスト、設定された各サービスレベル目標 (SLO) に基づいて、請求が行われます。インバウンドリクエストを受信するたびにアプリケーションシグナルが 1 つ生成され、アウトバウンドリクエストが発生するたびにアプリケーションシグナルが 1 つ生成されます。各 SLO は、測定間隔ごとにアプリケーションシグナルを 2 つ作成します。CloudWatch の料金の詳細については、「[Amazon CloudWatch の料金](https://aws.amazon.com/cloudwatch/pricing/)」をご覧ください。
どちらの方法を使用しても、Amazon EKS クラスターの Linux と Windows の両方のワーカーノードで Container Insights を有効にできます。Windows で Container Insights を有効にするには、Amazon EKS アドオンのバージョン 1.5.0 以降を使用するか、Helm チャートを使用する必要があります。Amazon EKS クラスターの Windows では、Application Signals はサポートされていません。
Amazon CloudWatch Observability EKS アドオンは、Kubernetes バージョン 1.23 以降で Amazon EKS クラスターを実行している場合にサポートされます。
また、このアドオンまたは Helm チャートをインストールするときは、IAM アクセス許可を付与して、CloudWatch エージェントが CloudWatch にメトリクス、ログ、トレースを送信できるようにする必要があります。次の 2 通りの方法があります。
+ ワーカーノードの IAM ロールにポリシーをアタッチします。このオプションは、テレメトリを CloudWatch に送信するアクセス許可をワーカーノードに付与します。
+ エージェントポッドでサービスアカウントの IAM ロールを使用し、このロールにポリシーをアタッチします。これは Amazon EKS クラスターでのみ機能します。このオプションでは、CloudWatch は適切なエージェントポッドにのみアクセスできます。
**Topics**
+ [
## オプション 1: EKS Pod Identity を使用してインストールする
](#install-CloudWatch-Observability-EKS-pod-identity)
+ [
## オプション 2: ワーカーノードで IAM のアクセス許可を使用してインストールする
](#install-CloudWatch-Observability-EKS-addon-workernodes)
+ [
## オプション 3: IAM サービスアカウントロールを使用してインストールする (アドオンを使用する場合のみ)
](#install-CloudWatch-Observability-EKS-addon-serviceaccountrole)
+ [
## Amazon EKS Hybrid Nodes の考慮事項
](#install-CloudWatch-Observability-EKS-addon-hybrid)
+ [
## (オプション) その他の設定
](#install-CloudWatch-Observability-EKS-addon-configuration)
+ [
## Java Management Extensions (JMX) メトリクスの収集
](#install-CloudWatch-Observability-EKS-addon-JMX-metrics)
+ [
## Kueue メトリクスの有効化
](#enable-Kueue-metrics)
+ [
## OpenTelemetry コレクター設定ファイルの追加
](#install-CloudWatch-Observability-EKS-addon-OpenTelemetry)
+ [
## Amazon EKS クラスターの Application Signals による APM の有効化
](#Container-Insights-setup-EKS-appsignalsconfiguration)
+ [
## Amazon CloudWatch Observability EKS アドオンや Helm チャートのトラブルシューティング
](#Container-Insights-setup-EKS-addon-troubleshoot)
+ [
## Application Signals のオプトアウト
](#Opting-out-App-Signals)
## オプション 1: EKS Pod Identity を使用してインストールする
バージョン 3.1.0 以降のアドオンを使用している場合は、EKS Pod Identity を使用して、必要なアクセス許可をアドオンに付与できます。EKS Pod Identity は、推奨オプションであり、最小特権、認証情報のローテーション、監査可能性などなどの利点を提供します。さらに、EKS Pod Identity を使用すると、クラスター作成自体の一部として EKS アドオンをインストールできます。
この方法を使用するには、まず [EKS Pod Identity の関連付け](https://docs.aws.amazon.com/eks/latest/userguide/pod-id-association.html#pod-id-association-create/)の手順に従って IAM ロールを作成し、EKS Pod Identity エージェントを設定します。
Amazon CloudWatch Observability EKS アドオンをインストールします。アドオンをインストールするには、AWS CLI、Amazon EKS コンソール、CloudFormation または Terraform を使用できます。
------
#### [ AWS CLI ]
**AWS CLI を使用して Amazon CloudWatch Observability EKS アドオンをインストールするには**
次のコマンドを入力します。`my-cluster-name` をクラスター名に置き換え、*111122223333* をアカウント ID に置き換えます。*my-role* を EKS Pod Identity の関連付けステップで作成した IAM ロールに置き換えます。
```
aws iam attach-role-policy \
--role-name my-role \
--policy-arn arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy
aws eks create-addon \
--addon-name amazon-cloudwatch-observability \
--cluster-name my-cluster-name \
--pod-identity-associations serviceAccount=cloudwatch-agent,roleArn=arn:aws:iam::111122223333:role/my-role
```
------
#### [ Amazon EKS console ]
**Amazon EKS コンソールを使用して Amazon CloudWatch Observability EKS アドオンを追加するには**
1. A[https://console.aws.amazon.com/eks/home\$1/clusters](https://console.aws.amazon.com/eks/home#/clusters) で Amazon EKS コンソールを開きます。
1. 左のナビゲーションペインで **[クラスター]** を選択してください。
1. Amazon CloudWatch Observability EKS アドオンを設定するクラスターの名前を選択します。
1. **[アドオン]** タブを選択してください。
1. **[その他のアドオンを入手]** を選択してください。
1. **[アドオンを選択]** ページで、次の操作を行います。
1. **[Amazon EKS アドオン]** セクションで、**[Amazon CloudWatch Observability]** チェックボックスを選択します。
1. [**次へ**] を選択します。
1. **[選択したアドオンセッティングの設定]** ページで、次の操作を行います。
1. 使用する **[バージョン]** を選択します。
1. **[アドオンアクセス]** では、**[EKS Pod Identity]** を選択します。
1. IAM ロールが設定されていない場合は、**[推奨ロールを作成]** を選択し、**ステップ 3 の [名前、確認、および作成]** になるまで **[次へ]** を選択します。必要に応じてロール名を変更することができます。それ以外の場合は、**[ロールの作成]** を選択し、アドオンページに戻り、作成した IAM ロールを選択します。
1. (オプション) **[オプションの構成設定]** を展開できます。**[コンフリクト解決方法]** で **[上書きする]** を選択すると、既存のアドオンでの 1 つ以上の設定が、Amazon EKS アドオンの設定で上書きされます。このオプションが有効でない状態で既存の設定との競合が発生する場合は、オペレーションが失敗します。表示されたエラーメッセージを使用して、競合をトラブルシューティングできます。このオプションを選択する前に、自分で管理する必要のある設定が、Amazon EKS アドオンにより管理されていないことを確認してください。
1. [**次へ**] を選択します。
1. **[確認と追加]** ページで、**[作成]** を選択します。アドオンのインストールが完了した後、インストールしたアドオンが表示されます。
------
#### [ CloudFormation ]
**CloudFormation を使用して Amazon CloudWatch Observability EKS アドオンをインストールするには**
1. まず、次の AWS CLI コマンドを実行して、必要な IAM ポリシーを IAM ロールにアタッチします。*my-role* を EKS Pod Identity の関連付けステップで作成したロールに置き換えます。
```
aws iam attach-role-policy \
--role-name my-role \
--policy-arn arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy
```
1. 次に、以下のリソースを作成します。`my-cluster-name` をクラスターの名前に置き換え、*111122223333* をアカウント ID に置き換え、*my-role* を EKS Pod Identity の関連付けステップで作成した IAM ロールに置き換えます。詳細については、「[AWS::EKS::Addon](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-eks-addon.html)」を参照してください。
```
{
"Resources": {
"EKSAddOn": {
"Type": "AWS::EKS::Addon",
"Properties": {
"AddonName": "amazon-cloudwatch-observability",
"ClusterName": "my-cluster-name",
"PodIdentityAssociations": [
{
"ServiceAccount": "cloudwatch-agent",
"RoleArn": "arn:aws:iam::111122223333:role/my-role"
}
]
}
}
}
}
```
------
#### [ Terraform ]
**Terraform を使用して Amazon CloudWatch Observability EKS アドオンをインストールするには**
1. 以下を使用します。`my-cluster-name` をクラスターの名前、*111122223333* をアカウント ID、*my-service-account-role* を EKS Pod Identity 関連付け手順で作成した IAM ロールに置き換えます。
詳細については、Terraform ドキュメントの「[Resource: aws\$1eks\$1addon](https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/eks_addon)」を参照してください。
1.
```
resource "aws_iam_role_policy_attachment" "CloudWatchAgentServerPolicy" {
policy_arn = "arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy"
role = "my-role"
}
resource "aws_eks_addon" "example" {
cluster_name = "my-cluster-name"
addon_name = "amazon-cloudwatch-observability"
pod_identity_associations {
roleArn = "arn:aws:iam::111122223333:role/my-role"
serviceAccount = "cloudwatch-agent"
}
}
```
------
## オプション 2: ワーカーノードで IAM のアクセス許可を使用してインストールする
この方法を使用するには、まず次のコマンドを入力して IAM ポリシー **CloudWatchAgentServerPolicy** をワーカーノードにアタッチします。このコマンドでは、*my-worker-node-role* を Kubernetes ワーカーノードが使用する IAM ロールに置き換えます。
```
aws iam attach-role-policy \
--role-name my-worker-node-role \
--policy-arn arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy
```
Amazon CloudWatch Observability EKS アドオンをインストールします。アドオンをインストールするには、AWS CLI、コンソール、CloudFormation または Terraform を使用できます。
------
#### [ AWS CLI ]
**AWS CLI を使用して Amazon CloudWatch Observability EKS アドオンをインストールするには**
次のコマンドを入力します。`my-cluster-name` を自分のクラスター名に置き換えます。
```
aws eks create-addon --addon-name amazon-cloudwatch-observability --cluster-name my-cluster-name
```
------
#### [ Amazon EKS console ]
**Amazon EKS コンソールを使用して Amazon CloudWatch Observability EKS アドオンを追加するには**
1. A[https://console.aws.amazon.com/eks/home\$1/clusters](https://console.aws.amazon.com/eks/home#/clusters) で Amazon EKS コンソールを開きます。
1. 左のナビゲーションペインで **[クラスター]** を選択してください。
1. Amazon CloudWatch Observability EKS アドオンを設定するクラスターの名前を選択します。
1. **[アドオン]** タブを選択してください。
1. **[その他のアドオンを入手]** を選択してください。
1. **[アドオンを選択]** ページで、次の操作を行います。
1. **[Amazon EKS アドオン]** セクションで、**[Amazon CloudWatch Observability]** チェックボックスを選択します。
1. [**次へ**] を選択します。
1. **[選択したアドオンセッティングの設定]** ページで、次の操作を行います。
1. 使用する **[バージョン]** を選択します。
1. (オプション) **[オプションの構成設定]** を展開できます。**[コンフリクト解決方法]** で **[上書きする]** を選択すると、既存のアドオンでの 1 つ以上の設定が、Amazon EKS アドオンの設定で上書きされます。このオプションが有効でない状態で既存の設定との競合が発生する場合は、オペレーションが失敗します。表示されたエラーメッセージを使用して、競合をトラブルシューティングできます。このオプションを選択する前に、自分で管理する必要のある設定が、Amazon EKS アドオンにより管理されていないことを確認してください。
1. [**次へ**] を選択します。
1. **[確認と追加]** ページで、**[作成]** を選択します。アドオンのインストールが完了した後、インストールしたアドオンが表示されます。
------
#### [ CloudFormation ]
**CloudFormation を使用して Amazon CloudWatch Observability EKS アドオンをインストールするには**
`my-cluster-name` を自分のクラスター名に置き換えます。詳細については、「[AWS::EKS::Addon](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-resource-eks-addon.html)」を参照してください。
```
{
"Resources": {
"EKSAddOn": {
"Type": "AWS::EKS::Addon",
"Properties": {
"AddonName": "amazon-cloudwatch-observability",
"ClusterName": "my-cluster-name"
}
}
}
}
```
------
#### [ Helm chart ]
**`amazon-cloudwatch-observability` Helm チャートを使用するには**
1. このチャートを使用するには、Helm をインストールしておく必要があります。Helm のインストールの詳細については、「[Helm ドキュメント](https://helm.sh/docs/)」を参照してください。
1. Helm をインストールしたら、次のコマンドを入力します。*my-cluster-name* をクラスターの名前に置き換え、*my-cluster-region* をクラスターが実行されるリージョンに置き換えます。
```
helm repo add aws-observability https://aws-observability.github.io/helm-charts
helm repo update aws-observability
helm install --wait --create-namespace --namespace amazon-cloudwatch amazon-cloudwatch-observability aws-observability/amazon-cloudwatch-observability --set clusterName=my-cluster-name --set region=my-cluster-region
```
------
#### [ Terraform ]
**Terraform を使用して Amazon CloudWatch Observability EKS アドオンをインストールするには**
`my-cluster-name` を自分のクラスター名に置き換えます。詳細については、「[Resource: aws\$1eks\$1addon](https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/eks_ad)」を参照してください。
```
resource "aws_eks_addon" "example" {
addon_name = "amazon-cloudwatch-observability"
cluster_name = "my-cluster-name"
}
```
------
## オプション 3: IAM サービスアカウントロールを使用してインストールする (アドオンを使用する場合のみ)
この方法は、Amazon CloudWatch Observability EKS アドオンを使用している場合にのみ有効です。この方法を使用する前に、次の前提条件を確認してください。
+ Container Insights がサポートされているいずれかの AWS リージョン に、ノードがアタッチされ機能している Amazon EKS クラスターがある。サポートされているリージョンのリストについては、「[Container Insights](ContainerInsights.md)」を参照してください。
+ クラスターに `kubectl` がインストールされ、設定されている。詳細については、*Amazon EKS ユーザーガイド*の「[`kubectl` のインストール](https://docs.aws.amazon.com/eks/latest/userguide/install-kubectl.html)」を参照してください。
+ `eksctl` がインストールされている。詳細については、「Amazon EKS ユーザーガイド」の「[Installing or updating `eksctl`](https://docs.aws.amazon.com/eks/latest/userguide/eksctl.html)」を参照してください。
------
#### [ AWS CLI ]
**AWS CLI を使用して IAM サービスアカウントロールを使用して Amazon CloudWatch Observability EKS アドオンをインストールするには**
1. クラスターに OpenID Connect (OIDC) プロバイダーがない場合、次のコマンドを入力して作成します。詳細については、「Amazon EKS ユーザーガイド」の「[Configuring a Kubernetes service account to assume an IAM role](https://docs.aws.amazon.com/eks/latest/userguide/associate-service-account-role.html)」を参照してください。
```
eksctl utils associate-iam-oidc-provider --cluster my-cluster-name --approve
```
1. 次のコマンドを入力してポリシー **CloudWatchAgentServerPolicy** がアタッチされた IAM ロールを作成し、OIDC を使用してそのロールを引き受けるようにエージェントのサービスアカウントを設定します。*my-cluster-name* をクラスターの名前、*my-service-account-role* をサービスアカウントを関連付けるロールの名前に置き換えます。ロールがまだ存在しない場合は、`eksctl` によって作成されます。
```
eksctl create iamserviceaccount \
--name cloudwatch-agent \
--namespace amazon-cloudwatch --cluster my-cluster-name \
--role-name my-service-account-role \
--attach-policy-arn arn:aws:iam::aws:policy/CloudWatchAgentServerPolicy \
--role-only \
--approve
```
1. 次のコマンドを入力して、アドオンをインストールします。*my-cluster-name* をクラスターの名前、*111122223333* をアカウント ID、*my-service-account-role* を前の手順で作成したIAM ロールに置き換えます。
```
aws eks create-addon --addon-name amazon-cloudwatch-observability --cluster-name my-cluster-name --service-account-role-arn arn:aws:iam::111122223333:role/my-service-account-role
```
------
#### [ Amazon EKS console ]
**コンソール上で、IAM サービスアカウントロールを使用して Amazon CloudWatch Observability EKS アドオンをインストールするには**
1. A[https://console.aws.amazon.com/eks/home\$1/clusters](https://console.aws.amazon.com/eks/home#/clusters) で Amazon EKS コンソールを開きます。
1. 左のナビゲーションペインで **[クラスター]** を選択してください。
1. Amazon CloudWatch Observability EKS アドオンを設定するクラスターの名前を選択します。
1. **[アドオン]** タブを選択してください。
1. **[その他のアドオンを入手]** を選択してください。
1. **[アドオンを選択]** ページで、次の操作を行います。
1. **[Amazon EKS アドオン]** セクションで、**[Amazon CloudWatch Observability]** チェックボックスを選択します。
1. [**次へ**] を選択します。
1. **[選択したアドオンセッティングの設定]** ページで、次の操作を行います。
1. 使用する **[バージョン]** を選択します。
1. **アドオンアクセス**の場合は、**[サービスアカウントの IAM ロール (IRSA)]** を選択します。
1. **アドオンアクセス**ボックスで IAM ロールを選択します。
1. (オプション) **[オプションの構成設定]** を展開できます。**[コンフリクト解決方法]** で **[上書きする]** を選択すると、既存のアドオンでの 1 つ以上の設定が、Amazon EKS アドオンの設定で上書きされます。このオプションが有効でない状態で既存の設定との競合が発生する場合は、オペレーションが失敗します。表示されたエラーメッセージを使用して、競合をトラブルシューティングできます。このオプションを選択する前に、自分で管理する必要のある設定が、Amazon EKS アドオンにより管理されていないことを確認してください。
1. [**次へ**] を選択します。
1. **[確認と追加]** ページで、**[作成]** を選択します。アドオンのインストールが完了した後、インストールしたアドオンが表示されます。
------
## Amazon EKS Hybrid Nodes の考慮事項
[Container Insights](ContainerInsights.md) はノードレベルのメトリクスの [EC2 インスタンスメタデータサービス](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-service.html) (IMDS) における可用性に依存するため、ノードレベルのメトリクスはハイブリッドノードでは利用できません。クラスター、ワークロード、Pod、コンテナレベルのメトリクスはハイブリッドノードで利用できます。
前のセクションの手順に従ってアドオンをインストールしたら、エージェントがハイブリッドノードで正常に実行できるように、アドオンマニフェストを更新する必要があります。クラスターの `amazoncloudwatchagents` リソースを編集し、`RUN_WITH_IRSA` 環境変数を追加して次のものと一致させます。
```
kubectl edit amazoncloudwatchagents -n amazon-cloudwatch cloudwatch-agent
```
```
apiVersion: v1
items:
- apiVersion: cloudwatch.aws.amazon.com/v1alpha1
kind: AmazonCloudWatchAgent
metadata:
...
name: cloudwatch-agent
namespace: amazon-cloudwatch
...
spec:
...
env:
- name: RUN_WITH_IRSA # <-- Add this
value: "True" # <-- Add this
- name: K8S_NODE_NAME
valueFrom:
fieldRef:
fieldPath: spec.nodeName
...
```
## (オプション) その他の設定
**Topics**
+ [
### コンテナログの収集をオプトアウトする
](#CloudWatch-Observability-EKS-addon-OptOutContainerLogs)
+ [
### カスタム Fluent Bit 設定を使用する
](#CloudWatch-Observability-EKS-addon-CustomFluentBit)
+ [
### インストールされたポッドワークロードの Kubernetes 許容範囲を管理する
](#CloudWatch-Observability-EKS-addon-Tolerations)
+ [
### 高速コンピューティングメトリクスの収集をオプトアウトする
](#CloudWatch-Observability-EKS-addon-OptOutAccelerated)
+ [
### カスタム CloudWatch エージェント設定を使用する
](#CloudWatch-Observability-EKS-addon-CustomAgentConfig)
+ [
### アドミッションウェブフック TLS 証明書の管理
](#CloudWatch-Observability-EKS-addon-Webhook)
+ [
### Amazon EBS ボリューム ID を収集する
](#CloudWatch-Observability-EKS-addon-VolumeIDs)
### コンテナログの収集をオプトアウトする
デフォルトでは、アドオンは Fluent Bit を使用してすべてのポッドからコンテナログを収集し、そのログを CloudWatch Logs に送信します。収集されるログについての詳細は、「[Fluent Bit の設定](Container-Insights-setup-logs-FluentBit.md#Container-Insights-FluentBit-setup)」を参照してください。
**注記**
アドオンも Helm チャートも、クラスター内の既存の Fluentd リソースや Fluent Bit リソースを管理しません。アドオンや Helm チャートをインストールする前に、既存の Fluentd や Fluent Bit リソースを削除できます。あるいは、既存のセットアップを維持し、アドオンや Helm チャートから Fluent Bit もインストールされないようにするには、このセクションの指示に従ってこうしたインストールを無効にできます。
Amazon CloudWatch Observability EKS アドオンを使用している場合に、コンテナログの収集をオプトアウトするには、アドオンの作成時または更新時に次のオプションを渡します。
```
--configuration-values '{ "containerLogs": { "enabled": false } }'
```
Helm チャートを使用している場合に、コンテナログの収集をオプトアウトするには、アドオンの作成時または更新時に次のオプションを渡します。
```
--set containerLogs.enabled=false
```
### カスタム Fluent Bit 設定を使用する
Amazon CloudWatch Observability EKS アドオンのバージョン 1.7.0 以降では、アドオンや Helm チャートを作成または更新するときに Fluent Bit 設定を変更できます。こうしてカスタマイズした Fluent Bit 設定は、アドオンでは詳細設定の `containerLogs` ルートレベルセクションで指定し、Helm チャートでは値のオーバーライドで指定します。このセクションでは、カスタマイズした Fluent Bit 設定を `config` セクション (Linux の場合) または `configWindows` セクション (Windows の場合) で指定します。`config` は、さらに次のサブセクションに分かれています。
+ `service` – `SERVICE` 設定を表すセクションであり、Fluent Bit エンジンのグローバルな動作を定義します。
+ `customParsers` - グローバルな `PARSER` を表すセクションであり、これを含めると非構造化ログエントリを取得して、ログの処理とその後のフィルタリングが容易になるように構造化できます。
+ `extraFiles` - Fluent Bit `conf` ファイルを追加で含めることができるセクションです。デフォルトでは、次の 3 つの `conf` ファイルが含まれています。
+ `application-log.conf` – クラスターから CloudWatch Logs 内のロググループ `/aws/containerinsights/my-cluster-name/application` にアプリケーションログを送信するための `conf` ファイル。
+ `dataplane-log.conf` – CRI ログ、kubelet ログ、kube-proxy ログ、Amazon VPC CNI ログなど、クラスターのデータプレーンコンポーネントに対応するログを CloudWatch Logs のロググループ `/aws/containerinsights/my-cluster-name/dataplane` に送信するための `conf` ファイル。
+ `host-log.conf` – Linux 上の `/var/log/dmesg`、`/var/log/messages`、`/var/log/secure` と、Windows 上の System `winlogs` から CloudWatch のロググループ `/aws/containerinsights/my-cluster-name/host` にログを送信するための `conf` ファイル。
**注記**
サブセクション内のフィールドを 1 つだけ変更する場合でも、上記の個々のセクションをすべて設定してください。デフォルトで有効になっている機能を無効にすることがないように、下記に示したデフォルト設定をベースラインとして使用し、そのうえで適宜変更を加えることをお勧めします。Amazon EKS アドオンの詳細設定を変更するときや、Helm チャートの値のオーバーライドを指定するときには、以下の YAML 設定を使用できます。
クラスターの `config` セクションを確認するには、GitHub の [aws-observability / helm-charts](https://github.com/aws-observability/helm-charts/releases) を参照し、インストールするアドオンまたは Helm チャートのバージョンに対応するリリースを見つけます。次に、`/charts/amazon-cloudwatch-observability/values.yaml` に移動して、`fluentBit` セクション内の `containerLogs` で `config` セクション (Linux の場合) および `configWindows` セクション (Windows の場合) を探します。
例えば、バージョン 1.7.0 のデフォルトの Fluent Bit 設定は、[ここで](https://github.com/aws-observability/helm-charts/blob/v1.7.0/charts/amazon-cloudwatch-observability/values.yaml#L44))確認できます。
`config` を、Amazon EKS アドオンの詳細設定を使用して指定する場合や、Helm インストールの値のオーバーライドとして指定する場合は、YAML として指定することをお勧めします。YAML が次の構造に準拠していることを確認してください。
```
containerLogs:
fluentBit:
config:
service: |
...
customParsers: |
...
extraFiles:
application-log.conf: |
...
dataplane-log.conf: |
...
host-log.conf: |
...
```
次の例では、`config` はフラッシュ間隔のグローバル設定を 45 秒に変更します。`Flush` フィールドへの変更はこれだけですが、サービスサブセクション全体に対する `SERVICE` 定義を指定する必要があります。この例では、他のサブセクションにオーバーライドを指定しなかったため、そのサブセクションではデフォルトが使用されます。
```
containerLogs:
fluentBit:
config:
service: |
[SERVICE]
Flush 45
Grace 30
Log_Level error
Daemon off
Parsers_File parsers.conf
storage.path /var/fluent-bit/state/flb-storage/
storage.sync normal
storage.checksum off
storage.backlog.mem_limit 5M
```
次の設定例には、追加で Fluent ビット `conf` ファイルが含まれています。この例では、`extraFiles` の下にカスタム `my-service.conf` を追加しており、3 つのデフォルトの `extraFiles` に加えて、このファイルが含まれます。
```
containerLogs:
fluentBit:
config:
extraFiles:
my-service.conf: |
[INPUT]
Name tail
Tag myservice.*
Path /var/log/containers/*myservice*.log
DB /var/fluent-bit/state/flb_myservice.db
Mem_Buf_Limit 5MB
Skip_Long_Lines On
Ignore_Older 1d
Refresh_Interval 10
[OUTPUT]
Name cloudwatch_logs
Match myservice.*
region ${AWS_REGION}
log_group_name /aws/containerinsights/${CLUSTER_NAME}/myservice
log_stream_prefix ${HOST_NAME}-
auto_create_group true
```
次の例では、既存の `conf` ファイルを `extraFiles` から完全に削除しています。空の文字列で上書きすることで、`application-log.conf` 全体が除外されます。`extraFiles` から `application-log.conf` を省いてもデフォルトの使用を示唆するだけであり、この例で示そうとしているのはそういうことではありません。同じことが、以前にカスタマイズして `extraFiles` に追加した `conf` ファイルを削除するといった場合にも言えます。
```
containerLogs:
fluentBit:
config:
extraFiles:
application-log.conf: ""
```
### インストールされたポッドワークロードの Kubernetes 許容範囲を管理する
Amazon CloudWatch Observability EKS アドオンのバージョン 1.7.0 以降、アドオンと Helm チャートはアドオンまたは Helm チャートがインストールするポッドワークロード上ですべてのテイントを許容するようにデフォルトで Kubernetes の許容範囲を設定します。これにより、CloudWatch エージェントや Fluent Bit などのデーモンセットは、デフォルトでクラスター内のすべてのノードでポッドをスケジュールできるようになります。許容範囲とテイントの詳細については、Kubernetes ドキュメントの「[Taints and Tolerations](https://kubernetes.io/docs/concepts/scheduling-eviction/taint-and-toleration/)」を参照してください。
アドオンまたは Helm チャートによってデフォルトで設定される許容範囲は次のとおりです。
```
tolerations:
- operator: Exists
```
アドオンの詳細設定を使用するときや、値のオーバーライドで Helm チャートをインストールまたはアップグレードするときに、`tolerations` フィールドをルートレベルで設定することで、デフォルトの許容範囲を上書きできます。例えば、次のようになります。
```
tolerations:
- key: "key1"
operator: "Exists"
effect: "NoSchedule"
```
許容範囲を完全に省略するには、次のような設定を使用できます。
```
tolerations: []
```
許容範囲に加えた変更は、アドオンまたは Helm チャートがインストールするすべてのポッドワークロードに適用されます。
### 高速コンピューティングメトリクスの収集をオプトアウトする
オブザーバビリティが強化された Container Insights は、デフォルトでは高速化コンピューティングのモニタリングのためにメトリクスを収集します。NVIDIA GPU メトリクス、AWS Trainium と AWS Inferentia の AWS Neuron メトリクス、AWS Elastic Fabric Adapter (EFA) メトリクスなどです。
Amazon EKS ワークロードの NVIDIA GPU メトリクスは、デフォルトではバージョン `v1.3.0-eksbuild.1` の EKS アドオンまたは Helm チャート、およびバージョン `1.300034.0` の CloudWatch エージェントから収集されます。収集されたメトリクスと前提条件のリストについては、「[NVIDIA GPU メトリクス](Container-Insights-metrics-enhanced-EKS.md#Container-Insights-metrics-EKS-GPU)」を参照してください。
AWS Trainium および AWS Inferentia アクセラレーターの AWS Neuron メトリクスは、バージョン `v1.5.0-eksbuild.1` の EKS アドオンまたは Helm チャート、およびバージョン `1.300036.0` の CloudWatch エージェントから収集されます。収集されたメトリクスと前提条件のリストについては、「[AWS Trainium と AWS Inferentia の AWS Neuron メトリクス](Container-Insights-metrics-enhanced-EKS.md#Container-Insights-metrics-EKS-Neuron)」を参照してください。
Amazon EKS クラスター上の Linux ノードの AWS Elastic Fabric Adapter (EFA) メトリクスは、デフォルトではバージョン `v1.5.2-eksbuild.1` の EKS アドオンまたは Helm チャート、およびバージョン `1.300037.0` の CloudWatch エージェントから収集されます。収集されたメトリクスと前提条件のリストについては、「[AWS Elastic Fabric Adapter (EFA) メトリクス](Container-Insights-metrics-enhanced-EKS.md#Container-Insights-metrics-EFA)」を参照してください。
CloudWatch エージェント設定ファイルの `accelerated_compute_metrics` フィールドを `false` に設定することで、これらのメトリクスの収集をオプトアウトできます。このフィールドは、CloudWatch 設定ファイルの `metrics_collected` セクションの `kubernetes` セクションで利用できます。以下は、オプトアウトの設定の例です。カスタム CloudWatch エージェント設定の使用方法の詳細については、次のセクション「[カスタム CloudWatch エージェント設定を使用する](#CloudWatch-Observability-EKS-addon-CustomAgentConfig)」を参照してください。
```
{
"logs": {
"metrics_collected": {
"kubernetes": {
"enhanced_container_insights": true,
"accelerated_compute_metrics": false
}
}
}
}
```
### カスタム CloudWatch エージェント設定を使用する
CloudWatch エージェントを使用して他のメトリクスやログやトレースを収集するには、Container Insights と CloudWatch Application Signals を有効にしたままカスタム設定を指定します。そのためには、EKS アドオンや Helm チャートを作成または更新するときに使用できる詳細設定を開き、エージェントキーの下にある設定キー内に CloudWatch エージェント設定ファイルを埋め込みます。次に、デフォルトのまま他に設定を行わない場合のエージェント設定を示します。
**重要**
他に構成設定を行って設定をカスタマイズした場合は、そのカスタム設定がエージェントで使用されるデフォルト設定よりも優先されます。オブザーバビリティが強化された Container Insights や CloudWatch Application Signals など、デフォルトで有効になっている機能を意図せず無効にしないように注意してください。エージェント設定をカスタマイズしなければならない場合は、以下のデフォルト設定をベースラインとして使用し、適宜必要な変更を加えることをお勧めします。
+ Amazon CloudWatch Observability EKS アドオンを使用する場合
```
--configuration-values '{
"agent": {
"config": {
"logs": {
"metrics_collected": {
"application_signals": {},
"kubernetes": {
"enhanced_container_insights": true
}
}
},
"traces": {
"traces_collected": {
"application_signals": {}
}
}
}
}
}'
```
+ Helm チャートを使用する場合
```
--set agent.config='{
"logs": {
"metrics_collected": {
"application_signals": {},
"kubernetes": {
"enhanced_container_insights": true
}
}
},
"traces": {
"traces_collected": {
"application_signals": {}
}
}
}'
```
次の例は、Windows 上の CloudWatch エージェントのデフォルトエージェント設定を示しています。Windows 上の CloudWatch エージェントは、カスタム設定をサポートしていません。
```
{
"logs": {
"metrics_collected": {
"kubernetes": {
"enhanced_container_insights": true
},
}
}
}
```
### アドミッションウェブフック TLS 証明書の管理
Amazon CloudWatch Observability EKS アドオンと Helm チャートは、Kubernetes [アドミッションウェブフック](https://kubernetes.io/docs/reference/access-authn-authz/extensible-admission-controllers/)を利用して、`AmazonCloudWatchAgent` および `Instrumentation` カスタムリソース (CR) リクエストのほか、オプションで CloudWatch Application Signals が有効になっている場合にはクラスター上の Kubernetes ポッドリクエストも、検証したうえで必要な変更を加えます。Kubernetes の場合、安全な通信を確保するためには、API サーバーからの信頼が設定された TLS 証明書がウェブフックに必要です。
デフォルトでは、Amazon CloudWatch Observability EKS アドオンと Helm チャートは、API サーバーとウェブフックサーバー間の通信を保護するために、自己署名 CA とこの CA の署名入りの TLS 証明書を自動生成します。この自動生成された証明書の有効期限はデフォルトで 10 年で、有効期限は自動更新されません。また、このアドオンや Helm チャートがアップグレードされるか再インストールされるたびに、CA バンドルと証明書が再生成されるため、有効期限がリセットされます。自動生成された証明書のデフォルトの有効期限を変更する場合は、アドオンを作成または更新するときに以下のように追加の設定を行います。*expiry-in-days* を目的の有効期限 (日) に置き換えてください。
+ これを Amazon CloudWatch Observability EKS アドオンに使用する
```
--configuration-values '{ "admissionWebhooks": { "autoGenerateCert": { "expiryDays": expiry-in-days } } }'
```
+ これを Helm チャートに使用する
```
--set admissionWebhooks.autoGenerateCert.expiryDays=expiry-in-days
```
安全性の高い多機能な証明機関を利用できるように、[cert-manager](https://cert-manager.io/docs/) がオプトインでサポートされています。Kubernetes で TLS 証明書を管理するのに広く採用されているソリューションであり、証明書を取得、更新、管理、使用するプロセスを簡素化できます。これにより、証明書が有効で最新の状態であることが保証されます。有効期限前の設定しておいた時刻になると、証明書が更新されます。また、[AWS Certificate Manager プライベート認証機関](https://aws.amazon.com/private-ca/)などサポートされているさまざまな発行元から簡単に証明書を発行できます。
クラスターで TLS 証明書を管理する場合のベストプラクティスを確認すること、および本番環境では cert-manager を選択することをお勧めします。アドミッションウェブフック TLS 証明書を管理できるように cert-manager を有効にすることにした場合は、Amazon CloudWatch Observability EKS アドオンや Helm チャートをインストールする前に、Amazon EKS クラスターに cert-manager をプリインストールしておく必要があることに注意してください。使用可能なインストールオプションの詳細については、[cert-manager のドキュメント](https://cert-manager.io/docs/installation/)を参照してください。インストールを終えたら、cert-manager を使用して、アドミッションウェブフック TLS 証明書を管理することもできます。その場合は、追加で以下の設定を行います。
+ Amazon CloudWatch Observability EKS アドオンを使用している場合
```
--configuration-values '{ "admissionWebhooks": { "certManager": { "enabled": true } } }'
```
+ Helm チャートを使用している場合
```
--set admissionWebhooks.certManager.enabled=true
```
```
--configuration-values '{ "admissionWebhooks": { "certManager": { "enabled": true } } }'
```
詳細設定では、ここで説明するように、デフォルトで[自己署名](https://cert-manager.io/docs/configuration/selfsigned/)発行者が使用されます。
### Amazon EBS ボリューム ID を収集する
パフォーマンスログで Amazon EBS ボリューム ID を収集する場合は、ワーカーノードまたはサービスアカウントにアタッチされた IAM ロールに別のポリシーを追加する必要があります。以下をインラインポリシーとして追加します。詳細については、「[Adding and Removing IAM Identity Permissions](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_manage-attach-detach.html)」を参照してください。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Action": [
"ec2:DescribeVolumes"
],
"Resource": "*",
"Effect": "Allow"
}
]
}
```
------
## Java Management Extensions (JMX) メトリクスの収集
CloudWatch エージェントは、Amazon EKS で Java Management Extensions (JMX) メトリクスの収集をサポートしています。これにより、Amazon EKS クラスターで実行されている Java アプリケーションから追加のメトリクスを収集し、パフォーマンス、メモリ使用量、トラフィック、その他の重要なメトリクスに関するインサイトを得ることができます。詳細については、「[Java Management Extensions (JMX) メトリクスの収集](CloudWatch-Agent-JMX-metrics.md)」を参照してください。
## Kueue メトリクスの有効化
CloudWatch Observability EKS アドオンのバージョン `v2.4.0-eksbuild.1` 以降、Container Insights for Amazon EKS は Amazon EKS クラスターから Kueue メトリクスの収集をサポートします。これらのメトリクスの詳細については、「[Kueue メトリクス](Container-Insights-metrics-EKS.md#Container-Insights-metrics-Kueue)」を参照してください。
Amazon SageMaker AI Hyperpod Task Governance EKS アドオンを使用している場合、**[前提条件]** セクションの手順をスキップし、「[設定フラグの有効化](#enable-Kueue-metrics-flag)」の手順にのみに従います。
### 前提条件
Amazon EKS クラスターに Kueue をインストールする前に、マニフェストファイルで次の更新を行います。
1. Kueue のオプションのクラスターキューリソースメトリクスを有効にします。これを行うには、`kueue-system` ConfigMap でインラインの `controller_manager_config.yaml` を変更します。`metrics` セクションで、`enableClusterQueueResources: true` 行を追加またはコメント解除します。
```
apiVersion: v1
data:
controller_manager_config.yaml: |
apiVersion: config.kueue.x-k8s.io/v1beta1
kind: Configuration
health:
healthProbeBindAddress: :8081
metrics:
bindAddress: :8080
enableClusterQueueResources: true <-- ADD/UNCOMMENT THIS LINE
```
1. デフォルトでは、すべての `k8s` サービスはクラスター全体で利用できます。Kueue は、メトリクスを公開するためのサービス `kueue-controller-manager-metrics-service` を作成します。メトリクスの観測値の重複を防止するには、このサービスを変更し、同じノードからメトリクスサービスにのみアクセス権を許可します。これを行うには、`kueue-controller-manager-metrics-service` 定義に `internalTrafficPolicy: Local` 行を追加します。
```
apiVersion: v1
kind: Service
metadata:
labels:
...
name: kueue-controller-manager-metrics-service
namespace: kueue-system
spec:
ports:
- name: https
port: 8443
protocol: TCP
targetPort: https
internalTrafficPolicy: Local <-- ADD THIS LINE
selector:
control-plane: controller-manager
```
1. 最後に、`kueue-controller-manager` ポッドによって `kube-rbac-proxy` コンテナが作成されます。現在、このコンテナには高レベルのログ記録の詳細度があり、メトリクススクレイパーが `kueue-controller-manager-metrics-service` にアクセスすると、クラスターのベアラートークンがそのコンテナによってログ記録される原因になります。このログ記録の詳細を減らすことをお勧めします。Kueue によって配布されるマニフェストのデフォルト値は 10 です。0 に変更することをお勧めします。
```
apiVersion: apps/v1
kind: Deployment
metadata:
labels:
...
name: kueue-controller-manager
namespace: kueue-system
spec:
...
template:
...
spec:
containers:
...
- args:
- --secure-listen-address=0.0.0.0:8443
- --upstream=http://127.0.0.1:8080/
- --logtostderr=true
- --v=0 <-- CHANGE v=10 TO v=0
image: gcr.io/kubebuilder/kube-rbac-proxy:v0.8.0
name: kube-rbac-proxy
...
```
### 設定フラグの有効化
Kueue メトリクスを有効にするには、アドオンの追加設定で `kueue_container_insights` を有効にする必要があります。これを行うには、AWS CLI を使用して EKS Observability アドオンを設定するか、Amazon EKS コンソールを使用します。
次のいずれかの方法で EKS Observability アドオンを正常にインストールできたら、HyperPod コンソールの **[ダッシュボード]** タブで Amazon EKS クラスターメトリクスを表示できます。
------
#### [ AWS CLI ]
**AWS CLI を使用して Kueue メトリクスを有効にする方法**
+ 次の AWS CLI コマンドを入力してアドオンをインストールします。
```
aws eks create-addon --cluster-name cluster-name --addon-name amazon-cloudwatch-observability --configuration-values "configuration_json_file"
```
次の例は、設定値を持つ JSON ファイルです。
```
{
"agent": {
"config": {
"logs": {
"metrics_collected": {
"kubernetes": {
"kueue_container_insights": true,
"enhanced_container_insights": true
},
"application_signals": { }
}
},
"traces": {
"traces_collected": {
"application_signals": { }
}
}
},
},
}
```
------
#### [ Amazon EKS console ]
**Amazon EKS コンソールを使用して Kueue メトリクスを有効にする方法**
1. [https://console.aws.amazon.com/eks/home\$1/clusters](https://console.aws.amazon.com/eks/home#/clusters) で Amazon EKS コンソールを開きます。
1. クラスターの名前を選択します。
1. **[アドオン]** を選択します。
1. リストで **[Amazon CloudWatch Observability]** アドオンを見つけてインストールします。これを行うとき、**[オプションの設定]** を選択して次の JSON 設定値を含めます。
```
{
"agent": {
"config": {
"logs": {
"metrics_collected": {
"kubernetes": {
"kueue_container_insights": true,
"enhanced_container_insights": true
},
"application_signals": { }
}
},
"traces": {
"traces_collected": {
"application_signals": { }
}
}
},
},
}
```
------
## OpenTelemetry コレクター設定ファイルの追加
CloudWatch エージェントは、独自の設定ファイルとともに、補足的な OpenTelemetry コレクター設定ファイルをサポートします。この機能を使用すると、CloudWatch エージェント設定を通じて CloudWatch Application Signals や Container Insights などの CloudWatch エージェント機能が使用できます。また、単一のエージェントで既存の OpenTelemetry コレクター設定を取り込むこともできます。
CloudWatch エージェントによって自動的に作成されたパイプラインとのマージ競合を防ぐには、OpenTelemetry コレクター設定の各コンポーネントおよびパイプラインにカスタムサフィックスを追加することをお勧めします。これにより、競合やマージ競合を防ぐことができます。
+ Amazon CloudWatch Observability EKS アドオンを使用している場合
```
--configuration-values file://values.yaml
```
または
```
--configuration-values '
agent:
otelConfig:
receivers:
otlp/custom-suffix:
protocols:
http: {}
exporters:
awscloudwatchlogs/custom-suffix:
log_group_name: "test-group"
log_stream_name: "test-stream"
service:
pipelines:
logs/custom-suffix:
receivers: [otlp/custom-suffix]
exporters: [awscloudwatchlogs/custom-suffix]
'
```
+ Helm チャートを使用している場合
```
--set agent.otelConfig='
receivers:
otlp/custom-suffix:
protocols:
http: {}
exporters:
awscloudwatchlogs/custom-suffix:
log_group_name: "test-group"
log_stream_name: "test-stream"
service:
pipelines:
logs/custom-suffix:
receivers: [otlp/custom-suffix]
exporters: [awscloudwatchlogs/custom-suffix]
'
```
## Amazon EKS クラスターの Application Signals による APM の有効化
デフォルトでは、CloudWatch Observability EKS アドオン (V5.0.0 以降) または Helm チャートのいずれかをインストールすると、OpenTelemetry (OTEL) ベースの Application Performance Monitoring (APM) が Application Signals を通じて有効になります。Amazon EKS アドオンの高度な設定を使用するか、Helm チャートで値を上書きすることで、特定の設定をさらにカスタマイズできます。
**注記**
OpenTelemetry (OTEL) ベースの APM ソリューションを使用する場合、Application Signals を有効にすると、既存のオブザーバビリティ設定に影響します。続行する前に、現在の実装を確認します。V5.0.0 以降にアップグレードした後に既存の APM 設定を維持するには、「[Application Signals のオプトアウト](#Opting-out-App-Signals)」を参照してください。
**Application Signals 自動モニター**
CloudWatch Observability Amazon EKS アドオンと Helm チャートのバージョン 5.0.0 では、新機能が導入されています。自動モニター設定を使用して、EKS クラスター内のすべてのサービスワークロードまたは特定のサービスワークロードに対して Application Signals を自動的に有効にできるようになりました。次の `autoMonitor` 設定は、詳細設定の `applicationSignals` セクションの `manager` セクション内で指定できます。
+ *monitorAllServices* – 自動モニターによるすべてのサービスワークロードのモニタリングを有効 (true) または無効 (false) にするブールフラグ。デフォルトは true です。このフラグを有効にすると、Kubernetes サービスにマッピングされているクラスター内のすべての Kubernetes ワークロード (デプロイ、DaemonSets、および StatefulSets) が、初めて起動したとき (または既存のワークロードで再起動したとき) に Application Signals の自動有効化の対象になります。デフォルトでは、`kube-system` および `amazon-cloudwatch` 名前空間のワークロードはシステムによって除外されます。
+ *languages* – `monitorAllServices` が有効になっている場合、Application Signals がサービスを自動的に計測しようとする言語のセットを指定する文字列のリスト。すべての[サポートされている言語](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Application-Monitoring-Sections.html)がデフォルトです。
+ *restartPods* – ブールフラグは、設定の変更後にワークロードを再起動するかどうかを制御します。デフォルトは false です。このフラグを `true` に有効にすると、設定変更を保存するときに自動モニタースコープ内の Kubernetes ワークロードが自動的に再起動するかどうかを制御します。`updateStrategy` などのポッドの再起動に影響する Kubernetes ワークロードの設定が考慮されます。再起動すると、サービスのダウンタイムが発生する可能性があることに注意してください。
+ *customSelector* – 自動モニターの特定の Kubernetes 名前空間またはワークロードを選択する設定。
+ *java* – Java で自動的に計測するワークロードを指定します
+ *python* – Python で自動的に計測するワークロードを指定します
+ *nodejs* – Node.js を使用して自動的に計測するワークロードを指定します
+ *dotnet* – .NET を使用して自動的に計測するワークロードを指定します
上記の各言語について、次のフィールドを設定できます。
+ *namespaces* – 選択した名前空間を指定する文字列のリスト。デフォルトは空のリスト、つまり [] です
+ *deployments* – 選択したデプロイを指定する文字列のリスト。`namespace/deployment` 形式で指定します。デフォルトは空のリスト、つまり [] です
+ *daemonsets* – 選択したデーモンセットを指定する文字列のリスト。`namespace/daemonset` 形式で指定します。デフォルトは空のリスト、つまり [] です
+ *statefulsets* – 選択したステートフルセットを指定する文字列のリスト。`namespace/statefulset` 形式で指定します。デフォルトは空のリスト、つまり [] です
+ *exclude* – 特定の Kubernetes 名前空間またはワークロードを自動モニターから除外する設定。同じワークロードが `monitorAllServices` または `customSelector` のスコープ内にある場合、ワークロードの除外が優先されます。
+ *java* – Java で自動的に計測されないように除外するワークロードを指定します
+ *python* – Python で自動的に計測されないように除外するワークロードを指定します
+ *nodejs* – Node.js で自動的に計測されないように除外するワークロードを指定します
+ *dotnet* – .NET で自動的に計測されないように除外するワークロードを指定します
上記の各言語について、次のフィールドを設定できます。
+ *namespaces* – 除外する名前空間を指定する文字列のリスト。デフォルトは空のリスト、つまり [] です
+ *deployments* – 除外するデプロイを指定する文字列のリスト。`namespace/deployment` 形式で指定します。デフォルトは空のリスト、つまり [] です
+ *daemonsets* – 除外するデーモンセットを指定する文字列のリスト。`namespace/daemonset` 形式で指定します。デフォルトは空のリスト、つまり [] です
+ *statefulsets* – 除外するステートフルセットを指定する文字列のリスト。`namespace/statefulset` 形式で指定します。デフォルトは空のリスト、つまり [] です
以下は、クラスター上のすべての既存および新規のサービスワークロードに対して Application Signals を自動的に有効にする設定例です。
```
manager:
applicationSignals:
autoMonitor:
monitorAllServices: true
restartPods: true
```
以下は、起動された新しいサービスワークロードと、クラスターで明示的に再起動された既存のサービスワークロードに対して Application Signals を自動的に有効にする設定例です。
```
manager:
applicationSignals:
autoMonitor:
monitorAllServices: true
```
以下は、`pet-warehouse` 名前空間のワークロードに対応するすべての既存および新規のポッドに対して、Java で Application Signals を自動的に有効にする設定例です。
```
manager:
applicationSignals:
autoMonitor:
restartPods: true
customSelector:
java:
namespaces: ["pet-warehouse"]
```
以下は、`pet-clinic` デプロイを除くクラスター内のすべての既存および新規のサービスワークロードに対して Python で Application Signals を自動的に有効にする設定例です。
```
manager:
applicationSignals:
autoMonitor:
monitorAllServices: true
languages: ["python"]
restartPods: true
exclude:
python:
deployments: ["pet-warehouse/pet-clinic"]
```
以下は、`python-apps` 名前空間内のワークロードを除くクラスター内のすべてのサービスワークロードに対して Java を使用した Application Signals を自動的に有効にし、さらに `python-apps` 名前空間内の `sample-python-app` デプロイに対して Python を使用した Application Signals を有効にする設定例です。
```
manager:
applicationSignals:
autoMonitor:
monitorAllServices: true
languages: ["java"]
restartPods: true
customSelector:
python:
deployments: ["python-apps/sample-python-app"]
exclude:
java:
namespaces: ["python-apps"]
```
## Amazon CloudWatch Observability EKS アドオンや Helm チャートのトラブルシューティング
以下の情報を参考にして、Amazon CloudWatch Observability EKS アドオンや Helm チャートに関する問題のトラブルシューティングを行います。
**Topics**
+ [
### Amazon CloudWatch Observability EKS アドオンや Helm チャートの更新と削除
](#EKS-addon-troubleshoot-update)
+ [
### Amazon CloudWatch Observability EKS アドオンや Helm チャートで使用される CloudWatch エージェントのバージョンを確認する
](#EKS-addon-troubleshoot-version)
+ [
### アドオンや Helm チャートの管理時の ConfigurationConflict の処理
](#EKS-addon-troubleshoot-conflict)
### Amazon CloudWatch Observability EKS アドオンや Helm チャートの更新と削除
Amazon CloudWatch Observability EKS アドオンを更新または削除する手順については、「[Amazon EKS アドオンの管理](https://docs.aws.amazon.com/eks/latest/userguide/managing-add-ons.html)」を参照してください。アドオン名には `amazon-cloudwatch-observability` を使用してください。
クラスター内の Helm チャートを削除するには、次のコマンドを入力します。
```
helm delete amazon-cloudwatch-observability -n amazon-cloudwatch --wait
```
### Amazon CloudWatch Observability EKS アドオンや Helm チャートで使用される CloudWatch エージェントのバージョンを確認する
Amazon CloudWatch Observability EKS アドオンと Helm チャートは、使用中の CloudWatch エージェントのバージョンなど、クラスター上の CloudWatch エージェントデーモンセットの動作を制御する `AmazonCloudWatchAgent` のカスタムリソースをインストールします。以下のコマンドを入力して、クラスターにインストールされている `AmazonCloudWatchAgent` カスタムリソースがすべて記載されたリストを取得できます。
```
kubectl get amazoncloudwatchagent -A
```
このコマンドの出力を調べれば、CloudWatch エージェントのバージョンを確認できるはずです。このほか、`amazoncloudwatchagent` リソースを記述するか、クラスターで動作しているいずれかの `cloudwatch-agent-*` ポッドを記述して、使用中のイメージを調べることもできます。
### アドオンや Helm チャートの管理時の ConfigurationConflict の処理
Amazon CloudWatch Observability EKS アドオンや Helm チャートのインストールまたは更新時に、既存のリソースによって生じたエラーが見られたとします。これはおそらく、CloudWatch エージェントとその関連コンポーネント (ServiceAccount、ClusterRole、ClusterRoleBinding など) がクラスターにインストールされていることが原因と考えられます。
アドオンによって表示されるエラーには、`Conflicts found when trying to apply. Will not continue due to resolve conflicts mode` などがあります。
Helm チャートによって表示されるエラーは、`Error: INSTALLATION FAILED: Unable to continue with install and invalid ownership metadata.` のようになります。
このアドオンや Helm チャートによって CloudWatch エージェントとその関連コンポーネントがインストールされるときに内容の変更が検出されると、デフォルトではインストールまたは更新が失敗します。これによって、クラスター上にあるリソースの状態が上書きされることを防いでいます。
Amazon CloudWatch Observability EKS アドオンへのオンボード時にこのエラーが発生した場合は、クラスターにインストール済みの CloudWatch エージェントセットアップを削除した後に EKS アドオンや Helm チャートをインストールすると良いでしょう。カスタムエージェント設定など、元の CloudWatch エージェントセットアップへのカスタマイズを必ずバックアップし、アドオンや Helm チャートを次回インストールまたは更新するときにそれらのカスタマイズを適用してください。Container Insights へのオンボーディングを目的に CloudWatch エージェントをインストール済みである場合は、「[Container Insights の CloudWatch エージェントと Fluent Bit の削除](ContainerInsights-delete-agent.md)」で詳細を確認してください。
その他に、アドオンでサポートされている設定オプションで `OVERWRITE` を指定して競合を解決することも可能です。このオプションを使用すると、クラスター上の競合を上書きしてアドオンのインストールまたは更新を継続できます。Amazon EKS コンソールを使用する場合、アドオンの作成または更新時に **[オプションの構成設定]** を選択すると、**[競合の解決方法]** が表示されます。AWS CLI を使用する場合は、コマンドに `--resolve-conflicts OVERWRITE` を指定することで、アドオンを作成または更新できます。
## Application Signals のオプトアウト
CloudWatch コンソールまたは SDK を使用して、サービスモニタリング設定をファインチューニングします。
5.0.0 より前のバージョンでは、Application Signals 自動モニタリングを無効にするには、以下の手順に従います。
**CLI または SDK の使用**
次の設定は、EKS アドオンの高度な設定として適用することも、Helm チャートを使用する場合の値の上書きとして適用することもできます。
```
{
"manager": {
"applicationSignals": {
"autoMonitor": {
"monitorAllServices": false
}
}
}
}
```
変更を有効にするには、サービスを再起動します。
**コンソールの使用**
CloudWatch コンソールの [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/) を開いてください。
1. ナビゲーションペインの **[Application Signals (APM)]** で、**[サービス]** を選択します。
1. **[Application Signals を有効にする]** を選択して、有効化ページを表示します。
1. モニタリングしない各サービスの **[自動モニタリング]** チェックボックスをオフにします。
1. 変更を有効にするには、サービスを再起動します。
# Security-Enhanced Linux (SELinux) で CloudWatch エージェントをセットアップする
システムで Security-Enhanced Linux (SELinux) が有効になっている場合は、適切なセキュリティポリシーを適用して、CloudWatch エージェントが制限のあるドメインで実行されるようにする必要があります。
## 前提条件
エージェントに SELinux を設定する前に、次の**[前提条件]**を確認してください。
**SELinux で CloudWatch エージェントを使用するための前提条件を満たすには**
1. まだインストールしていない場合は、次の SELinux ポリシー開発パッケージをインストールします。
```
sudo yum update
sudo yum install -y selinux-policy-devel policycoreutils-devel rpm-build git
```
1. 次のコマンドを実行して、システムの SELinux のステータスを確認します。
```
sestatus
```
出力例:
```
SELinux status: enabled
SELinuxfs mount: /sys/fs/selinux
SELinux root directory: /etc/selinux
Loaded policy name: targeted
Current mode: permissive
Mode from config file: permissive
Policy MLS status: enabled
Policy deny_unknown status: allowed
Memory protection checking: actual (secure)
Max kernel policy version: 33
```
SELinux が現在無効になっている場合は、次の操作を行います。
1. 次のコマンドを入力して SELinux ファイルを開きます。
```
sudo vi /etc/selinux/config
```
1. `SELINUX` パラメータを `permissive` または `enforcing` に設定します。例えば、次のようになります。
```
SELINUX=enforcing
```
1. ファイルを保存し、システムを再起動して変更を適用します。
```
sudo reboot
```
1. CloudWatch エージェントが `systemd` サービスとして実行されていることを確認します。これは、制限のある SELinux ドメイン内での使用に必要になります。
```
sudo systemctl status amazon-cloudwatch-agent
```
エージェントが正しく設定されている場合、起動時に出力でエージェントが `active (running)` と `enabled` であることが示されます。
## エージェントに SELinux を設定する
前提条件を完了したら、SELinux を設定できます。
**CloudWatch エージェントに SELinux を設定するには**
1. 次のコマンドを入力して、CloudWatch エージェントの SELinux ポリシーを複製します。
```
git clone https://github.com/aws/amazon-cloudwatch-agent-selinux.git
```
1. 複製したリポジトリに移動し、次のコマンドを入力してスクリプトのアクセス許可を更新します。
```
cd amazon-cloudwatch-agent-selinux
chmod +x amazon_cloudwatch_agent.sh
```
1. `sudo` を使用し、次のコマンドを入力して SELinux ポリシーのインストールスクリプトを実行します。実行中、スクリプトは `y` または `n` を入力して自動再起動を許可するように求めます。この再起動によって、エージェントが正しい SELinux ドメインに移行されます。
```
sudo ./amazon_cloudwatch_agent.sh
```
1. CloudWatch エージェントをまだ再起動していない場合は、再起動して正しい SELinux ドメインに移行されることを確認します。
```
sudo systemctl restart amazon-cloudwatch-agent
```
1. 次のコマンドを入力して、CloudWatch エージェントが制限されているドメイン内で実行中であることを確認します。
```
ps -efZ | grep amazon-cloudwatch-agent
```
エージェントが正しく制限されている場合、出力は `unconfined_service_t` ではなく SELinux で制限されているドメインを示します。
以下は、エージェントが正しく制限されている場合の出力の例です。
```
system_u:system_r:confined_t:s0 root 1234 1 0 12:00 ? 00:00:10 /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent
```
SELinux を設定したら、メトリクス、ログ、トレースを収集するようにエージェントを設定できます。詳細については、「[CloudWatch エージェント設定ファイルを手動で作成または編集する](CloudWatch-Agent-Configuration-File-Details.md)」を参照してください。
# CloudWatch エージェント設定ファイルを作成する
CloudWatch エージェントをサーバーで実行する前に、CloudWatch エージェント設定ファイルを 1 つ以上作成する必要があります。
エージェント設定ファイルは、カスタムメトリクスを含め、エージェントが収集するメトリクス、ログ、トレースを指定する JSON ファイルです。このファイルを作成するには、ウィザードを使用するか、一から自分で作成します。また、ウィザードを使用して最初に設定ファイルを作成してから、手動で変更することもできます。ファイル手動で作成または変更するほうがプロセスが複雑になりますが、収集されるメトリクスをきめ細かくコントロールし、ウィザードで使用できないメトリクスを指定できます。
エージェント設定ファイルを変更するときは必ず、エージェントを再起動して変更を有効にする必要があります。エージェントを再起動するには、「[(オプション) CloudWatch エージェントの一般的な設定と名前付きプロファイルを変更する](installing-cloudwatch-agent-ssm.md#CloudWatch-Agent-profile-instance-fleet)」の手順に従います。
設定ファイルを作成したら、手動で JSON ファイルとして保存し、エージェントをサーバーにインストールする際に使用することができます。また、エージェントをサーバーにインストールする際にSystems Manager を使用する場合は、Systems Manager Parameter Store に保存することもできます。
CloudWatch エージェントは複数の設定ファイルの使用に対応しています。詳細については、「[複数の CloudWatch エージェント設定ファイルを作成する](#CloudWatch-Agent-multiple-config-files)」を参照してください。
CloudWatch エージェントによって収集されたメトリクス、ログ、トレースには料金が発生します。料金の詳細については、「[Amazon CloudWatch の料金](https://aws.amazon.com/cloudwatch/pricing)」を参照してください。
**Topics**
+ [
# ウィザードを使用して CloudWatch エージェント設定ファイルを作成する
](create-cloudwatch-agent-configuration-file-wizard.md)
+ [
## 複数の CloudWatch エージェント設定ファイルを作成する
](#CloudWatch-Agent-multiple-config-files)
+ [
# CloudWatch エージェント設定ファイルを手動で作成または編集する
](CloudWatch-Agent-Configuration-File-Details.md)
# ウィザードを使用して CloudWatch エージェント設定ファイルを作成する
エージェント設定ファイルウィザード (`amazon-cloudwatch-agent-config-wizard`) では、ニーズに合わせて CloudWatch エージェントを設定するための一連の質問を行います。このセクションでは、設定ファイルに必要な認証情報について説明します。また、CloudWatch エージェント設定ウィザードを実行する方法について説明します。さらに、ウィザードに事前定義されているメトリクスについても説明します。
## 必要な認証情報
ウィザードの開始前に AWS 認証方法および設定ファイルを所定の場所に置いた場合、ウィザードは使用する認証情報と AWS リージョンを自動検出できます。これらのファイルの詳細については、*AWS Systems Manager ユーザーガイド*の[設定ファイルと認証情報ファイル](https://docs.aws.amazon.com/cli/latest/userguide/cli-config-files.html)を参照してください。
ウィザードでは、AWS 認証ファイルのデフォルトの認証情報を確認するとともに、次のような `AmazonCloudWatchAgent` セクションを探します。
```
[AmazonCloudWatchAgent]
aws_access_key_id = my_access_key
aws_secret_access_key = my_secret_key
```
また、このウィザードには、デフォルトの認証情報、`AmazonCloudWatchAgent` の認証情報、および `Others` オプションが表示されます。使用する認証情報を選択することができます。`Others` を選択した場合は、認証情報を入力できます。
*my\$1access\$1key* および *my\$1secret\$1key* で、Systems Manager Parameter Store に書き込むアクセス許可がある IAM ユーザーのキーを使用します。
AWS 設定ファイルで、エージェントからメトリクスを送信する先のリージョンを指定できます (`[default]` セクションのリージョンと異なる場合)。デフォルトでは、Amazon EC2 インスタンスが配置されているリージョンにメトリクスが発行されます。メトリクスを別のリージョンに発行する場合は、ここでリージョンを指定します。次の例では、メトリクスを `us-west-1` リージョンに発行しています。
```
[AmazonCloudWatchAgent]
region = us-west-1
```
## CloudWatch エージェント設定ウィザードを実行する
**CloudWatch エージェント設定ファイルを作成するには**
1. CloudWatch エージェント設定ウィザードを開始するには、次のように入力します。
```
sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-config-wizard
```
Windows Server を実行しているサーバーで、次のコマンドを実行してウィザードを起動します。
```
cd "C:\Program Files\Amazon\AmazonCloudWatchAgent"
```
```
.\amazon-cloudwatch-agent-config-wizard.exe
```
1. 質問に答えて、サーバーの設定ファイルをカスタマイズします。
1. 設定ファイルをローカルに保存する場合、設定ファイル `config.json` は Linux サーバーでは `/opt/aws/amazon-cloudwatch-agent/bin/` に保存され、Windows Server では `C:\Program Files\Amazon\AmazonCloudWatchAgent` に保存されます。これで、エージェントをインストールする他のサーバーにこのファイルをコピーできます。
Systems Manager を使用してエージェントをインストールおよび設定する場合、ファイルを Systems Manager Parameter Store に保存するかどうかを確認するよう求められたら、必ず「**Yes**」と回答してください。SSM Agent を使用して CloudWatch エージェントをインストールしていない場合でも、ファイルを Parameter Store に保存することもできます。Parameter Store にファイルを保存できるようにするには、十分なアクセス権限を持つ IAM ロールを使用する必要があります。
## CloudWatch エージェントの事前定義されたメトリクスセット
ウィザードは、異なる詳細レベルを持つ、事前定義されたメトリクスセットで設定されます。これらのメトリクスのセットを次の表に示します。これらのメトリクスの詳細については、[CloudWatch エージェントにより収集されるメトリクス](metrics-collected-by-CloudWatch-agent.md)を参照してください。
**注記**
Parameter Store では、標準とアドバンストの階層のパラメータをサポートしています。これらのパラメータ層は、これらの表で説明されているメトリクス詳細のベーシックレベル、標準レベル、アドバンストレベルとは関係ありません。
**Linux を実行する Amazon EC2 インスタンス**
| 詳細レベル | 含められるメトリクス |
| --- | --- |
| **ベーシック** | **Mem:** mem\$1used\$1percent **Disk:** disk\$1used\$1percent `disk` などの `disk_used_percent` メトリクスには `Partition` のディメンションがあります。つまり、生成されるカスタムメトリクスの数は、インスタンスに関連付けられたパーティションの数によって異なります。ディスクパーティションの数は、使用している AMI とサーバーにアタッチする Amazon EBS ボリュームの数によって異なります。 |
| **スタンダード** | **CPU:** `cpu_usage_idle`、`cpu_usage_iowait`、`cpu_usage_user`、`cpu_usage_system` **Disk:** `disk_used_percent`、`disk_inodes_free` **Diskio:** `diskio_io_time` **Mem:** `mem_used_percent` **Swap:** `swap_used_percent` |
| **アドバンスト** | **CPU:** `cpu_usage_idle`、`cpu_usage_iowait`、`cpu_usage_user`、`cpu_usage_system` **Disk:** `disk_used_percent`、`disk_inodes_free` **Diskio:** `diskio_io_time`、`diskio_write_bytes`、`diskio_read_bytes`、`diskio_writes`、`diskio_reads` **Mem:** `mem_used_percent` **Netstat:** `netstat_tcp_established`、`netstat_tcp_time_wait` **Swap:** `swap_used_percent` |
**Linux を実行しているオンプレミスサーバー**
| 詳細レベル | 含められるメトリクス |
| --- | --- |
| **ベーシック** | **Disk:** `disk_used_percent` **Diskio:** `diskio_write_bytes`、`diskio_read_bytes`、`diskio_writes`、`diskio_reads` **Mem:** `mem_used_percent` **Net:** `net_bytes_sent`、`net_bytes_recv`、`net_packets_sent`、`net_packets_recv` **Swap:** `swap_used_percent` |
| **スタンダード** | **CPU:** `cpu_usage_idle`、`cpu_usage_iowait` **Disk:** `disk_used_percent`、`disk_inodes_free` **Diskio:** `diskio_io_time`、`diskio_write_bytes`、`diskio_read_bytes`、`diskio_writes`、`diskio_reads` **Mem:** `mem_used_percent` **Net:** `net_bytes_sent`、`net_bytes_recv`、`net_packets_sent`、`net_packets_recv` **Swap:** `swap_used_percent` |
| **アドバンスト** | **CPU:** `cpu_usage_guest`、`cpu_usage_idle`、`cpu_usage_iowait`、`cpu_usage_steal` 、`cpu_usage_user`、`cpu_usage_system` **Disk:** `disk_used_percent`、`disk_inodes_free` **Diskio:** `diskio_io_time`、`diskio_write_bytes`、`diskio_read_bytes`、`diskio_writes`、`diskio_reads` **Mem:** `mem_used_percent` **Net:** `net_bytes_sent`、`net_bytes_recv`、`net_packets_sent`、`net_packets_recv` **Netstat:** `netstat_tcp_established`、`netstat_tcp_time_wait` **Swap:** `swap_used_percent` |
**Windows Server を実行する Amazon EC2 インスタンス**
**注記**
この表に記載されているメトリクス名は、メトリクスがどのようにコンソールに表示されるかを示しています。実際のメトリクス名には、最初の単語が含まれていない場合があります。例えば、`LogicalDisk % Free Space` の実際のメトリクス名は `% Free Space` です。
| 詳細レベル | 含められるメトリクス |
| --- | --- |
| **ベーシック** | **Memory:** `Memory % Committed Bytes In Use` **LogicalDisk:** `LogicalDisk % Free Space` |
| **スタンダード** | **Memory:** `Memory % Committed Bytes In Use` **Paging:** `Paging File % Usage` **Processor:** `Processor % Idle Time`、`Processor % Interrupt Time`、`Processor % User Time` **PhysicalDisk:** `PhysicalDisk % Disk Time` **LogicalDisk:** `LogicalDisk % Free Space` |
| **アドバンスト** | **Memory:** `Memory % Committed Bytes In Use` **Paging:** `Paging File % Usage` **Processor:** `Processor % Idle Time`、`Processor % Interrupt Time`、`Processor % User Time` **LogicalDisk:** `LogicalDisk % Free Space` **PhysicalDisk:** `PhysicalDisk % Disk Time`、`PhysicalDisk Disk Write Bytes/sec`、`PhysicalDisk Disk Read Bytes/sec`、`PhysicalDisk Disk Writes/sec`、`PhysicalDisk Disk Reads/sec` **TCP:** `TCPv4 Connections Established`、 `TCPv6 Connections Established` |
**Windows Server を実行しているオンプレミスサーバー**
**注記**
この表に記載されているメトリクス名は、メトリクスがどのようにコンソールに表示されるかを示しています。実際のメトリクス名には、最初の単語が含まれていない場合があります。例えば、`LogicalDisk % Free Space` の実際のメトリクス名は `% Free Space` です。
| 詳細レベル | 含められるメトリクス |
| --- | --- |
| **ベーシック** | **Paging: **`Paging File % Usage` **Processor:** `Processor % Processor Time` **LogicalDisk:**`LogicalDisk % Free Space` **PhysicalDisk:** `PhysicalDisk Disk Write Bytes/sec`、`PhysicalDisk Disk Read Bytes/sec` 、`PhysicalDisk Disk Writes/sec`、`PhysicalDisk Disk Reads/sec` **Memory:** `Memory % Committed Bytes In Use` **Network Interface:** `Network Interface Bytes Sent/sec`、`Network Interface Bytes Received/sec`、`Network Interface Packets Sent/sec`、`Network Interface Packets Received/sec` |
| **スタンダード** | **Paging:** `Paging File % Usage` **Processor:** `Processor % Processor Time`、`Processor % Idle Time`、`Processor % Interrupt Time` **LogicalDisk:** `LogicalDisk % Free Space` **PhysicalDisk:** `PhysicalDisk % Disk Time`、`PhysicalDisk Disk Write Bytes/sec`、`PhysicalDisk Disk Read Bytes/sec`、`PhysicalDisk Disk Writes/sec`、`PhysicalDisk Disk Reads/sec` **Memory:** `Memory % Committed Bytes In Use` **Network Interface:** `Network Interface Bytes Sent/sec`、`Network Interface Bytes Received/sec`、`Network Interface Packets Sent/sec`、`Network Interface Packets Received/sec` |
| **アドバンスト** | **Paging:**`Paging File % Usage` **Processor:** `Processor % Processor Time`、`Processor % Idle Time`、`Processor % Interrupt Time`、`Processor % User Time` **LogicalDisk:** `LogicalDisk % Free Space` **PhysicalDisk:** `PhysicalDisk % Disk Time`、`PhysicalDisk Disk Write Bytes/sec`、`PhysicalDisk Disk Read Bytes/sec`、`PhysicalDisk Disk Writes/sec`、`PhysicalDisk Disk Reads/sec` **Memory:** `Memory % Committed Bytes In Use` **Network Interface:** `Network Interface Bytes Sent/sec`、`Network Interface Bytes Received/sec`、`Network Interface Packets Sent/sec`、`Network Interface Packets Received/sec` **TCP:** `TCPv4 Connections Established`、 `TCPv6 Connections Established` |
# 設定ファイルの例
**基本的なシステムメトリクスの設定**
```
{
"agent": {
"metrics_collection_interval": 60,
"region": "us-east-1"
},
"metrics": {
"namespace": "MySystem",
"metrics_collected": {
"cpu": {
"resources": ["*"],
"measurement": ["usage_active", "usage_system", "usage_user"]
},
"mem": {
"measurement": ["used_percent"]
},
"disk": {
"resources": ["/"],
"measurement": ["used_percent"]
}
},
"append_dimensions": {
"InstanceId": "${aws:InstanceId}"
}
}
}
```
**ウェブサーバーモニタリングの設定**
```
{
"agent": {
"metrics_collection_interval": 60,
"region": "us-east-1"
},
"metrics": {
"namespace": "WebServer",
"metrics_collected": {
"cpu": {
"resources": ["*"],
"measurement": ["usage_active"]
},
"mem": {
"measurement": ["used_percent"]
},
"net": {
"resources": ["eth0"],
"measurement": ["bytes_sent", "bytes_recv"]
}
}
},
"logs": {
"logs_collected": {
"files": {
"collect_list": [
{
"file_path": "/var/log/apache2/access.log",
"log_group_name": "apache-access-logs",
"log_stream_name": "{instance_id}-access"
},
{
"file_path": "/var/log/apache2/error.log",
"log_group_name": "apache-error-logs",
"log_stream_name": "{instance_id}-error"
}
]
}
}
}
}
```
**データベースサーバーの設定**
```
{
"agent": {
"metrics_collection_interval": 30,
"region": "us-east-1"
},
"metrics": {
"namespace": "DatabaseServer",
"metrics_collected": {
"cpu": {
"resources": ["*"],
"measurement": ["usage_active", "usage_iowait"]
},
"mem": {
"measurement": ["used_percent", "available_percent"]
},
"disk": {
"resources": ["/", "/data"],
"measurement": ["used_percent", "inodes_free"]
},
"diskio": {
"resources": ["*"],
"measurement": ["read_bytes", "write_bytes", "io_time"]
}
},
"append_dimensions": {
"InstanceId": "${aws:InstanceId}",
"InstanceType": "${aws:InstanceType}",
"AutoScalingGroupName": "${aws:AutoScalingGroupName}"
}
}
}
```
## 複数の CloudWatch エージェント設定ファイルを作成する
Linux サーバーと Windows サーバーの両方で、複数の設定ファイルを使用するように CloudWatch エージェントを設定できます。例えば、インフラストラクチャ内のすべてのサーバーから常に収集する一連のメトリクス、ログ、およびトレースを収集する共通の設定ファイルを使用できます。その後、追加の設定ファイルを使用して、特定のアプリケーションから、または特定の状況でメトリクスを収集することができます。
これを設定するには、まず使用する設定ファイルを作成します。同じサーバー上で一緒に使用される設定ファイルは、異なるファイル名を持つ必要があります。設定ファイルは、サーバー上または Parameter Store に保存できます。
`fetch-config` オプションを使って CloudWatch エージェントを開始し、1 つ目の設定ファイルを指定します。エージェントの実行の 2 つ目の設定ファイルを追加するには、同じコマンドを使用しますが、`append-config` オプションを使います。いずれかの設定ファイルにリストされている、すべてのメトリクス、ログ、トレースが収集されます。次のコマンドは、このシナリオで設定ストアをファイルとして使用した例を示しています。1 行目で `infrastructure.json` 設定ファイルを使ってエージェントを開始し、2 行目で `app.json` 設定ファイルを追加しています。
次のサンプルコマンドは、Linux 用です。
```
/opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -a fetch-config -m ec2 -s -c file:/tmp/infrastructure.json
```
```
/opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -a append-config -m ec2 -s -c file:/tmp/app.json
```
次のコマンドは Windows Server 用です。
```
& "C:\Program Files\Amazon\AmazonCloudWatchAgent\amazon-cloudwatch-agent-ctl.ps1" -a fetch-config -m ec2 -s -c file:"C:\Program Files\Amazon\AmazonCloudWatchAgent\infrastructure.json"
```
```
& "C:\Program Files\Amazon\AmazonCloudWatchAgent\amazon-cloudwatch-agent-ctl.ps1" -a append-config -m ec2 -s -c file:"C:\Program Files\Amazon\AmazonCloudWatchAgent\app.json"
```
次の設定ファイルは、この機能の使用方法の例を示しています。1 つ目の設定ファイルは、インフラストラクチャ内のすべてのサーバーに使用され、2 つ目の設定ファイルは、特定のアプリケーションからのログのみを収集し、そのアプリケーションを実行しているサーバーに追加されています。
**infrastructure.json**
```
{
"metrics": {
"metrics_collected": {
"cpu": {
"resources": [
"*"
],
"measurement": [
"usage_active"
],
"totalcpu": true
},
"mem": {
"measurement": [
"used_percent"
]
}
}
},
"logs": {
"logs_collected": {
"files": {
"collect_list": [
{
"file_path": "/opt/aws/amazon-cloudwatch-agent/logs/amazon-cloudwatch-agent.log",
"log_group_name": "amazon-cloudwatch-agent.log"
},
{
"file_path": "/var/log/messages",
"log_group_name": "/var/log/messages"
}
]
}
}
}
}
```
**app.json**
```
{
"logs": {
"logs_collected": {
"files": {
"collect_list": [
{
"file_path": "/app/app.log*",
"log_group_name": "/app/app.log"
}
]
}
}
}
}
```
設定に追加される設定ファイルは、互いに異なるファイル名を持つ必要があり、また初期の設定ファイルと異なるファイル名を持つ必要があります。エージェントで既に使用されている設定ファイルと同じファイル名の設定ファイルで `append-config` を使用した場合、その append コマンドでは追加は行われず、1 つ目の設定ファイルの情報は上書きされます。これは、同じファイル名の 2 つの設定ファイルが異なるファイルパスにある場合でも同様です。
前の例では、2 つの設定ファイルを使用していますが、エージェント設定に追加できる設定ファイルの数に制限はありません。サーバー上にある設定ファイルと Parameter Store にある設定を混在させることもできます。
# CloudWatch エージェント設定ファイルを手動で作成または編集する
CloudWatch エージェント設定ファイルは、`agent`、`metrics`、`logs`、`traces` の 4 つのセクションを持つ JSON ファイルです。
+ `agent` セクションには、エージェントの全体的な設定に関するフィールドが含まれています。
+ `metrics` セクションでは、収集と CloudWatch への発行に関するカスタムメトリクスを指定します。ログを収集するためだけにエージェントを使用している場合は、ファイルから `metrics` セクションを省略できます。
+ `logs` セクションでは、CloudWatch Logs に発行されるログファイルを指定します。サーバーで Windows Server が実行されている場合、これには Windows イベントログからのイベントが含まれることがあります。
+ `traces` セクションでは、収集されて AWS X-Ray に送信されるトレースのソースを指定します。
このセクションでは、CloudWatch エージェント設定ファイルの構造とフィールドについて説明します。また、この設定ファイルのスキーマ定義を表示することもできます。スキーマ定義は、Linux サーバーでは `installation-directory/doc/amazon-cloudwatch-agent-schema.json`、Windows Server を実行しているサーバーでは `installation-directory/amazon-cloudwatch-agent-schema.json` にあります。
エージェント設定ファイルを手動で作成または編集する場合は、任意の名前を付けることができます。トラブルシューティングを簡単にするため、Linux サーバーでは、`/opt/aws/amazon-cloudwatch-agent/etc/cloudwatch-agent.json`、Windows Server を実行しているサーバーでは、`$Env:ProgramData\Amazon\AmazonCloudWatchAgent\amazon-cloudwatch-agent.json` という名前を付けることをお勧めします。ファイルを作成したら、エージェントをインストールする他のサーバーにそのファイルをコピーできます。
エージェントが起動されると、`/opt/aws/amazon-cloudwatch/etc/amazon-cloudwatch-agent.d` ディレクトリに各設定ファイルのコピーが作成されます。ファイル名のプレフィックスには、設定の原点を示す `file_` (ローカルファイルソースの場合) または `ssm_` (Systems Manager パラメータストアソースの場合) が付きます。
**注記**
CloudWatch エージェントによって収集されたメトリクス、ログ、トレースには料金が発生します。料金の詳細については、「[Amazon CloudWatch の料金](https://aws.amazon.com/cloudwatch/pricing)」を参照してください。
## CloudWatch エージェント設定ファイル: Agent セクション
`agent` セクションでは、次のフィールドを含めることができます。ウィザードでは、`agent` セクションは作成されません。代わりに、このセクションは省略されて、このセクションのすべてのフィールドにデフォルト値が使用されます。
+ `metrics_collection_interval` – オプション。この設定ファイルで指定されたすべてのメトリクスが収集される頻度を指定します。この値は、特定の種類のメトリクスで上書きすることができます。
この値は数秒で指定されます。例えば、10 と設定するとメトリクスが 10 秒ごとに収集されるようになり、300 と設定するとメトリクスが 5 分ごとに収集されように指定されます。
この値を 60 秒未満に設定した場合、各メトリクスは高解像度メトリクスとして収集されます。高解像度メトリクスの詳細については、「[高解像度のメトリクス](publishingMetrics.md#high-resolution-metrics)」を参照してください。
デフォルト値は 60 です。
+ `region` – Amazon EC2 インスタンスを監視しているときに CloudWatch エンドポイントに使用するリージョンを指定します。収集されたメトリクスは、このリージョン (`us-west-1` など) に送信されます。このフィールドを省略すると、エージェントは Amazon EC2 インスタンスが配置されているリージョンにメトリクスを送信します。
オンプレミスサーバーをモニターリングしている場合、このフィールドは使用されず、エージェントは `AmazonCloudWatchAgent` 設定ファイルの AWS プロファイルからリージョンを読み取ります。
+ `credentials` – 異なる AWS アカウントにメトリクス、ログ、トレースを送信する際に使用する IAM ロールを指定します。指定した場合、このフィールドには 1 つのパラメータ `role_arn` が含まれています。
+ `role_arn` – 異なる AWS アカウントにメトリクス、ログ、トレースを送信する際の認証用 IAM ロールの Amazon リソースネーム (ARN) を指定します。詳細については、「[別のアカウントへのメトリクス、ログ、トレースの送信](CloudWatch-Agent-common-scenarios.md#CloudWatch-Agent-send-to-different-AWS-account)」を参照してください。
+ `debug` - オプション。デバッグログメッセージを使用して CloudWatch を実行することを指定します。デフォルト値は `false` です。
+ `aws_sdk_log_level` - オプション。バージョン 1.247350.0 以降の CloudWatch エージェントでのみサポートされます。
このフィールドを指定すると、エージェントが AWS SDK エンドポイントに対してログ記録を実行できるようになります。このフィールドの値には、次のオプションうち 1 つまたは複数を含めることができます。複数のオプションは、`|` 文字で区切ります。
+ `LogDebug`
+ `LogDebugWithSigning`
+ `LogDebugWithHTTPBody`
+ `LogDebugRequestRetries`
+ `LogDebugWithEventStreamBody`
これらのオプションの詳細については、「[LogLevelType](https://docs.aws.amazon.com/sdk-for-go/api/aws/#LogLevelType)」を参照してください。
+ `logfile` – CloudWatch エージェントがログメッセージを書き込む場所を指定します。空の文字列を指定すると、ログは stderr に書き込まれます。このオプションを指定しない場合、デフォルトの場所は次のようになります。
+ Linux: `/opt/aws/amazon-cloudwatch-agent/logs/amazon-cloudwatch-agent.log`
+ Windows Server: `c:\\ProgramData\\Amazon\\CloudWatchAgent\\Logs\\amazon-cloudwatch-agent.log`
CloudWatch エージェントで作成されるログファイルは自動的に更新されます。ログファイルは、サイズが 100 MB に達すると、更新されます。エージェントは、更新したログファイルを最大 7 日間保持します。また、更新したバックアップログファイルを最大 5 つまで保持します。バックアップログファイルのファイル名にはタイムスタンプが追加されます。このタイムスタンプは、ファイルの更新日時 (例: `amazon-cloudwatch-agent-2018-06-08T21-01-50.247.log.gz`) を示します。
+ `omit_hostname` - オプション。デフォルトでは、`append_dimensions` セクション内の `metrics` フィールドを使用している場合を除き、ホスト名はエージェントによって収集されるメトリクスのディメンションとして発行されます。`omit_hostname ` を `true` に設定すると、`append_dimensions` を使用していなくても、ホスト名がディメンションとして発行されません。デフォルト値は `false` です。
+ `run_as_user` - オプション。CloudWatch エージェントを実行するために使用するユーザーを指定します。このパラメータを指定しないと、ルートユーザーが使用されます。このオプションは、Linux サーバーでのみ有効です。
このオプションを使用する場合は、CloudWatch エージェントを起動する前にユーザーが存在している必要があります。詳細については、「[CloudWatch エージェントの別のユーザーとしての実行](CloudWatch-Agent-common-scenarios.md#CloudWatch-Agent-run-as-user)」を参照してください。
+ `user_agent` - オプション。CloudWatch エージェントによって CloudWatch バックエンドへの API 呼び出しに使用される `user-agent` 文字列を指定します。デフォルト値は、エージェントのバージョン、エージェントのコンパイルに使用された Go プログラミング言語のバージョン、ランタイムオペレーティングシステムおよびアーキテクチャ、構築時間、有効にするプラグインで構成される文字列です。
+ `usage_data` - オプション。デフォルトでは、CloudWatch エージェントは、メトリクスまたはログを CloudWatch に発行するたびに、自らに関するヘルスおよびパフォーマンスのデータを CloudWatch に送信します。このデータには費用はかかりません。`usage_data` に `false` を指定することで、エージェントがこのデータを送信しないようにできます。このパラメータを省略すると、デフォルトの `true` が使用され、エージェントはヘルスおよびパフォーマンスのデータを送信します。
この値を `false` に設定した場合、有効にするにはエージェントを停止して再起動する必要があります。
+ `service.name` - オプション。エンティティに入力して[関連するテレメトリを検索](ExploreRelated.md)するために使用されるサービス名を指定します。
+ `deployment.environment` - オプション。エンティティに入力して[関連するテレメトリを検索](ExploreRelated.md)するために使用される環境名を指定します。
+ `use_dualstack_endpoint` - オプション。これが `true` の場合、CloudWatch エージェントはすべての API コールに[デュアルスタックエンドポイント](https://docs.aws.amazon.com/general/latest/gr/rande.html#dual-stack-endpoints)を使用します。
`agent` セクションの例を以下に示します。
```
"agent": {
"metrics_collection_interval": 60,
"region": "us-west-1",
"logfile": "/opt/aws/amazon-cloudwatch-agent/logs/amazon-cloudwatch-agent.log",
"debug": false,
"run_as_user": "cwagent"
}
```
## CloudWatch エージェント設定ファイル: Metrics セクション
### Linux および Windows の共通のフィールド
Linux または Windows Server を実行しているサーバーでは、`metrics` セクションに次のフィールドが含まれています。
+ `namespace` - オプション。エージェントによって収集されるメトリクスに使用する名前空間。デフォルト値は `CWAgent` です。最大長は 255 文字です。次に例を示します。
```
{
"metrics": {
"namespace": "Development/Product1Metrics",
......
},
}
```
+ `append_dimensions` - オプション。エージェントによって収集されたメトリクスに Amazon EC2 メトリクスのディメンションを追加します。これにより、エージェントはホスト名をディメンションとして発行しません。
`append_dimensions` で唯一サポートされるキーと値のペアは、次のリストに示されています。他のキーと値のペアは無視されます。エージェントは、次のリストに示されているとおりに、これらのキーと値のペアをサポートします。キーの値を変更して、異なるディメンション名を発行することはできません。
+ `"ImageId":"${aws:ImageId}"` は、インスタンスの AMI ID を `ImageId` ディメンションの値として設定します。
+ `"InstanceId":"${aws:InstanceId}"` は、インスタンスのインスタンス ID を `InstanceId` ディメンションの値として設定します。
+ `"InstanceType":"${aws:InstanceType}"` は、インスタンスのインスタンスタイプを `InstanceType` ディメンションの値として設定します。
+ `"AutoScalingGroupName":"${aws:AutoScalingGroupName}"` は、インスタンスの Auto Scaling グループ名を `AutoScalingGroupName` ディメンションの値として設定します。
任意のキーと値のペアを持つメトリクスにディメンションを追加する場合は、その特定のタイプのメトリクスのフィールドの `append_dimensions` パラメータを使用します。
Amazon EC2 メタデータに依存する値を指定し、プロキシーを使用する場合は、サーバーが Amazon EC2 のエンドポイントにアクセスできることを確認する必要があります。これらのエンドポイントの詳細については、「Amazon Web Services 全般のリファレンス」の「[Amazon Elastic Compute Cloud (Amazon EC2)](https://docs.aws.amazon.com/general/latest/gr/rande.html#ec2_region)」を参照してください。
+ `aggregation_dimensions` - オプション。収集されたメトリクスが集計されるディメンションを指定します。例えば、`AutoScalingGroupName` ディメンションでメトリクスをロールアップした場合、各 Auto Scaling グループ内のすべてのインスタンスのメトリクスが集約され、全体として参照できるようになります。
1 つまたは複数のディメンションに沿ってメトリクスをロールアップすることができます。たとえば、`[["InstanceId"], ["InstanceType"], ["InstanceId","InstanceType"]]` を指定すると、インスタンス ID 単独、インスタンスタイプ単独、および 2 つのディメンションの組み合わせのメトリクスが集約されます。
`[]` を指定することにより、すべてのディメンションを無視して、すべてのメトリクスを 1 つのコレクションにロールアップすることもできます。
+ `endpoint_override` – エージェントがメトリクスを送信するエンドポイントとして使用する FIPS エンドポイントまたはプライベートリンクを指定します。これを指定してプライベートリンクを設定すると、Amazon VPC エンドポイントにメトリクスを送信できます。詳細については、「[Amazon VPC とは](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html)」を参照してください。
`endpoint_override` の値は URL 文字列であることが必要です。
たとえば、設定ファイルのメトリクスセクションの次の部分は、メトリクスの送信時に VPC エンドポイントを使用するようにエージェントを設定します。
```
{
"metrics": {
"endpoint_override": "vpce-XXXXXXXXXXXXXXXXXXXXXXXXX.monitoring.us-east-1.vpce.amazonaws.com",
......
},
}
```
+ `metrics_collected` – 必須。収集するメトリクス (`StatsD` または `collectd` を介して収集されたカスタムメトリクスを含む) を指定します。このセクションには、いくつかのサブセクションがあります。
この `metrics_collected` セクションの内容は、この設定ファイルが Linux を実行しているサーバー用か Windows Server を実行しているサーバー用かによって異なります。
+ `metrics_destinations` - オプション。`metrics_collected` で定義されたすべてのメトリクスに 1 つ以上の送信先を指定します。ここで指定された場合、`cloudwatch` のデフォルトの送信先が上書きされます。
+ `cloudwatch` – Amazon CloudWatch。
+ `amp` – Amazon Managed Service for Prometheus
+ `workspace_id` – Amazon Managed Service for Prometheus ワークスペースに対応する ID。
```
{
"metrics": {
"metrics_destinations": {
"cloudwatch": {},
"amp": {
"workspace_id": "ws-abcd1234-ef56-7890-ab12-example"
}
}
}
}
```
+ `force_flush_interval` – メトリクスがサーバーに送信されるまでにメモリバッファ内に残留する最大時間を秒単位で指定します。この設定にかかわらず、バッファ内のメトリクスのサイズが 1 MB に達するか、異なるタイプのメトリクスの数が 1,000 個に達すると、メトリクスは即座にサーバーに送信されます。
デフォルト値は 60 です。
+ `credentials` – 異なるアカウントにメトリクスを送信する際に使用する IAM ロールを指定します。指定した場合、このフィールドには 1 つのパラメータ `role_arn` が含まれています。
+ `role_arn` – 異なるアカウントにメトリクスを送信する際の認証用の IAM ロールの ARN を指定します。詳細については、「[別のアカウントへのメトリクス、ログ、トレースの送信](CloudWatch-Agent-common-scenarios.md#CloudWatch-Agent-send-to-different-AWS-account)」を参照してください。ここで指定した値は、設定ファイルの `role_arn` セクションで指定された `agent` よりも優先されます (存在する場合)。
+ `service.name` - オプション。エンティティに入力して[関連するテレメトリを検索](ExploreRelated.md)するために使用されるサービス名を指定します。
+ `deployment.environment` - オプション。エンティティに入力して[関連するテレメトリを検索](ExploreRelated.md)するために使用される環境名を指定します。
### Linux のセクション
Linux を実行しているサーバーでは、設定ファイルの `metrics_collected` セクションに次のフィールドを含めることもできます。
これらのフィールドの多くには、そのリソースに対して収集するメトリクスをリストする `measurement` セクションを含めることができます。これらの `measurement` セクションでは、`swap_used` などの完全なメトリクス名、またはリソースのタイプに追加されるメトリクス名の一部のみを指定できます。たとえば、`reads` セクションの `measurement` セクションで `diskio` を指定すると、`diskio_reads` メトリクスが収集されます。
+ `collectd` - オプション。`collectd` プロトコルを使用してカスタムメトリクスを取得することを指定します。`collectd` ソフトウェアを使用して CloudWatch エージェントにメトリクスを送信します。collectd で使用できる設定オプションの詳細については、「[collectd を使用してカスタムメトリクスを取得する](CloudWatch-Agent-custom-metrics-collectd.md)」を参照してください。
+ `cpu` - オプション。収集する CPU メトリクスを指定します。このセクションは、Linux インスタンスでのみ有効です。収集する CPU メトリクスの `resources` フィールドと `totalcpu` フィールドを少なくとも 1 つ含める必要があります。このセクションには、次のフィールドを含めることができます。
+ `drop_original_metrics` - オプション。`metrics` セクションの `aggregation_dimensions` フィールドを使用してメトリクスを集計結果にロールアップしている場合、デフォルトでは、エージェントは集計メトリクスと、ディメンションの値ごとに分離された元のメトリクスの両方を送信します。元のメトリクスを CloudWatch に送信したくない場合は、メトリクスのリストを使用してこのパラメータを指定できます。このパラメータとともに指定されたメトリクスには、CloudWatch にレポートされるディメンションごとのメトリクスがありません。代わりに、集計されたメトリクスのみがレポートされます。これにより、エージェントが収集するメトリクスの数が減り、コストが削減されます。
+ `resources` - オプション。このフィールドの値を `*` に指定すると、CPU ごとのメトリクスが収集されます。許容されている値は `*` のみです。
+ `totalcpu` - オプション。すべての CPU コア間で集計された cpu メトリクスを報告するかどうかを指定します。デフォルトは true です。
+ `measurement` – 収集する cpu メトリクスの配列を指定します。利用できる値は、`time_active`、`time_guest`、`time_guest_nice`、`time_idle`、`time_iowait`、`time_irq`、`time_nice`、`time_softirq`、`time_steal`、`time_system`、`time_user`、`usage_active`、`usage_guest`、`usage_guest_nice`、`usage_idle`、`usage_iowait`、`usage_irq`、`usage_nice`、`usage_softirq`、`usage_steal`、`usage_system`、および `usage_user` です。このフィールドは、`cpu` を含めた場合にのみ必要です。
デフォルトでは、`cpu_usage_*` メトリクスの単位は `Percent` であり、`cpu_time_*` メトリクスには単位がありません。
各メトリクスのエントリでは、必要に応じて次のいずれかまたは両方を指定できます。
+ `rename` – このメトリクスに別の名前を指定します。
+ `unit` – メトリクスの `None` のデフォルト単位を上書きして、このメトリクスに使用する単位を指定します。指定する単位は、「[MetricDatum](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_MetricDatum.html)」の `Unit` に関する説明にリストされている有効な CloudWatch メトリクス単位でなければなりません。
+ `metrics_collection_interval` - オプション。設定ファイルの `metrics_collection_interval` セクションで指定されたグローバルな `agent` を上書きして、cpu メトリクスを収集する頻度を指定します。
この値は数秒で指定されます。例えば、10 と設定するとメトリクスが 10 秒ごとに収集されるようになり、300 と設定するとメトリクスが 5 分ごとに収集されように指定されます。
この値を 60 秒未満に設定した場合、各メトリクスは高解像度メトリクスとして収集されます。高解像度メトリクスの詳細については、「[高解像度のメトリクス](publishingMetrics.md#high-resolution-metrics)」を参照してください。
+ `append_dimensions` - オプション。cpu メトリクスにのみ使用する追加のディメンション。このフィールドを指定した場合、エージェントによって収集されるすべてのタイプのメトリクスに使用されるグローバルフィールド `append_dimensions` で指定されたディメンションに加えて使用されます。
+ `disk` - オプション。収集する disk メトリクスを指定します。マウントされたボリュームのメトリクスのみを収集します。このセクションは、Linux インスタンスでのみ有効です。このセクションには、次のフィールドを含めることができます。
+ `drop_original_metrics` - オプション。`metrics` セクションの `aggregation_dimensions` フィールドを使用してメトリクスを集計結果にロールアップしている場合、デフォルトでは、エージェントは集計メトリクスと、ディメンションの値ごとに分離された元のメトリクスの両方を送信します。元のメトリクスを CloudWatch に送信したくない場合は、メトリクスのリストを使用してこのパラメータを指定できます。このパラメータとともに指定されたメトリクスには、CloudWatch にレポートされるディメンションごとのメトリクスがありません。代わりに、集計されたメトリクスのみがレポートされます。これにより、エージェントが収集するメトリクスの数が減り、コストが削減されます。
+ `resources` - オプション。ディスクのマウントポイントの配列を指定します。このフィールドは、リストされているマウントポイントのみから CloudWatch がメトリクスを収集するように制限します。値として `*` を指定すると、すべてのマウントポイントからメトリクスを収集できます。デフォルト値を使用すると、すべてのマウントポイントからメトリクスが収集されます。
+ `measurement` – 収集する disk メトリクスの配列を指定します。指定できる値は `free`、`total`、`used`、`used_percent`、`inodes_free`、`inodes_used`､および `inodes_total` です。このフィールドは、`disk` を含めた場合にのみ必要です。
**注記**
`disk` メトリクスには `Partition` のディメンションがあります。つまり、生成されるカスタムメトリクスの数は、インスタンスに関連付けられたパーティションの数によって異なります。ディスクパーティションの数は、使用している AMI とサーバーにアタッチする Amazon EBS ボリュームの数によって異なります。
各 `disk` メトリクスのデフォルトの単位を確認するには、「[Linux および macOS インスタンスで CloudWatch エージェントにより収集されるメトリクス](metrics-collected-by-CloudWatch-agent.md#linux-metrics-enabled-by-CloudWatch-agent)」を参照してください。
各メトリクスのエントリでは、必要に応じて次のいずれかまたは両方を指定できます。
+ `rename` – このメトリクスに別の名前を指定します。
+ `unit` – メトリクスの `None` の `None` のデフォルト単位を上書きして、このメトリクスに使用する単位を指定します。指定する単位は、「[MetricDatum](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_MetricDatum.html)」の `Unit` に関する説明にリストされている有効な CloudWatch メトリクス単位でなければなりません。
+ `ignore_file_system_types` – disk メトリクスを収集するときに除外するファイルシステムのタイプを指定します。有効な値は、`sysfs`、`devtmpfs` などです。
+ `drop_device` – これを `true` に設定すると、`Device` はディスクメトリクスのディメンションとして含まれません。
`Device` がディメンションとして使用されないようにすることは、Nitro システムを使用するインスタンスで役立ちます。これらのインスタンスでは、インスタンスの再起動時にディスクマウントごとにデバイス名が変更されるためです。これにより、メトリクスに整合性のないデータが発生し、これらのメトリクスに基づくアラームが `INSUFFICIENT DATA` 状態になる可能性があります。
デフォルト: `false`。
+ `metrics_collection_interval` - オプション。設定ファイルの `metrics_collection_interval` セクションで指定されたグローバルな `agent` を上書きして、disk メトリクスを収集する頻度を指定します。
この値は数秒で指定されます。
この値を 60 秒未満に設定した場合、各メトリクスは高解像度メトリクスとして収集されます。詳細については、「[高解像度のメトリクス](publishingMetrics.md#high-resolution-metrics)」を参照してください。
+ `append_dimensions` - オプション。ディスクメトリクス専用の追加のディメンションとして使用するキーと値のペアを指定します。このフィールドを指定した場合、エージェントにより収集されるすべてのタイプのメトリクスに使用される `append_dimensions` フィールドで指定されたディメンションに加えて使用されます。
使用できるキーと値のペアは次のとおりです。他のカスタムのキーと値のペアを指定することもできます。
+ `"VolumeId":"${aws:VolumeId}"` は、ブロックデバイスディスクメトリクスに `VolumeId` ディメンションを追加します。これは、Amazon EBS ボリュームの場合には Amazon EBS ボリューム ID になります。EC2 インスタンスストアの場合にはデバイスシリアルになります。これを使用するには、`drop_device` パラメータを `false` に設定する必要があります。
+ `diskio` - オプション。収集する disk i/o メトリクスを指定します。このセクションは、Linux インスタンスでのみ有効です。このセクションには、次のフィールドを含めることができます。
+ `drop_original_metrics` - オプション。`metrics` セクションの `aggregation_dimensions` フィールドを使用してメトリクスを集計結果にロールアップしている場合、デフォルトでは、エージェントは集計メトリクスと、ディメンションの値ごとに分離された元のメトリクスの両方を送信します。元のメトリクスを CloudWatch に送信したくない場合は、メトリクスのリストを使用してこのパラメータを指定できます。このパラメータとともに指定されたメトリクスには、CloudWatch にレポートされるディメンションごとのメトリクスがありません。代わりに、集計されたメトリクスのみがレポートされます。これにより、エージェントが収集するメトリクスの数が減り、コストが削減されます。
+ `resources` - オプション。デバイスの配列を指定した場合、CloudWatch はそれらのデバイスからのみメトリクスを収集します。それ以外の場合、すべてのデバイスのメトリクスが収集されます。値として \$1 を指定し、すべてのデバイスからメトリクスを収集することもできます。
+ `measurement` – Amazon EC2 AWS インスタンスにアタッチされた Amazon EBS ボリュームとインスタンスストアボリュームに対して収集される diskio および NVMe ドライバーメトリクスの配列を指定します。指定できる diskio 値は `reads`、`writes`、`read_bytes`、`write_bytes`、`read_time`、`write_time`、`io_time`、および `iops_in_progress` です。Amazon EBS ボリュームと Amazon EC2 インスタンスストアボリュームの NVMe ドライバーメトリクスのリストについては、「[Amazon EBS NVMe ドライバーメトリクスを収集する](Container-Insights-metrics-EBS-Collect.md)」および「[Amazon EC2 インスタンスストアボリューム NVMe ドライバーメトリクスを収集する](Container-Insights-metrics-instance-store-Collect.md)」を参照してください。このフィールドは、`diskio` を含めた場合にのみ必要です。
各メトリクスのエントリでは、必要に応じて次のいずれかまたは両方を指定できます。
+ `rename` – このメトリクスに別の名前を指定します。
+ `unit` – メトリクスの `None` の `None` のデフォルト単位を上書きして、このメトリクスに使用する単位を指定します。指定する単位は、「[MetricDatum](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_MetricDatum.html)」の `Unit` に関する説明にリストされている有効な CloudWatch メトリクス単位でなければなりません。
デフォルトの単位とメトリクスの説明については、「[Amazon EBS NVMe ドライバーメトリクスを収集する](Container-Insights-metrics-EBS-Collect.md)」を参照してください。
+ `metrics_collection_interval` - オプション。設定ファイルの `metrics_collection_interval` セクションで指定されたグローバルな `agent` を上書きして、diskio メトリクスを収集する頻度を指定します。
この値は数秒で指定されます。
この値を 60 秒未満に設定した場合、各メトリクスは高解像度メトリクスとして収集されます。高解像度メトリクスの詳細については、「[高解像度のメトリクス](publishingMetrics.md#high-resolution-metrics)」を参照してください。
+ `append_dimensions` - オプション。diskio メトリクスにのみ使用する追加のディメンション。このフィールドを指定した場合、エージェントにより収集されるすべてのタイプのメトリクスに使用される `append_dimensions` フィールドで指定されたディメンションに加えて使用されます。
+ `swap` - オプション。収集するスワップメモリメトリクスを指定します。このセクションは、Linux インスタンスでのみ有効です。このセクションには、次のフィールドを含めることができます。
+ `drop_original_metrics` - オプション。`metrics` セクションの `aggregation_dimensions` フィールドを使用してメトリクスを集計結果にロールアップしている場合、デフォルトでは、エージェントは集計メトリクスと、ディメンションの値ごとに分離された元のメトリクスの両方を送信します。元のメトリクスを CloudWatch に送信したくない場合は、メトリクスのリストを使用してこのパラメータを指定できます。このパラメータとともに指定されたメトリクスには、CloudWatch にレポートされるディメンションごとのメトリクスがありません。代わりに、集計されたメトリクスのみがレポートされます。これにより、エージェントが収集するメトリクスの数が減り、コストが削減されます。
+ `measurement` – 収集する swap メトリクスの配列を指定します。指定できる値は `free`、`used`、および `used_percent` です。このフィールドは、`swap` を含めた場合にのみ必要です。
各 `swap` メトリクスのデフォルトの単位を確認するには、「[Linux および macOS インスタンスで CloudWatch エージェントにより収集されるメトリクス](metrics-collected-by-CloudWatch-agent.md#linux-metrics-enabled-by-CloudWatch-agent)」を参照してください。
各メトリクスのエントリでは、必要に応じて次のいずれかまたは両方を指定できます。
+ `rename` – このメトリクスに別の名前を指定します。
+ `unit` – メトリクスの `None` の `None` のデフォルト単位を上書きして、このメトリクスに使用する単位を指定します。指定する単位は、「[MetricDatum](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_MetricDatum.html)」の `Unit` に関する説明にリストされている有効な CloudWatch メトリクス単位でなければなりません。
+ `metrics_collection_interval` - オプション。設定ファイルの `metrics_collection_interval` セクションで指定されたグローバルな `agent` を上書きして、swap メトリクスを収集する頻度を指定します。
この値は数秒で指定されます。
この値を 60 秒未満に設定した場合、各メトリクスは高解像度メトリクスとして収集されます。高解像度メトリクスの詳細については、「[高解像度のメトリクス](publishingMetrics.md#high-resolution-metrics)」を参照してください。
+ `append_dimensions` - オプション。swap メトリクスにのみ使用する追加のディメンション。このフィールドを指定した場合、エージェントにより収集されるすべてのタイプのメトリクスに使用されるグローバル `append_dimensions` フィールドで指定されたディメンションに加えて使用されます。高解像度メトリクスとして収集されます。
+ `mem` - オプション。収集するメモリメトリクスを指定します。このセクションは、Linux インスタンスでのみ有効です。このセクションには、次のフィールドを含めることができます。
+ `drop_original_metrics` - オプション。`metrics` セクションの `aggregation_dimensions` フィールドを使用してメトリクスを集計結果にロールアップしている場合、デフォルトでは、エージェントは集計メトリクスと、ディメンションの値ごとに分離された元のメトリクスの両方を送信します。元のメトリクスを CloudWatch に送信したくない場合は、メトリクスのリストを使用してこのパラメータを指定できます。このパラメータとともに指定されたメトリクスには、CloudWatch にレポートされるディメンションごとのメトリクスがありません。代わりに、集計されたメトリクスのみがレポートされます。これにより、エージェントが収集するメトリクスの数が減り、コストが削減されます。
+ `measurement` – 収集する memory メトリクスの配列を指定します。指定できる値は `active`、`available`、`available_percent`、`buffered`、`cached`、`free`、`inactive`、`shared`、`total`、`used`、`used_percent` です。このフィールドは、`mem` を含めた場合にのみ必要です。
各 `mem` メトリクスのデフォルトの単位を確認するには、「[Linux および macOS インスタンスで CloudWatch エージェントにより収集されるメトリクス](metrics-collected-by-CloudWatch-agent.md#linux-metrics-enabled-by-CloudWatch-agent)」を参照してください。
各メトリクスのエントリでは、必要に応じて次のいずれかまたは両方を指定できます。
+ `rename` – このメトリクスに別の名前を指定します。
+ `unit` – メトリクスの `None` のデフォルト単位を上書きして、このメトリクスに使用する単位を指定します。指定する単位は、「[MetricDatum](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_MetricDatum.html)」の `Unit` に関する説明にリストされている有効な CloudWatch メトリクス単位でなければなりません。
+ `metrics_collection_interval` - オプション。設定ファイルの `metrics_collection_interval` セクションで指定されたグローバルな `agent` を上書きして、mem メトリクスを収集する頻度を指定します。
この値は数秒で指定されます。
この値を 60 秒未満に設定した場合、各メトリクスは高解像度メトリクスとして収集されます。高解像度メトリクスの詳細については、「[高解像度のメトリクス](publishingMetrics.md#high-resolution-metrics)」を参照してください。
+ `append_dimensions` - オプション。mem メトリクスにのみ使用する追加のディメンション。このフィールドを指定した場合、エージェントによって収集されるすべてのタイプのメトリクスに使用される `append_dimensions` フィールドで指定されたディメンションに加えて使用されます。
+ `net` - オプション。収集するネットワーキングメトリクスを指定します。このセクションは、Linux インスタンスでのみ有効です。このセクションには、次のフィールドを含めることができます。
+ `drop_original_metrics` - オプション。`metrics` セクションの `aggregation_dimensions` フィールドを使用してメトリクスを集計結果にロールアップしている場合、デフォルトでは、エージェントは集計メトリクスと、ディメンションの値ごとに分離された元のメトリクスの両方を送信します。元のメトリクスを CloudWatch に送信したくない場合は、メトリクスのリストを使用してこのパラメータを指定できます。このパラメータとともに指定されたメトリクスには、CloudWatch にレポートされるディメンションごとのメトリクスがありません。代わりに、集計されたメトリクスのみがレポートされます。これにより、エージェントが収集するメトリクスの数が減り、コストが削減されます。
+ `resources` - オプション。ネットワークインターフェイスの配列を指定した場合、CloudWatch はそれらのインターフェイスからのみメトリクスを収集します。それ以外の場合、すべてのデバイスのメトリクスが収集されます。また、値として `*` を指定し、すべてのインターフェイスからメトリクスを収集することもできます。
+ `measurement` – 収集する networking メトリクスの配列を指定します。指定できる値は `bytes_sent`、`bytes_recv`、`drop_in`、`drop_out`、`err_in`、`err_out`､`packets_sent`、および `packets_recv` です。このフィールドは、`net` を含めた場合にのみ必要です。
各 `net` メトリクスのデフォルトの単位を確認するには、「[Linux および macOS インスタンスで CloudWatch エージェントにより収集されるメトリクス](metrics-collected-by-CloudWatch-agent.md#linux-metrics-enabled-by-CloudWatch-agent)」を参照してください。
各メトリクスのエントリでは、必要に応じて次のいずれかまたは両方を指定できます。
+ `rename` – このメトリクスに別の名前を指定します。
+ `unit` – メトリクスの `None` のデフォルト単位を上書きして、このメトリクスに使用する単位を指定します。指定する単位は、「[MetricDatum](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_MetricDatum.html)」の `Unit` に関する説明にリストされている有効な CloudWatch メトリクス単位でなければなりません。
+ `metrics_collection_interval` - オプション。設定ファイルの `metrics_collection_interval` セクションで指定されたグローバルな `agent` を上書きして、net メトリクスを収集する頻度を指定します。
この値は数秒で指定されます。例えば、10 と設定するとメトリクスが 10 秒ごとに収集されるようになり、300 と設定するとメトリクスが 5 分ごとに収集されように指定されます。
この値を 60 秒未満に設定した場合、各メトリクスは高解像度メトリクスとして収集されます。高解像度メトリクスの詳細については、「[高解像度のメトリクス](publishingMetrics.md#high-resolution-metrics)」を参照してください。
+ `append_dimensions` - オプション。net メトリクスにのみ使用する追加のディメンション。このフィールドを指定した場合、エージェントにより収集されるすべてのタイプのメトリクスに使用される `append_dimensions` フィールドで指定されたディメンションに加えて使用されます。
+ `netstat` - オプション。収集する TCP 接続状態と UDP 接続メトリクスを指定します。このセクションは、Linux インスタンスでのみ有効です。このセクションには、次のフィールドを含めることができます。
+ `drop_original_metrics` - オプション。`metrics` セクションの `aggregation_dimensions` フィールドを使用してメトリクスを集計結果にロールアップしている場合、デフォルトでは、エージェントは集計メトリクスと、ディメンションの値ごとに分離された元のメトリクスの両方を送信します。元のメトリクスを CloudWatch に送信したくない場合は、メトリクスのリストを使用してこのパラメータを指定できます。このパラメータとともに指定されたメトリクスには、CloudWatch にレポートされるディメンションごとのメトリクスがありません。代わりに、集計されたメトリクスのみがレポートされます。これにより、エージェントが収集するメトリクスの数が減り、コストが削減されます。
+ `measurement` – 収集する netstat メトリクスの配列を指定します。指定できる値は `tcp_close`、`tcp_close_wait`、`tcp_closing`、`tcp_established`、`tcp_fin_wait1`、`tcp_fin_wait2`、`tcp_last_ack`、`tcp_listen`、`tcp_none`、`tcp_syn_sent`、`tcp_syn_recv`、`tcp_time_wait`、および `udp_socket` です。このフィールドは、`netstat` を含めた場合にのみ必要です。
各 `netstat` メトリクスのデフォルトの単位を確認するには、「[Linux および macOS インスタンスで CloudWatch エージェントにより収集されるメトリクス](metrics-collected-by-CloudWatch-agent.md#linux-metrics-enabled-by-CloudWatch-agent)」を参照してください。
各メトリクスのエントリでは、必要に応じて次のいずれかまたは両方を指定できます。
+ `rename` – このメトリクスに別の名前を指定します。
+ `unit` – メトリクスの `None` のデフォルト単位を上書きして、このメトリクスに使用する単位を指定します。指定する単位は、「[MetricDatum](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_MetricDatum.html)」の `Unit` に関する説明にリストされている有効な CloudWatch メトリクス単位でなければなりません。
+ `metrics_collection_interval` - オプション。設定ファイルの `metrics_collection_interval` セクションで指定されたグローバルな `agent` を上書きして、netstat メトリクスを収集する頻度を指定します。
この値は数秒で指定されます。
この値を 60 秒未満に設定した場合、各メトリクスは高解像度メトリクスとして収集されます。高解像度メトリクスの詳細については、「[高解像度のメトリクス](publishingMetrics.md#high-resolution-metrics)」を参照してください。
+ `append_dimensions` - オプション。netstat メトリクスにのみ使用する追加のディメンション。このフィールドを指定した場合、エージェントにより収集されるすべてのタイプのメトリクスに使用される `append_dimensions` フィールドで指定されたディメンションに加えて使用されます。
+ `processes` - オプション。収集するプロセスメトリクスを指定します。このセクションは、Linux インスタンスでのみ有効です。このセクションには、次のフィールドを含めることができます。
+ `drop_original_metrics` - オプション。`metrics` セクションの `aggregation_dimensions` フィールドを使用してメトリクスを集計結果にロールアップしている場合、デフォルトでは、エージェントは集計メトリクスと、ディメンションの値ごとに分離された元のメトリクスの両方を送信します。元のメトリクスを CloudWatch に送信したくない場合は、メトリクスのリストを使用してこのパラメータを指定できます。このパラメータとともに指定されたメトリクスには、CloudWatch にレポートされるディメンションごとのメトリクスがありません。代わりに、集計されたメトリクスのみがレポートされます。これにより、エージェントが収集するメトリクスの数が減り、コストが削減されます。
+ `measurement` – 収集する processes メトリクスの配列を指定します。指定できる値は `blocked`、`dead`、`idle`、`paging`、`running`、`sleeping`、`stopped`、`total`、`total_threads`、`wait`、`zombies` です。このフィールドは、`processes` を含めた場合にのみ必要です。
すべての `processes` メトリクスで、デフォルトの単位は `None` です。
各メトリクスのエントリでは、必要に応じて次のいずれかまたは両方を指定できます。
+ `rename` – このメトリクスに別の名前を指定します。
+ `unit` – メトリクスの `None` のデフォルト単位を上書きして、このメトリクスに使用する単位を指定します。指定する単位は、「[MetricDatum](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_MetricDatum.html)」の `Unit` に関する説明にリストされている有効な CloudWatch メトリクス単位でなければなりません。
+ `metrics_collection_interval` - オプション。設定ファイルの `metrics_collection_interval` セクションで指定されたグローバルな `agent` を上書きして、processes メトリクスを収集する頻度を指定します。
この値は数秒で指定されます。例えば、10 と設定するとメトリクスが 10 秒ごとに収集されるようになり、300 と設定するとメトリクスが 5 分ごとに収集されように指定されます。
この値を 60 秒未満に設定した場合、各メトリクスは高解像度メトリクスとして収集されます。詳細については、「[高解像度のメトリクス](publishingMetrics.md#high-resolution-metrics)」を参照してください。
+ `append_dimensions` - オプション。process メトリクスにのみ使用する追加のディメンション。このフィールドを指定した場合、エージェントにより収集されるすべてのタイプのメトリクスに使用される `append_dimensions` フィールドで指定されたディメンションに加えて使用されます。
+ `nvidia_gpu` - オプション。収集する NVIDIA GPU メトリクスを指定します。このセクションは、NVIDIA GPU アクセラレーターで設定され、NVIDIA System Management Interface (nvidia-smi) がインストールされているホスト上の Linux インスタンスについてのみ有効です。
収集される NVIDIA GPU メトリクスには、他のアクセラレータータイプ用に収集されるメトリクスと区別するために、`nvidia_smi_` という文字列のプレフィックスが付けられます。このセクションには、次のフィールドを含めることができます。
+ `drop_original_metrics` - オプション。`metrics` セクションの `aggregation_dimensions` フィールドを使用してメトリクスを集計結果にロールアップしている場合、デフォルトでは、エージェントは集計メトリクスと、ディメンションの値ごとに分離された元のメトリクスの両方を送信します。元のメトリクスを CloudWatch に送信したくない場合は、メトリクスのリストを使用してこのパラメータを指定できます。このパラメータとともに指定されたメトリクスには、CloudWatch にレポートされるディメンションごとのメトリクスがありません。代わりに、集計されたメトリクスのみがレポートされます。これにより、エージェントが収集するメトリクスの数が減り、コストが削減されます。
+ `measurement` – 収集する NVIDIA GPU メトリクスの配列を指定します。ここで使用できる値のリストについては、[NVIDIA GPU メトリクスを収集する](CloudWatch-Agent-NVIDIA-GPU.md) の表の **[Metric]** (メトリクス) 列を参照してください。
各メトリクスのエントリでは、必要に応じて次のいずれかまたは両方を指定できます。
+ `rename` – このメトリクスに別の名前を指定します。
+ `unit` – メトリクスの `None` のデフォルト単位を上書きして、このメトリクスに使用する単位を指定します。指定する単位は、「[MetricDatum](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_MetricDatum.html)」の `Unit` に関する説明にリストされている有効な CloudWatch メトリクス単位でなければなりません。
+ `metrics_collection_interval` - オプション。設定ファイルの `agent` セクションで指定されたグローバルな `metrics_collection_interval` を上書きして、NVIDIA GPU メトリクスを収集する頻度を指定します。
+ `jmx` - オプション。インスタンスから Java Management Extensions (JMX) メトリクスを取得することを指定します。このセクションで使用できるパラメータ、ならびに収集できるメトリクスの詳細については、「[Java Management Extensions (JMX) メトリクスの収集](CloudWatch-Agent-JMX-metrics.md)」を参照してください。
+ `otlp` - オプション。OpenTelemetry SDK からメトリクスを収集することを指定します。このセクションで使用できるフィールドの詳細については、「[OpenTelemetry を使用してメトリクスとトレースを収集する](CloudWatch-Agent-OpenTelemetry-metrics.md)」を参照してください。
+ `procstat` - オプション。個別のプロセスからメトリクスを取得することを指定します。procstat で使用できる設定オプションの詳細については、「[procstat プラグインでプロセスメトリクスを収集する](CloudWatch-Agent-procstat-process-metrics.md)」を参照してください 。
+ `statsd` - オプション。`StatsD` プロトコルを使用してカスタムメトリクスを取得することを指定します。CloudWatch エージェントは、プロトコルのデーモンとして機能します。スタンダード `StatsD` クライアントを使用して CloudWatch エージェントにメトリクスを送信します。StatsD で使用できる設定オプションの詳細については、「[StatsD を使用してカスタムメトリクスを取得する](CloudWatch-Agent-custom-metrics-statsd.md)」を参照してください。
+ `ethtool` - オプション。`ethtool` プラグインを使用してネットワークメトリクスを取得することを指定します。このプラグインは、標準 ethtool ユーティリティによって収集されたメトリクスと、Amazon EC2 インスタンスからのネットワークパフォーマンスメトリクスの両方をインポートできます。ethtool で使用できる設定オプションの詳細については、「[ネットワークパフォーマンスメトリクスの収集](CloudWatch-Agent-network-performance.md)」を参照してください。
Linux サーバーの `metrics` セクションの例を次に示します。この例では、3 つの CPU メトリクス、3 つの netstat メトリクス、3 つのプロセスメトリクス、および 1 つのディスクメトリクスが収集され、エージェントは `collectd` クライアントから追加のメトリクスを受信するように設定されています。
```
"metrics": {
"aggregation_dimensions" : [["AutoScalingGroupName"], ["InstanceId", "InstanceType"],[]],
"metrics_collected": {
"collectd": {},
"cpu": {
"resources": [
"*"
],
"measurement": [
{"name": "cpu_usage_idle", "rename": "CPU_USAGE_IDLE", "unit": "Percent"},
{"name": "cpu_usage_nice", "unit": "Percent"},
"cpu_usage_guest"
],
"totalcpu": false,
"drop_original_metrics": [ "cpu_usage_guest" ],
"metrics_collection_interval": 10,
"append_dimensions": {
"test": "test1",
"date": "2017-10-01"
}
},
"netstat": {
"measurement": [
"tcp_established",
"tcp_syn_sent",
"tcp_close"
],
"metrics_collection_interval": 60
},
"disk": {
"measurement": [
"used_percent"
],
"resources": [
"*"
],
"drop_device": true
},
"processes": {
"measurement": [
"running",
"sleeping",
"dead"
]
}
},
"append_dimensions": {
"ImageId": "${aws:ImageId}",
"InstanceId": "${aws:InstanceId}",
"InstanceType": "${aws:InstanceType}",
"AutoScalingGroupName": "${aws:AutoScalingGroupName}"
}
}
```
### Windows Server
Windows Server の `metrics_collected` セクションでは、Windows パフォーマンスオブジェクトごとに `Memory`、`Processor`、`LogicalDisk` などのサブセクションを含めることができます。使用可能なオブジェクトとカウンターについては、Microsoft Windows のドキュメントの「[パフォーマンスカウンター](https://learn.microsoft.com/en-us/windows/win32/perfctrs/performance-counters-portal)」を参照してください。
各オブジェクトのサブセクション内では、収集するカウンタの `measurement` 配列を指定します。`measurement` 配列は、設定ファイルで指定するオブジェクトごとに必要です。`resources` フィールドを指定して、メトリクスの収集元のインスタンスを指定することもできます。また、`*` に `resources` を指定し、すべてのインスタンスの別個のメトリクスを収集することもできます。インスタンスのあるカウンターの `resources` を省略すると、すべてのインスタンスのデータが 1 つのセットに集約されます。インスタンスのないカウンターの `resources` を省略すると、CloudWatch エージェントはカウンターを収集しません。カウンターにインスタンスがあるかどうかを判断するには、次のコマンドのいずれかを使用します。
Powershell:
```
Get-Counter -ListSet *
```
コマンドライン (Powershell ではない):
```
TypePerf.exe –q
```
各オブジェクトセクション内で、以下のオプションフィールドを指定することもできます。
+ `metrics_collection_interval` - オプション。設定ファイルの `metrics_collection_interval` セクションで指定されたグローバルな `agent` を上書きして、このオブジェクトのメトリクスを収集する頻度を指定します。
この値は数秒で指定されます。例えば、10 と設定するとメトリクスが 10 秒ごとに収集されるようになり、300 と設定するとメトリクスが 5 分ごとに収集されように指定されます。
この値を 60 秒未満に設定した場合、各メトリクスは高解像度メトリクスとして収集されます。詳細については、「[高解像度のメトリクス](publishingMetrics.md#high-resolution-metrics)」を参照してください。
+ `append_dimensions` - オプション。このオブジェクトのメトリクスにのみ使用する追加のディメンションを指定します。このフィールドを指定した場合、エージェントにより収集されるすべてのタイプのメトリクスに使用されるグローバル `append_dimensions` フィールドで指定されたディメンションに加えて使用されます。
+ `drop_original_metrics` - オプション。`metrics` セクションの `aggregation_dimensions` フィールドを使用してメトリクスを集計結果にロールアップしている場合、デフォルトでは、エージェントは集計メトリクスと、ディメンションの値ごとに分離された元のメトリクスの両方を送信します。元のメトリクスを CloudWatch に送信したくない場合は、メトリクスのリストを使用してこのパラメータを指定できます。このパラメータとともに指定されたメトリクスには、CloudWatch にレポートされるディメンションごとのメトリクスがありません。代わりに、集計されたメトリクスのみがレポートされます。これにより、エージェントが収集するメトリクスの数が減り、コストが削減されます。
各カウンタセクション内で、以下のオプションフィールドを指定することもできます。
+ `rename` – このメトリクスに、CloudWatch で使用する別の名前を指定します。
+ `unit` – このメトリクスに使用する単位を指定します。指定する単位は、「[MetricDatum](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_MetricDatum.html)」の `Unit` に関する説明にリストされている有効な CloudWatch メトリクス単位でなければなりません。
`metrics_collected` には、他にもオプションのセクションがあります。
+ `statsd` – `StatsD` プロトコルを使用してカスタムメトリクスを取得できます。CloudWatch エージェントは、プロトコルのデーモンとして機能します。スタンダード `StatsD` クライアントを使用して CloudWatch エージェントにメトリクスを送信します。詳細については、「[StatsD を使用してカスタムメトリクスを取得する](CloudWatch-Agent-custom-metrics-statsd.md)」を参照してください。
+ `procstat` – 個別のプロセスからメトリクスを取得できます。詳細については、「[procstat プラグインでプロセスメトリクスを収集する](CloudWatch-Agent-procstat-process-metrics.md)」を参照してください。
+ `jmx` - オプション。インスタンスから Java Management Extensions (JMX) メトリクスを取得することを指定します。このセクションで使用できるフィールド、ならびに収集できるメトリクスの詳細については、「[Java Management Extensions (JMX) メトリクスの収集](CloudWatch-Agent-JMX-metrics.md)」を参照してください。
+ `otlp` - オプション。OpenTelemetry SDK からメトリクスを収集することを指定します。このセクションで使用できるフィールドの詳細については、「[OpenTelemetry を使用してメトリクスとトレースを収集する](CloudWatch-Agent-OpenTelemetry-metrics.md)」を参照してください。
Windows Server で使用する `metrics` セクションの例を次に示します。この例では、多くの Windows メトリクスが収集され、コンピュータは `StatsD` クライアントから追加のメトリクスを受信するように設定されています。
```
"metrics": {
"metrics_collected": {
"statsd": {},
"Processor": {
"measurement": [
{"name": "% Idle Time", "rename": "CPU_IDLE", "unit": "Percent"},
"% Interrupt Time",
"% User Time",
"% Processor Time"
],
"resources": [
"*"
],
"append_dimensions": {
"d1": "win_foo",
"d2": "win_bar"
}
},
"LogicalDisk": {
"measurement": [
{"name": "% Idle Time", "unit": "Percent"},
{"name": "% Disk Read Time", "rename": "DISK_READ"},
"% Disk Write Time"
],
"resources": [
"*"
]
},
"Memory": {
"metrics_collection_interval": 5,
"measurement": [
"Available Bytes",
"Cache Faults/sec",
"Page Faults/sec",
"Pages/sec"
],
"append_dimensions": {
"d3": "win_bo"
}
},
"Network Interface": {
"metrics_collection_interval": 5,
"measurement": [
"Bytes Received/sec",
"Bytes Sent/sec",
"Packets Received/sec",
"Packets Sent/sec"
],
"resources": [
"*"
],
"append_dimensions": {
"d3": "win_bo"
}
},
"System": {
"measurement": [
"Context Switches/sec",
"System Calls/sec",
"Processor Queue Length"
],
"append_dimensions": {
"d1": "win_foo",
"d2": "win_bar"
}
}
},
"append_dimensions": {
"ImageId": "${aws:ImageId}",
"InstanceId": "${aws:InstanceId}",
"InstanceType": "${aws:InstanceType}",
"AutoScalingGroupName": "${aws:AutoScalingGroupName}"
},
"aggregation_dimensions" : [["ImageId"], ["InstanceId", "InstanceType"], ["d1"],[]]
}
}
```
## CloudWatch エージェント設定ファイル: Logs セクション
`logs` セクションには、次のフィールドが含まれます。
+ `service.name` - オプション。エンティティに入力して[関連するテレメトリを検索](ExploreRelated.md)するために使用されるサービス名を指定します。
+ `deployment.environment` - オプション。エンティティに入力して[関連するテレメトリを検索](ExploreRelated.md)するために使用される環境名を指定します。
+ `backpressure_mode` - オプション。CloudWatch エージェントが CloudWatch Logs に送信できるよりも速くログを取り込んでいて、バックプレッシャーが発生する場合の動作を指定します。バックプレッシャーは、ネットワークの問題、API スロットリング、または大量のログが原因で発生する可能性があります。
エージェントは、以下の値をサポートします。
+ `fd_release` – バックプレッシャー状態中に削除されたファイルのファイル記述子を解放します。このオプションは、外部ログのローテーションまたはクリーンアッププロセスでファイルが削除されても、開いているファイル記述子をエージェントが維持している場合、ディスクスペースの枯渇を防ぐのに役立ちます。`auto_removal` オプションは、`fd_release` に設定されている `backpressure_mode` オプションよりも優先されます。`auto_removal` を有効にすると、CloudWatch エージェントはファイル記述子を解放せずにファイルを完了処理します。
**重要**
`fd_release` を使用すると、CloudWatch エージェントは完了するまでログファイルを読み取ることができなくなり、ログが失われる可能性があります。
+ `concurrency` - オプション。CloudWatch Logs へのログファイルの同時発行に使用される共有ログパブリッシャーの数を指定します。
このフィールドを省略すると、ログファイルの送信先 (ロググループ、ストリームの組み合わせ) ごとの共有ログパブリッシャーは 1 つになるため、大きなファイルの場合や同じ送信先に複数のファイルを書き込むときにボトルネックが発生する可能性があります。同時実行を有効にすると、スループットに役立ちます。
+ `logs_collected` – `logs` セクションが含まれている場合に必要です。サーバーから収集するログファイルおよび Windows イベントログを指定します。`files` と `windows_events` の 2 つのフィールドを含めることができます。
+ `files` – CloudWatch エージェントが収集する定期的なログファイルを指定します。1 つのフィールド `collect_list` が含まれます。このフィールドでは、これらのファイルを詳細に定義します。
+ `collect_list` – `files` が含まれている場合に必要です。エントリの配列が含まれており、それぞれ収集するログファイルを 1 つ指定します。これらの各エントリには、次のフィールドを含めることができます。
+ `file_path` – CloudWatch Logs にアップロードするログファイルのパスを指定します。*スーパーアスタリスク*として `**` を追加すると、標準 Unix glob マッチングルールが受け入れられます。たとえば、`/var/log/**.log` と指定すると `.log` ディレクトリツリー内のすべての `/var/log` ファイルが収集されます。他の例については、「[Glob Library](https://github.com/gobwas/glob)」を参照してください。
また、標準のアスタリスクを標準のワイルドカードとして使用することもできます。例えば、`/var/log/system.log*` は、`/var/log` 内の、`system.log_1111`、`system.log_2222` などのファイルに一致します。
ファイルの変更時間に基づいて、最新のファイルのみが CloudWatch Logs にプッシュされます。`access_log.2018-06-01-01` と `access_log.2018-06-01-02` など同じ形式の一連のファイルを指定するにはワイルドカードの使用をお勧めします。ただし、`access_log_80` と `access_log_443` のように複数の種類のファイルには使用しないでください。複数の種類のファイルを指定するには、エージェント設定ファイルに別のストリームログのエントリを追加して、各種類のログファイルが異なるログストリームに行くようにします。
+ `auto_removal` - オプション。これが `true` である場合、CloudWatch エージェントは、このログファイルを、読み取りとローテーションが完了した後に自動的に削除します。通常、ログファイルは、そのコンテンツ全体が CloudWatch Logs にアップロードされた後に削除されますが、エージェントが EOF (ファイルの終わり) に達し、同じ `file_path` に一致する別の新しいログファイルも検出した場合、エージェントは古いファイルを削除します。したがって、新しいファイルの作成前に、古いファイルへの記述を確実に完了する必要があります。[RUST トレースライブラリ](https://docs.rs/tracing/latest/tracing/)には既知の非互換性があります。これは、新しいログファイルが作成された後も、古いログファイルへの書き込みが試行される可能性があることが原因です。
エージェントは、日別に異なるファイルを作成するログなど、複数のファイルを作成するログから完全なファイルのみを削除します。ログが 1 つのファイルに継続的に書き込まれる場合、そのファイルは削除されません。
ログファイルの更新方法や削除方法が設定済みである場合は、このフィールドを省略するか、`false` に設定することをお勧めします。
このフィールドを省略した場合は、デフォルト値の `false` が使用されます。
+ `log_group_name` - オプション。CloudWatch Logs でロググループ名として何を使用するかを指定します。
混乱を避けるため、このフィールドを使用してロググループ名を指定することをお勧めします。`log_group_name` を省略した場合、末尾のドットまでの `file_path` の値がロググループ名として使用されます。たとえば、ファイルパスが `/tmp/TestLogFile.log.2017-07-11-14` の場合、ロググループ名は `/tmp/TestLogFile.log` です。
ロググループ名を指定する場合、`{instance_id}`、`{hostname}`、`{local_hostname}`、`{ip_address}` を変数として使用できます。`{hostname}` は EC2 メタデータからホスト名を取得し、`{local_hostname}` はネットワーク設定ファイルからホスト名を使用します。
これらの変数を使用して多くの異なるロググループを作成する場合は、1 リージョン、1 アカウントあたり 100 万ロググループという制限を念頭に置いてください。
ここで使えるのは、a～z、A～Z、0～9、"\$1" (アンダーバー)、"-" (ハイフン)、"/" (スラッシュ) および "." (ピリオド) です。
+ `log_group_class` - オプション。新しいロググループに使用するロググループクラスを指定します。ロググループクラスの詳細については、「[Log classes](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/CloudWatch_Logs_Log_Classes.html)」を参照してください。
有効な値は、`STANDARD` および `INFREQUENT_ACCESS` です。このフィールドを省略した場合、`STANDARD` のデフォルトが使用されます。
**重要**
ロググループの作成後に、ロググループクラスを変更することはできません。
+ `log_stream_name` - オプション。CloudWatch Logs でログストリーム名として何を使用するかを指定します。名前の一部として、名前では変数として `{instance_id}`、`{hostname}`、`{local_hostname}`、`{ip_address}` を使用することができます。`{hostname}` は、EC2 メタデータからホスト名を取得し、`{local_hostname}` は、ネットワーク設定ファイルからホスト名を使用します。
このフィールドを省略すると、グローバル `log_stream_name` セクションの `logs` パラメータの値が使用されます。これも省略すると、`{instance_id}` のデフォルト値が使用されます。
ログストリームが存在しない場合には、自動的に作成されます。
+ `retention_in_days` - オプション。指定されたロググループにログイベントを保持する日数を指定します。
+ エージェントがこのロググループを作成中なら、このフィールドを省略すると、この新しいロググループが無期限に保持されるように設定されます。
+ このロググループが既に存在していて、このフィールドを指定すると、指定した新しい保存期間が使用されます。既に存在するロググループで、このフィールドを省略した場合、ロググループの保持は変更されません。
CloudWatch エージェントウィザードは、このフィールドのデフォルト値として `-1` を使用します。これは、エージェント設定ファイルを作成する場合で、ログ保持の値を指定しない場合に使用されます。ウィザードが設定するこの `-1` の値によって、ロググループ内のイベントが期限切れにならないよう指定されます。ただし、この値を手動で `-1` に編集しても効果はありません。
有効な値は 1、3、5、7、14、30、60、90、120、150、180、365、400、545、731、1827、2192、2557、2922、3288、および 3653 です。
同じロググループに複数のログストリームを書き込むようにエージェントを設定する場合、1 つの場所で `retention_in_days` を指定すると、ロググループ全体のログの保持が設定されます。複数の場所で同じロググループ向けに `retention_in_days` を指定した場合、それらの値がすべて等しい場合に保持が設定されます。ただし、複数の場所で同じロググループに異なる `retention_in_days` の値が指定されている場合、ログの保持は設定されず、エージェントは停止してエラーを返します。
**注記**
エージェントの IAM ロールまたは IAM ユーザーが保持ポリシーを設定するには、`logs:PutRetentionPolicy` を持っている必要があります。
**警告**
既に存在するロググループ向けに `retention_in_days` を設定した場合、指定した日数より前に発行されたそのロググループ内のすべてのログが削除されます。例えば、3 に設定すると、3 日以上前のすべてのログが削除されます。
+ `filters` - オプション。エントリの配列を含めることができます。各エントリは、正規表現とフィルタータイプを指定し、フィルターに一致するログエントリを発行またはドロップするかどうかを指定します。このフィールドを省略すると、ログファイル内のすべてのログが CloudWatch Logs に発行されます。このフィールドを含めると、エージェントは指定したすべてのフィルターを使用して各ログメッセージを処理し、すべてのフィルターを通過するログイベントのみが CloudWatch Logs に発行されます。一部のフィルターを通過しないログエントリは、ホストのログファイルに残りますが、CloudWatch Logs には送信されません。
フィルター配列の各エントリには、次のフィールドを含めることができます。
+ `type` – フィルターのタイプを示します。有効な値は、`include` および `exclude` です。`include` では、ログエントリは CloudWatch Logs に発行される式と一致する必要があります。`exclude` では、フィルターに一致する各ログエントリは CloudWatch Logs に送信されません。
+ `expression` – [RE2 Syntax](https://github.com/google/re2/wiki/Syntax) に続く正規表現の文字列。
**注記**
CloudWatch エージェントは、指定した正規表現のパフォーマンスをチェックしたり、正規表現の評価の実行時間を制限したりしません。評価に多くのコストがかかる表現を記述しないように注意することをおすすめします。発生する可能性のある問題の詳細については、「[Regular expression Denial of Service - ReDoS](https://owasp.org/www-community/attacks/Regular_expression_Denial_of_Service_-_ReDoS)」(正規表現のサービス拒否 - ReDoS) を参照してください。
例えば、次の CloudWatch エージェント設定ファイルの抜粋は、PUT および POST リクエストであるログを CloudWatch Logs に発行しますが、Firefox からのログは除外されます。
```
"collect_list": [
{
"file_path": "/opt/aws/amazon-cloudwatch-agent/logs/test.log",
"log_group_name": "test.log",
"log_stream_name": "test.log",
"filters": [
{
"type": "exclude",
"expression": "Firefox"
},
{
"type": "include",
"expression": "P(UT|OST)"
}
]
},
.....
]
```
**注記**
設定ファイル内のフィルターの順序は、パフォーマンス上重要です。前述の例において、エージェントは 2 番目のフィルターの評価を開始する前に、`Firefox` に一致するすべてのログをドロップします。複数のフィルターで評価されるログエントリを少なくするには、より多くのログを除外するフィルターを設定ファイルに最初に配置します。
+ `timezone` - オプション。ログイベントにタイムスタンプを付けるときに使用するタイムゾーンを指定します。有効な値は `UTC` および `Local` です。デフォルト値は `Local` です。
`timestamp_format` の値を指定しない場合、このパラメータは無視されます。
+ `timestamp_format` - オプション。% で始まる特殊記号とプレーンテキストを使用して、タイムスタンプ形式を指定します。このフィールドを省略した場合は、現在の時刻が使用されます。このフィールドを使用する場合は、以下のリストの記号を形式の一部に使用することができます。
**注記**
このパラメータは、`file_path` が `amazon-cloudwatch-agent.log` に設定されている場合、考慮されません。
1 つのログエントリに、形式に一致する 2 つのタイムスタンプが含まれている場合、最初のタイムスタンプが使用されます。
この記号のリストは、以前の CloudWatch Logs エージェントで使用されるリストとは異なります。このような違いの概要については、「[CloudWatch エージェントと前の CloudWatch Logs エージェントとの間のタイムスタンプの違い](CloudWatch-Agent-common-scenarios.md#CloudWatch-Agent-logs-timestamp-differences)」を参照してください。
`%y`
ゼロ詰め 10 進数での年 (世紀なし) たとえば `19` で 2019 を表します。
`%Y`
10 進数での年 (世紀あり) 例えば、`2019`。
`%b`
ロケールの省略名称での月
`%B`
ロケールの正式名称での月
`%m`
ゼロ詰め 10 進数での月
`%-m`
10 進数での月 (ゼロ詰めなし)
`%d`
ゼロ詰め 10 進数での日
`%-d`
10 進数での日 (ゼロ詰めなし)
`%A`
曜日のフルネーム。`Monday` など
`%a`
曜日の略称。`Mon` など
`%H`
ゼロ詰め 10 進数での時 (24 時間形式の時計)
`%I`
ゼロ詰め 10 進数での時 (12 時間形式の時計)
`%-I`
10 進数での時間 (12 時間制) (ゼロ詰めなし)
`%p`
AM または PM
`%M`
ゼロ詰め 10 進数での分
`%-M`
10 進数での分 (ゼロ詰めなし)
`%S`
ゼロ詰め 10 進数での秒
`%-S`
10 進数での秒 (ゼロ詰めなし)
`%f`
10 進数 (1～9 桁) での少数秒 (左側をゼロ詰め)
`%Z`
タイムゾーン。`PST` など
`%z`
タイムゾーンは、ローカルタイムゾーンと UTC の間のオフセットとして表されます。例えば、`-0700`。この形式のみがサポートされています。たとえば、`-07:00` は有効な形式ではありません。
+ `multi_line_start_pattern` – ログメッセージの開始を識別するパターンを指定します。ログメッセージは、パターンに一致する 1 行と、後続パターンに一致しない行で構成されます。
このフィールドを指定しない場合、複数行モードが無効になり、空白文字以外の文字で始まる行は、前のログメッセージを終了して新しいログメッセージを開始します。
このフィールドを含める場合、`{timestamp_format}` を指定してタイムスタンプ形式と同じ正規表現を使用できます。それ以外の場合、CloudWatch Logs が複数行エントリの最初の行を判断するために使用する別の正規表現を指定できます。
+ `encoding` – 正しく読み込むことができるように、ログファイルのエンコードを指定します。正しくないエンコードを指定すると、デコードできない文字がその他の文字に置き換えられるため、データ損失が生じる可能性があります。
デフォルト値は `utf-8` です。指定できる値は以下のとおりです。
`ascii, big5, euc-jp, euc-kr, gbk, gb18030, ibm866, iso2022-jp, iso8859-2, iso8859-3, iso8859-4, iso8859-5, iso8859-6, iso8859-7, iso8859-8, iso8859-8-i, iso8859-10, iso8859-13, iso8859-14, iso8859-15, iso8859-16, koi8-r, koi8-u, macintosh, shift_jis, utf-8, utf-16, utf-16le, UTF-16, UTF-16LE, windows-874, windows-1250, windows-1251, windows-1252, windows-1253, windows-1254, windows-1255, windows-1256, windows-1257, windows-1258, x-mac-cyrillic`
+ `service.name` - オプション。エンティティに入力して[関連するテレメトリを検索](ExploreRelated.md)するために使用されるサービス名を指定します。
+ `deployment.environment` - オプション。エンティティに入力して[関連するテレメトリを検索](ExploreRelated.md)するために使用される環境名を指定します。
+ `trim_timestamp` - オプション。これが true の場合、CloudWatch エージェントは CloudWatch Logs に送信する前に、`timestamp_format` によって一致したタイムスタンプを行から削除します。LogEvent には引き続き `timestamp` フィールドが含まれます。
このフィールドを省略した場合は、デフォルト値の `false` が使用されます。
+ `windows_events` セクションでは、Windows Server を実行しているサーバーから収集する Windows イベントのタイプを指定します。次のフィールドが含まれています。
+ `collect_list` – `windows_events` が含まれている場合に必要です。収集する Windows イベントのタイプとレベルを指定します。収集される各ログには、このセクションのエントリがあります。次のフィールドが含まれる可能性があります。
+ `event_name` – ログ記録する Windows イベントのタイプを指定します。これは Windows イベントログのチャネル名と同等です。たとえば、`System`、`Security`、`Application` などがあります。このフィールドは、ログ記録する Windows イベントのタイプごとに必要です。
**注記**
CloudWatch が Windows ログチャネルからメッセージを取得する際には、`Full Name` プロパティに基づき、そのログチャネルがルックアップされます。その間、Windows イベントビューアのナビゲーションペインには、ログチャネルの `Log Name` プロパティが表示されます。`Full Name` と `Log Name` は必ずしも一致しません。チャンネルの `Full Name` を確認するには、Windows イベントビューアでチャンネルを右クリックし、[**プロパティ**] を開きます。
+ `event_levels` - オプション。ログに記録するイベントのレベルを指定します。ログ記録する各レベルを指定する必要があります。指定できる値には、`INFORMATION`、`WARNING`、`ERROR`、`CRITICAL`および `VERBOSE` などがあります。このフィールドは、ログに記録する Windows イベントのタイプごとにオプションで設定できます。`event_ids` や `filters` などの他のフィルタリングオプションと併用できます。
+ `event_ids` - オプション。Windows イベントログから収集するイベントを指定する Windows イベント ID の配列が含まれています。このフィールドを除外すると、指定されたイベントログのすべてのイベントが収集されます。このフィールドを含めると、エージェントは指定されたイベント ID に一致するイベントのみを収集します。
`event_ids` 配列内の各エントリは、数値のイベント ID 値である必要があり、他のフィルタリングオプションと併用できます。以下の設定サンプルの 3 番目のエントリを参照してください。
**注記**
イベント ID でフィルタリングする必要がある場合は、正規表現よりも `event_ids` をフィルタリングに使用することをお勧めします。これにより、パフォーマンスが向上します。
+ `filters` - オプション。エントリの配列が含まれます。各エントリは、正規表現とフィルタータイプを指定し、フィルターに一致するログエントリを発行またはドロップするかどうかを指定します。フィールドが含まれている場合、エージェントは指定したすべてのフィルターを使用して各ログメッセージを処理し、すべてのフィルターを通過したログイベントのみが CloudWatch Logs に発行されます。すべてのフィルターに通過しない Windows イベントログは破棄され、CloudWatch Logs に送信されません。フィルターセクションは、イベント ID [4624、4625] やシステムレベル (情報、エラー、重大) などの他のフィルタリングメカニズムと併用して、ログを効果的にフィルタリングして CloudWatch にプッシュすることもできます。
フィルター配列の各エントリには、次のフィールドを含めることができます。
+ `type` – フィルターのタイプを指定します。有効な値は、`include` および `exclude` です。include を使用する場合、Windows イベントエントリは、CloudWatch Logs に発行される式と一致する必要があります。exclude を使用すると、フィルターに一致する各 Windows イベントログエントリは CloudWatch Logs に送信されません。
+ `expression` – RE2 Syntax に続く正規表現の文字列。
**注記**
CloudWatch エージェントは、指定した正規表現を検証しません。また、評価時間も制限されません。パフォーマンスの問題を避けるために、式を慎重に記述してください。セキュリティリスクの詳細については、「[Regular expression Denial of Service - ReDoS](https://owasp.org/www-community/attacks/Regular_expression_Denial_of_Service_-_ReDoS)」を参照してください。
以下のエージェント設定の例では:
最初のエントリでは、エージェントはデータベース障害メッセージ、認証関連のアクティビティ、すべてのログインイベント (成功した試行と失敗した試行の両方) を含むログを CloudWatch にプッシュします。このパターンに一致しないログはすべてドロップされます。
2 番目のエントリでは、Windows イベントサブスクリプションのイベント ID に基づいて最初のフィルタリングが行われます。エージェントは、文字列ユーザーを含むすべてのログを収集し、これらのパターンに一致しないログを破棄します。エージェントは、残りのログを CloudWatch Logs に送信する前に、`successful` を含むログを削除します。CloudWatch に送信する前に、すべてのフィルタータイプが各 Windows イベントログに適用されます。
```
"collect_list": [
{
"event_name": "Application",
"log_group_name": "ApplicationEvents",
"log_stream_name": "ApplicationEvents",
"filters": [
{
"type": "include",
"expression": "Database.*failed|Authentication.*|login.*"
}
]
},
{
"event_name": "System",
"log_group_name": "SystemEvents",
"log_stream_name": "Logon-events",
"event_ids": [
4624,
4625
],
"filters": [
{
"type": "include",
"expression": ".*user.*"
},
{
"type": "exclude",
"expression": ".*successful.*"
}
]
}
.....
]
```
**注記**
設定内のフィルターの順序はパフォーマンスに影響します。2 番目のエントリでは、エージェントは 2 番目のフィルター式の評価を開始する前に、ユーザーと一致しないすべてのログをドロップします。最適なパフォーマンスを得るには、除外率の上限から下限までフィルターを並べ替えます。
フィルター式のイベント ID とシステムレベルのログを除外できますが、パフォーマンスを向上させるには、2 番目のエントリに示すように、`event_ids` と `log_level` を使用することをお勧めします。
**警告**
すべてのフィルタリングメカニズム (event\$1levels、event\$1ids、filters) はオプションですが、ログをフィルタリングするにはエージェント設定中に少なくとも 1 つが必要です。
+ `log_group_name` – 必須。CloudWatch Logs でロググループ名として何を使用するかを指定します。
+ `log_stream_name` - オプション。CloudWatch Logs でログストリーム名として何を使用するかを指定します。名前の一部として、名前では変数として `{instance_id}`、`{hostname}`、`{local_hostname}`、`{ip_address}` を使用することができます。`{hostname}` は、EC2 メタデータからホスト名を取得し、`{local_hostname}` は、ネットワーク設定ファイルからホスト名を使用します。
このフィールドを省略すると、グローバル `log_stream_name` セクションの `logs` パラメータの値が使用されます。これも省略すると、`{instance_id}` のデフォルト値が使用されます。
ログストリームが存在しない場合には、自動的に作成されます。
+ `event_format` - オプション。Windows のイベントを CloudWatch Logs に保存する際に使用する形式を指定します。`xml` は、Windows イベントビューワーと同じように XML 形式を使用します。`text` は、レガシーの CloudWatch Logs エージェント形式を使用します。
+ `retention_in_days` - オプション。指定されたロググループに Windows イベントを保持する日数を指定します。
+ エージェントがこのロググループを作成中なら、このフィールドを省略すると、この新しいロググループが無期限に保持されるように設定されます。
+ このロググループが既に存在していて、このフィールドを指定すると、指定した新しい保存期間が使用されます。既に存在するロググループで、このフィールドを省略した場合、ロググループの保持は変更されません。
CloudWatch エージェントウィザードは、このフィールドのデフォルト値として `-1` を使用します。これは、エージェント設定ファイルを作成する場合で、ログ保持の値を指定しない場合に使用されます。ウィザードが設定するこの `-1` の値は、ロググループ内のイベントが期限切れにならないよう指定します。ただし、この値を手動で `-1` に編集しても効果はありません。
有効な値は 1、3、5、7、14、30、60、90、120、150、180、365、400、545、731、1827、2192、2557、2922、3288、および 3653 です。
同じロググループに複数のログストリームを書き込むようにエージェントを設定する場合、1 つの場所で `retention_in_days` を指定すると、ロググループ全体のログの保持が設定されます。複数の場所で同じロググループ向けに `retention_in_days` を指定した場合、それらの値がすべて等しい場合に保持が設定されます。ただし、複数の場所で同じロググループに異なる `retention_in_days` の値が指定されている場合、ログの保持は設定されず、エージェントは停止してエラーを返します。
**注記**
エージェントの IAM ロールまたは IAM ユーザーが保持ポリシーを設定するには、`logs:PutRetentionPolicy` を持っている必要があります。
**警告**
既に存在するロググループ向けに `retention_in_days` を設定した場合、指定した日数より前に発行されたそのロググループ内のすべてのログが削除されます。例えば、3 に設定すると、3 日以上前のすべてのログが削除されます。
+ `log_stream_name` - オプション。`log_stream_name` のログや Windows イベントの個別のログストリーム名が `collect_list` パラメータに定義されていない場合、代わりに使用するデフォルトのログストリーム名を指定します。
+ `endpoint_override` – エージェントがログを送信するエンドポイントとして使用する FIPS エンドポイントまたはプライベートリンクを指定します。このフィールドを指定してプライベートリンクを設定すると、Amazon VPC エンドポイントにログを送信できます。詳細については、「[Amazon VPC とは](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html)」を参照してください。
`endpoint_override` の値は URL 文字列であることが必要です。
たとえば、設定ファイルの logs セクションの次の部分は、ログを送信するときに VPC エンドポイントを使用するようにエージェントを設定します。
```
{
"logs": {
"endpoint_override": "vpce-XXXXXXXXXXXXXXXXXXXXXXXXX.logs.us-east-1.vpce.amazonaws.com",
......
},
}
```
+ `force_flush_interval` – ログがサーバーに送信されるまでにメモリバッファ内に残留する最大時間を秒単位で指定します。このフィールドの設定にかかわらず、バッファ内のログのサイズが 1 MB に達すると、ログは即座にサーバーに送信されます。デフォルト値は 5 です。
エージェントを使用して高解像度メトリクスを埋め込みメトリクス形式で報告し、それらのメトリクスにアラームを設定する場合は、このパラメータをデフォルト値の 5 に設定してください。それ以外の場合は、メトリクスが遅延して報告され、データが部分的または不完全な場合にアラームが発報する可能性があります。
+ `credentials` – 異なる AWS アカウントにログを送信する際に使用する IAM ロールを指定します。指定した場合、このフィールドには 1 つのパラメータ `role_arn` が含まれています。
+ `role_arn` – 異なる AWS アカウントにログを送信する際の認証用 IAM ロールの ARN を指定します。詳細については、「[別のアカウントへのメトリクス、ログ、トレースの送信](CloudWatch-Agent-common-scenarios.md#CloudWatch-Agent-send-to-different-AWS-account)」を参照してください。ここで指定した場合は、設定ファイルの `role_arn` セクションで指定された `agent` よりも優先されます (存在する場合)。
+ `metrics_collected` - このフィールドには、エージェントにログ収集を指示するセクションを含めることができます。CloudWatch Application Signals と Container Insights のオブザーバビリティを Amazon EKS 向けに強化するといったユースケースを利用できるようになります。
+ `application_signals`(オプション) [CloudWatch Application Signals](CloudWatch-Application-Monitoring-Sections.md) を有効にすることを指定します。この設定の詳細については、「[CloudWatch Application Signals を有効にする](CloudWatch-Agent-Application_Signals.md)」を参照してください。
+ `kubernetes` — このフィールドには、`enhanced_container_insights` パラメータを含めることができます。これは、Amazon EKS 向けにオブザーバビリティが強化された Container Insights を有効にするために使用できます。
+ `enhanced_container_insights` — これを `true` に設定すると、Amazon EKS 向けにオブザーバビリティが強化された Container Insights が有効になります。詳細については、「[Amazon EKS 向けに拡張オブザーバビリティを備えた Container Insights](container-insights-detailed-metrics.md)」を参照してください。
+ `accelerated_compute_metrics` - Amazon EKS クラスターでの Nvidia GPU メトリクスの収集をオプトアウトするには、これを `false` に設定します。詳細については、「[NVIDIA GPU メトリクス](Container-Insights-metrics-enhanced-EKS.md#Container-Insights-metrics-EKS-GPU)」を参照してください。
+ `emf` – ログに埋め込まれたメトリクスを収集するために、この `emf` フィールドを追加する必要はなくなりました。これは、エージェントが埋め込みメトリクス形式のログを収集するように指定するレガシーフィールドです。これらのログからメトリクスデータを生成できます。詳細については、「[ログ内へのメトリクスの埋め込み](CloudWatch_Embedded_Metric_Format.md)」を参照してください。
+ `otlp` - オプション。OpenTelemetry SDK からメトリクスを収集することを指定します。このセクションで使用できるフィールドの詳細については、「[OpenTelemetry を使用してメトリクスとトレースを収集する](CloudWatch-Agent-OpenTelemetry-metrics.md)」を参照してください。
`logs` セクションの例を以下に示します。
```
"logs":{
"logs_collected": {
"files": {
"collect_list": [
{
"file_path": "c:\\ProgramData\\Amazon\\AmazonCloudWatchAgent\\Logs\\amazon-cloudwatch-agent.log",
"log_group_name": "amazon-cloudwatch-agent.log",
"log_stream_name": "my_log_stream_name_1"
},
{
"file_path": "c:\\ProgramData\\Amazon\\AmazonCloudWatchAgent\\Logs\\test.log",
"log_group_name": "test.log",
"log_stream_name": "my_log_stream_name_2"
}
]
},
"windows_events": {
"collect_list": [
{
"event_name": "System",
"event_ids": [
1001,
1008
],
"log_group_name": "System",
"log_stream_name": "System"
},
{
"event_name": "CustomizedName",
"event_levels": [
"INFORMATION",
"ERROR"
],
"log_group_name": "CustomizedLogGroup",
"log_stream_name": "CustomizedLogStream"
},
{
"event_name": "Application",
"event_levels": [
"INFORMATION",
"ERROR"
],
"event_ids":[
7369,
5624
],
"log_group_name": "CustomizedLogGroup",
"log_stream_name": "CustomizedLogStream"
}
]
}
},
"log_stream_name": "my_log_stream_name",
"metrics_collected": {
"kubernetes": {
"enhanced_container_insights": true
}
}
}
```
## CloudWatch エージェント設定ファイル: [トレース] セクション
CloudWatch エージェント設定ファイルに `traces` セクションを追加することで、CloudWatch Application Signals を有効にできるほか、X-Ray や OpenTelemetry 計測 SDK からトレースを収集して X-Ray に送信することもできます。
**重要**
エージェントの IAM ロールまたは IAM ユーザーがトレースデータを X-Ray に送信できるようにするには、**AWSXrayWriteOnlyAccess** ポリシーが必要です。
トレースの収集を簡単に開始するために必要なのは、CloudWatch エージェント設定ファイルに次の内容を追加することだけです。
```
"traces_collected": {
"xray": {
},
"otlp": {
}
}
```
前のセクションを CloudWatch エージェント設定ファイルに追加してエージェントを再起動すると、エージェントは次のデフォルトのオプションと値を使用してトレースの収集を開始します。これらのパラメータの詳細については、このセクションで後述するパラメータの定義を参照してください。
```
"traces_collected": {
"xray": {
"bind_address": "127.0.0.1:2000",
"tcp_proxy": {
"bind_address": "127.0.0.1:2000"
}
},
"otlp": {
"grpc_endpoint": "127.0.0.1:4317",
"http_endpoint": "127.0.0.1:4318"
}
}
```
`traces` セクションでは、次のフィールドを含めることができます。
+ `traces_collected` – `traces` セクションが含まれている場合に必要です。トレースの収集元になる SDK を指定します。次のフィールドを含めることができます。
+ `application_signals` - オプション。[CloudWatch Application Signals](CloudWatch-Application-Monitoring-Sections.md) を有効にすることを指定します。この設定の詳細については、「[CloudWatch Application Signals を有効にする](CloudWatch-Agent-Application_Signals.md)」を参照してください。
+ `xray` - オプション。X-Ray SDK からトレースを収集することを指定します。このセクションには、次のフィールドを含めることができます。
+ `bind_address` - オプション。CloudWatch エージェントが X-Ray のトレースのリッスンに使用する UDP アドレスを指定します。形式は `ip:port` です。このアドレスは、X-Ray SDK で設定されたアドレスと一致する必要があります。
このフィールドを省略した場合、`127.0.0.1:2000` のデフォルトが使用されます。
+ `tcp_proxy` - オプション。X-Ray リモートサンプリングをサポートするために使用されるプロキシのアドレスを設定します。詳細については、X-Ray ドキュメントの「[サンプリングルールの設定](https://docs.aws.amazon.com/xray/latest/devguide/xray-console-sampling.html)」を参照してください。
このセクションには、次のフィールドを含めることができます。
+ `bind_address` - オプション。CloudWatch エージェントがプロキシを設定する必要がある TCP アドレスを指定します。形式は `ip:port` です。このアドレスは、X-Ray SDK で設定されたアドレスと一致する必要があります。
このフィールドを省略した場合、`127.0.0.1:2000` のデフォルトが使用されます。
+ `otlp` - オプション。OpenTelemetry SDK からトレースを収集することを指定します。このセクションで使用できるフィールドの詳細については、「[OpenTelemetry を使用してメトリクスとトレースを収集する](CloudWatch-Agent-OpenTelemetry-metrics.md)」を参照してください)。AWS Distro for OpenTelemetry の詳細については、[AWS Distro for OpenTelemetry](https://aws.amazon.com/otel/) を参照してください。AWS Distro for OpenTelemetry SDK の詳細については、「[はじめに](https://aws-otel.github.io/docs/introduction)」を参照してください。
このセクションには、次のフィールドを含めることができます。
+ `grpc_endpoint` - オプション。gRPC リモートプロシージャコールを使用して送信された OpenTelemetry トレースをリッスンするために使用する CloudWatch エージェントのアドレスを指定します。形式は `ip:port` です。このアドレスは、OpenTelemetry SDK の gRPC エクスポーター用に設定されたアドレスと一致する必要があります。
このフィールドを省略した場合、`127.0.0.1:4317` のデフォルトが使用されます。
+ `http_endpoint` - オプション。HTTP 経由で送信される OTLP トレースをリッスンするために CloudWatch エージェントが使用するアドレスを指定します。形式は `ip:port` です。このアドレスは、OpenTelemetry SDK の HTTP エクスポーター用に設定されたアドレスと一致する必要があります。
このフィールドを省略した場合、`127.0.0.1:4318` のデフォルトが使用されます。
+ `concurrency` - オプション。トレースのアップロードに使用できる、X-Ray に対する同時呼び出しの最大数を指定します。デフォルト値は、「`8`」です。
+ `local_mode` - オプション。`true` の場合、エージェントは Amazon EC2 インスタンスのメタデータを収集しません。デフォルトは `false` です。
+ `endpoint_override` - オプション。 CloudWatch エージェントがトレースを送信するエンドポイントとして使用する FIPS エンドポイントまたはプライベートリンクを指定します。このフィールドを指定してプライベートリンクを設定すると、Amazon VPC エンドポイントにトレースを送信できます。詳細については、「[Amazon VPC とは](https://docs.aws.amazon.com/vpc/latest/userguide/what-is-amazon-vpc.html)」を参照してください。
`endpoint_override` の値は URL 文字列であることが必要です。
+ `region_override` - オプション。X-Ray エンドポイント用に使用するリージョンを指定します。CloudWatch エージェントは、指定されたリージョンの X-Ray にトレースを送信します。このフィールドを省略すると、エージェントは Amazon EC2 インスタンスが配置されているリージョンにトレースを送信します。
ここでリージョンを指定すると、設定ファイルの `agent` セクションの `region` パラメータの設定よりも優先されます。
+ `proxy_override` - オプション。X-Ray にリクエストを送信する際に CloudWatch エージェントが使用するプロキシサーバーアドレスを指定します。プロキシサーバーのプロトコルは、このアドレスの一部として指定する必要があります。
+ `credentials` – 異なる AWS アカウントにトレースを送信する際に使用する IAM ロールを指定します。指定した場合、このフィールドには 1 つのパラメータ `role_arn` が含まれています。
+ `role_arn` – 異なる AWS アカウントにトレースを送信する際の認証用 IAM ロールの ARN を指定します。詳細については、「[別のアカウントへのメトリクス、ログ、トレースの送信](CloudWatch-Agent-common-scenarios.md#CloudWatch-Agent-send-to-different-AWS-account)」を参照してください。ここで指定した場合は、設定ファイルの `role_arn` セクションで指定された `agent` よりも優先されます (存在する場合)。
+ `transit_spans_in_otlp_format` - オプション。`true` の場合、OpenTelemetry Protocol 形式でトレースを X-Ray に送信します。これはトランザクション検索のスパンイベントをサポートします。詳細については、「[カスタム属性の追加](CloudWatch-Transaction-Search-add-custom-attributes.md)」を参照してください。デフォルトは `false` です。
## CloudWatch エージェント設定ファイル: 完全な例
Linux サーバーの完全な CloudWatch エージェント設定ファイルの例を次に示します。
収集するメトリクスについて `measurement` セクションにリストされた項目では、完全なメトリクス名、またはリソースのタイプに追加するメトリクス名の一部のみを指定できます。たとえば、`reads` セクションの `diskio_reads` セクションで `measurement` または `diskio` を指定すると、`diskio_reads` メトリクスが収集されます。
この例には、`measurement` セクションでメトリクスを指定するための両方の方法が含まれています。
```
{
"agent": {
"metrics_collection_interval": 10,
"logfile": "/opt/aws/amazon-cloudwatch-agent/logs/amazon-cloudwatch-agent.log"
},
"metrics": {
"namespace": "MyCustomNamespace",
"metrics_collected": {
"cpu": {
"resources": [
"*"
],
"measurement": [
{"name": "cpu_usage_idle", "rename": "CPU_USAGE_IDLE", "unit": "Percent"},
{"name": "cpu_usage_nice", "unit": "Percent"},
"cpu_usage_guest"
],
"totalcpu": false,
"metrics_collection_interval": 10,
"append_dimensions": {
"customized_dimension_key_1": "customized_dimension_value_1",
"customized_dimension_key_2": "customized_dimension_value_2"
}
},
"disk": {
"resources": [
"/",
"/tmp"
],
"measurement": [
{"name": "free", "rename": "DISK_FREE", "unit": "Gigabytes"},
"total",
"used"
],
"ignore_file_system_types": [
"sysfs", "devtmpfs"
],
"metrics_collection_interval": 60,
"append_dimensions": {
"customized_dimension_key_3": "customized_dimension_value_3",
"customized_dimension_key_4": "customized_dimension_value_4"
}
},
"diskio": {
"resources": [
"*"
],
"measurement": [
"reads",
"writes",
"read_time",
"write_time",
"io_time"
],
"metrics_collection_interval": 60
},
"swap": {
"measurement": [
"swap_used",
"swap_free",
"swap_used_percent"
]
},
"mem": {
"measurement": [
"mem_used",
"mem_cached",
"mem_total"
],
"metrics_collection_interval": 1
},
"net": {
"resources": [
"eth0"
],
"measurement": [
"bytes_sent",
"bytes_recv",
"drop_in",
"drop_out"
]
},
"netstat": {
"measurement": [
"tcp_established",
"tcp_syn_sent",
"tcp_close"
],
"metrics_collection_interval": 60
},
"processes": {
"measurement": [
"running",
"sleeping",
"dead"
]
}
},
"append_dimensions": {
"ImageId": "${aws:ImageId}",
"InstanceId": "${aws:InstanceId}",
"InstanceType": "${aws:InstanceType}",
"AutoScalingGroupName": "${aws:AutoScalingGroupName}"
},
"aggregation_dimensions" : [["ImageId"], ["InstanceId", "InstanceType"], ["d1"],[]],
"force_flush_interval" : 30
},
"logs": {
"logs_collected": {
"files": {
"collect_list": [
{
"file_path": "/opt/aws/amazon-cloudwatch-agent/logs/amazon-cloudwatch-agent.log",
"log_group_name": "amazon-cloudwatch-agent.log",
"log_stream_name": "amazon-cloudwatch-agent.log",
"timezone": "UTC"
},
{
"file_path": "/opt/aws/amazon-cloudwatch-agent/logs/test.log",
"log_group_name": "test.log",
"log_stream_name": "test.log",
"timezone": "Local"
}
]
}
},
"log_stream_name": "my_log_stream_name",
"force_flush_interval" : 15,
"metrics_collected": {
"kubernetes": {
"enhanced_container_insights": true
}
}
}
}
```
Windows Server を実行しているサーバーの完全な CloudWatch エージェント設定ファイルの例を次に示します。
```
{
"agent": {
"metrics_collection_interval": 60,
"logfile": "c:\\ProgramData\\Amazon\\AmazonCloudWatchAgent\\Logs\\amazon-cloudwatch-agent.log"
},
"metrics": {
"namespace": "MyCustomNamespace",
"metrics_collected": {
"Processor": {
"measurement": [
{"name": "% Idle Time", "rename": "CPU_IDLE", "unit": "Percent"},
"% Interrupt Time",
"% User Time",
"% Processor Time"
],
"resources": [
"*"
],
"append_dimensions": {
"customized_dimension_key_1": "customized_dimension_value_1",
"customized_dimension_key_2": "customized_dimension_value_2"
}
},
"LogicalDisk": {
"measurement": [
{"name": "% Idle Time", "unit": "Percent"},
{"name": "% Disk Read Time", "rename": "DISK_READ"},
"% Disk Write Time"
],
"resources": [
"*"
]
},
"customizedObjectName": {
"metrics_collection_interval": 60,
"customizedCounterName": [
"metric1",
"metric2"
],
"resources": [
"customizedInstances"
]
},
"Memory": {
"metrics_collection_interval": 5,
"measurement": [
"Available Bytes",
"Cache Faults/sec",
"Page Faults/sec",
"Pages/sec"
]
},
"Network Interface": {
"metrics_collection_interval": 5,
"measurement": [
"Bytes Received/sec",
"Bytes Sent/sec",
"Packets Received/sec",
"Packets Sent/sec"
],
"resources": [
"*"
],
"append_dimensions": {
"customized_dimension_key_3": "customized_dimension_value_3"
}
},
"System": {
"measurement": [
"Context Switches/sec",
"System Calls/sec",
"Processor Queue Length"
]
}
},
"append_dimensions": {
"ImageId": "${aws:ImageId}",
"InstanceId": "${aws:InstanceId}",
"InstanceType": "${aws:InstanceType}",
"AutoScalingGroupName": "${aws:AutoScalingGroupName}"
},
"aggregation_dimensions" : [["ImageId"], ["InstanceId", "InstanceType"], ["d1"],[]]
},
"logs": {
"logs_collected": {
"files": {
"collect_list": [
{
"file_path": "c:\\ProgramData\\Amazon\\AmazonCloudWatchAgent\\Logs\\amazon-cloudwatch-agent.log",
"log_group_name": "amazon-cloudwatch-agent.log",
"timezone": "UTC"
},
{
"file_path": "c:\\ProgramData\\Amazon\\AmazonCloudWatchAgent\\Logs\\test.log",
"log_group_name": "test.log",
"timezone": "Local"
}
]
},
"windows_events": {
"collect_list": [
{
"event_name": "System",
"event_levels": [
"INFORMATION",
"ERROR"
],
"log_group_name": "System",
"log_stream_name": "System",
"event_format": "xml"
},
{
"event_name": "CustomizedName",
"event_levels": [
"WARNING",
"ERROR"
],
"log_group_name": "CustomizedLogGroup",
"log_stream_name": "CustomizedLogStream",
"event_format": "xml"
}
]
}
},
"log_stream_name": "example_log_stream_name"
}
}
```
## CloudWatch エージェント設定ファイルを手動で保存するには
CloudWatch エージェント設定ファイルを手動で作成または編集する場合は、任意の名前を付けることができます。ファイルを作成したら、エージェントを実行する他のサーバーにそのファイルをコピーできます。
## CloudWatch エージェント設定ファイルの Systems Manager Parameter Store へのアップロード
SSM Agent を使用して CloudWatch エージェントをサーバーにインストールする場合は、CloudWatch エージェント設定ファイルを手動で編集した後、Systems Manager Parameter Store にアップロードできます。これを行うには、Systems Manager `put-parameter` コマンドを使用します。
Parameter Store にファイルを保存できるようにするには、十分なアクセス権限を持つ IAM ロールを使用する必要があります。
次のコマンドを使用します。ここで、*parameter name* は Parameter Store でこのファイルに使用する名前で、*configuration\$1file\$1pathname* は編集した設定ファイルのパスとファイル名です。
```
aws ssm put-parameter --name "parameter name" --type "String" --value file://configuration_file_pathname
```
# CloudWatch Application Signals を有効にする
CloudWatch Application Signals を使用すると、AWS 上でアプリケーションを自動的に計測して、ビジネス目標に照らしてアプリケーションのパフォーマンスを追跡できます。Application Signals では、Java アプリケーションとその依存関係やエッジをアプリケーション中心の統合ビューで把握できます。詳細については、「[Application Signals](CloudWatch-Application-Monitoring-Sections.md)」を参照してください。
CloudWatch Application Signals は、CloudWatch エージェントを利用して、自動計測されたアプリケーションからメトリクスとトレースを受け取ります。必要に応じて、ルールを適用して高基数を減らしてから、処理済みのテレメトリを CloudWatch に公開できます。エージェント設定ファイルを使用すると、設定を特に Application Signals 向けにカスタマイズしてから CloudWatch エージェントに提供できます。エージェント設定ファイルでは `logs` セクション内の `metrics_collected` セクションに `application_signals` セクションがあり、CloudWatch エージェントが自動計測されたアプリケーションからメトリクスを受け取ることを指定しています。同様に、`traces` セクション内の `traces_collected` セクションに `application_signals` セクションがあり、CloudWatch エージェントが自動計測されたアプリケーションからトレースを受け取ることを指定しています。さらに、ここで説明しているように、必要に応じてカスタム設定ルールを渡して、公開する高基数テレメトリを減らすことができます。
+ Amazon EKS クラスターの場合、[Amazon CloudWatch Observability](install-CloudWatch-Observability-EKS-addon.md) EKS アドオンをインストールすると、デフォルトで CloudWatch エージェントが自動計測されたアプリケーションからメトリクスとトレースの両方を受け取るようになります。カスタム設定ルールを渡すことにした場合は、[(オプション) その他の設定](install-CloudWatch-Observability-EKS-addon.md#install-CloudWatch-Observability-EKS-addon-configuration) で説明しているように、別途必要な設定を行ってそのルールを作成または更新するときに、Amazon EKS アドオンにカスタムエージェント設定を渡します。
+ RedHat for OpenShift on AWS (ROSA) の場合、Helm チャートを使用して CloudWatch エージェントオペレータをインストールすると、CloudWatch エージェントはデフォルトで有効になり、自動計測されたアプリケーションからメトリクスとトレースの両方を受信できるようになります。必要に応じてカスタム設定ルールを渡すようにする場合は、[(オプション) その他の設定](install-CloudWatch-Observability-EKS-addon.md#install-CloudWatch-Observability-EKS-addon-configuration) で説明されているように、Helm チャートを使用してカスタムエージェント設定を渡します。
+ Amazon EC2 などサポートされているその他のプラットフォームの場合、CloudWatch エージェントを起動するには、Application Signals を有効にするようにエージェントを設定しておく必要があります。そのためにはこの後で説明しているように、`application_signals` セクションを指定し、さらに必要に応じてカスタム設定ルールを指定します。
次に、CloudWatch エージェント設定ファイルにあるフィールドのうち、CloudWatch Application Signals に関連するフィールドの概要を示します。
+ `logs`
+ `metrics_collected` - このフィールドには、エージェントにログ収集を指示するセクションを含めることができます。CloudWatch Application Signals と Container Insights のオブザーバビリティを Amazon EKS 向けに強化するといったユースケースを利用できるようになります。
**注記**
以前このセクションは、エージェントが埋め込みメトリクス形式のログを収集するように指定するためにも使用されていました。それらの設定はもう必要ありません。
+ `application_signals` (オプション) CloudWatch Application Signals を有効にして、自動計測されたアプリケーションからメトリクスを受け取るよう指定し、CloudWatch Application Signals を利用しやすくします。
+ `rules` (オプション) 高基数を使用する状況に対応できるように、条件に従ってメトリクスとトレースを選択してアクションを適用する一連のルール。各ルールに次のフィールドの要素を含めることができます。
+ `rule_name` (オプション) ルールの名前。
+ `selectors` (オプション) メトリクスとトレースの一連のディメンションマッチャー。各セレクターでは、以下のフィールドを指定する必要があります。
+ `dimension` `selectors` が空でない場合は必須です。フィルターとして使用するメトリクスとトレースのディメンションを指定します。
+ `match` `selectors` が空でない場合は必須です。指定したディメンションの値のマッチングに使用されるワイルドカードパターン。
+ `action` (オプション) 指定したセレクターに一致したメトリクスとトレースに適用するアクション。`action` の値は、次のキーワードのいずれかにする必要があります。
+ `keep` メトリクスとトレースを `selectors` に一致した場合にのみ CloudWatch に送信するように指定します。
+ `drop` `selectors` に一致するメトリクスとトレースをドロップするように指定します。
+ `replace` `selectors` に一致するメトリクスとトレースのディメンションを置き換えるように指定します。`replacements` セクションに従って置き換えられます。
+ `replacements` `action` が `replace` の場合は必須です。`action` が `replace` の場合に、指定した `selectors` に一致するメトリクスとトレースに適用される一連のディメンションと値のペア。置き換えを行うには、以下のフィールドを指定する必要があります。
+ `target_dimension` `replacements` が空でない場合は必須です。置き換える必要があるディメンションを指定します。
+ `value` `replacements` が空でない場合は必須です。置き換え対象の値 `target_dimension` をこの値に置き換えます。
+ `limiter` (オプション) このセクションを使用して、Application Signals が CloudWatch に送信するメトリクスとディメンションの数を制限し、コストを最適化します。
+ `disabled` (オプション) `true` の場合、メトリクス制限機能は無効になります。デフォルトは `false` です。
+ `drop_threshold` (オプション) 1 つの CloudWatch エージェントがエクスポートできる、1 つのローテーション間隔におけるサービスごとの個別メトリクスの最大数。デフォルトは 500 です。
+ `rotation_interval` (オプション) リミッターが区別してカウントするためにメトリクスレコードをリセットする間隔。これは、一連の数字と単位サフィックスを使用する文字列として表されます。分数がサポートされています。サポートされている単位サフィックスは、`s`、`m`、`h`、`ms`、`us`、`ns` です。デフォルトは 1 時間の `1h` です。
+ `log_dropped_metrics` (オプション) Application Signals のメトリクスがドロップされたときに、エージェントが CloudWatch エージェントログにログを書き込む必要があるかどうかを指定します。デフォルトは `false` です。
**注記**
このログ記録を有効にするには、`agent` セクションの `debug` パラメータも `true` に設定する必要があります。
+ `traces`
+ `traces_collected`
+ `application_signals` オプション。このフィールドを指定すると、CloudWatch Application Signals を利用しやすくするために、CloudWatch エージェントが自動計測されたアプリケーションからメトリクスを受け取るようにできます。
**注記**
カスタムの `application_signals` ルールは、`logs` セクションに含まれている `metrics_collected` セクションの下に指定している場合でも、`traces_collected` セクションに暗黙的に適用されます。同じルールセットがメトリクスとトレースの両方に適用されます。
アクションの異なるルールが複数ある場合は、`keep`、`drop`、`replace` という順序で適用されます。
次に、CloudWatch エージェント設定ファイルでカスタムルールを適用する場合の設定例を示します。
```
{
"logs": {
"metrics_collected": {
"application_signals": {
"rules": [
{
"rule_name": "keep01",
"selectors": [
{
"dimension": "Service",
"match": "pet-clinic-frontend"
},
{
"dimension": "RemoteService",
"match": "customers-service"
}
],
"action": "keep"
},
{
"rule_name": "drop01",
"selectors": [
{
"dimension": "Operation",
"match": "GET /api/customer/owners/*"
}
],
"action": "drop"
},
{
"rule_name": "replace01",
"selectors": [
{
"dimension": "Operation",
"match": "PUT /api/customer/owners/*/pets/*"
},
{
"dimension": "RemoteOperation",
"match": "PUT /owners"
}
],
"replacements": [
{
"target_dimension": "Operation",
"value": "PUT /api/customer/owners/{ownerId}/pets{petId}"
}
],
"action": "replace"
}
]
}
}
},
"traces": {
"traces_collected": {
"application_signals": {}
}
}
}
```
この例の設定ファイルの場合、`rules` は以下のように処理されます。
1. ルール `keep01` により、ディメンション `Service` が `pet-clinic-frontend` で、ディメンション `RemoteService` が `customers-service` であるメトリクスとトレースが保持されます。
1. `keep01` の適用後、処理されたメトリクスとトレースを対象にルール `drop01` が適用され、ディメンション `Operation` が `GET /api/customer/owners/*` であるメトリクスとトレースがドロップされます。
1. `drop01` の適用後、処理されたメトリクスとトレースを対象にルール `replace01` が適用され、ディメンション `Operation` が `PUT /api/customer/owners/*/pets/*` で、ディメンション `RemoteOperation` が `PUT /owners` であるメトリクスとトレースが更新されます。その結果、`Operation` ディメンションが `PUT /api/customer/owners/{ownerId}/pets{petId}` に変更されます。
メトリクスの制限を 100 に変更し、ドロップされたメトリクスのログ記録を有効にして、ローテーション間隔を 2 時間に設定することで、Application Signals の基数を管理する CloudWatch 設定ファイルの完全な例を以下に示します。
```
{
"logs": {
"metrics_collected": {
"application_signals": {
"limiter": {
"disabled": false,
"drop_threshold": 100,
"rotation_interval": "2h",
"log_dropped_metrics": true
}
}
},
"traces": {
"traces_collected": {
"application_signals": {}
}
}
}
}
```
# ネットワークパフォーマンスメトリクスの収集
Elastic Network Adapter (ENA) を使用する Linux で実行されている EC2 インスタンスは、ネットワークパフォーマンスメトリクスを発行します。バージョン 1.246396.0 以降の CloudWatch エージェントでは、これらのネットワークパフォーマンスメトリクスを CloudWatch にインポートできます。これらのネットワークパフォーマンスメトリクスを CloudWatch にインポートすると、CloudWatch カスタムメトリクスとして課金されます。
ENA ドライバーの詳細については、「[Linux インスタンスにおける Elastic Network Adapter (ENA) を使用した拡張ネットワーキングの有効化](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/enhanced-networking-ena.html)」および「[Windows インスタンスにおける Elastic Network Adapter (ENA) を使用した拡張ネットワーキングの有効化](https://docs.aws.amazon.com/AWSEC2/latest/WindowsGuide/enhanced-networking-ena.html)」をご参照ください。
ネットワークパフォーマンスメトリクスの収集の設定方法は、Linux サーバーと Windows サーバーで異なります。
以下の表では、ENA アダプターによって有効化されたこれらのネットワークパフォーマンスメトリクスを示しています。CloudWatch エージェントがこれらのメトリクスを Linux インスタンスから CloudWatch にインポートすると、これらの各メトリクス名の先頭に `ethtool_` が付加されます。
| メトリクス | 説明 |
| --- | --- |
| Linux サーバー上の名前: `bw_in_allowance_exceeded` Windows サーバー上の名前: `Aggregate inbound BW allowance exceeded` | インバウンド集計の帯域幅がインスタンスの最大値を超えたために、キューおよび (または) ドロップされたパケットの数。 このメトリクスは、CloudWatch エージェント設定ファイルの `ethtool` セクションの `metrics_collected` サブセクションにリストされている場合にのみ収集されます。詳細については、[ネットワークパフォーマンスメトリクスの収集](#CloudWatch-Agent-network-performance) を参照してください。 単位: なし |
| Linux サーバー上の名前: `bw_out_allowance_exceeded` Windows サーバー上の名前: `Aggregate outbound BW allowance exceeded` | アウトバウンド集計の帯域幅がインスタンスの最大値を超えたために、キューおよび (または) ドロップされたパケットの数。 このメトリクスは、CloudWatch エージェント設定ファイルの `ethtool` セクションの `metrics_collected` サブセクションにリストされている場合にのみ収集されます。詳細については、[ネットワークパフォーマンスメトリクスの収集](#CloudWatch-Agent-network-performance) を参照してください。 単位: なし |
| Linux サーバー上の名前: `conntrack_allowance_available` Windows サーバー上の名前: `Available connection tracking allowance` | そのインスタンスタイプの Connections Tracked 許容量に達する前にインスタンスが確立できる接続トラッキング数をレポートします。このメトリクスは、バージョン 2.8.1 以降の Elastic Network Adapter (ENA) 用の Linux ドライバーを使用する Nitro ベースの EC2 インスタンス、およびバージョン 2.6.0 以降の Elastic Network Adapter (ENA) 用の Windows ドライバーを使用するコンピュータでのみ使用できます。 このメトリクスは、CloudWatch エージェント設定ファイルの `ethtool` セクションの `metrics_collected` サブセクションにリストされている場合にのみ収集されます。詳細については、[ネットワークパフォーマンスメトリクスの収集](#CloudWatch-Agent-network-performance) を参照してください。 単位: なし |
| Linux サーバー上の名前: `ena_srd_mode` Windows サーバー上の名前: `ena srd mode` | ENA Express のどの機能が有効になっているかを説明します。ENA Express の詳細については、「[Linux インスタンスで ENA Express を使用してネットワークパフォーマンスを向上させる](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ena-express.html)」を参照してください。値は次のとおりです。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/CloudWatch-Agent-network-performance.html) |
| Linux サーバー上の名前: `ena_srd_eligible_tx_pkts` Windows サーバー上の名前: `ena srd eligible tx pkts` | 一定期間内に送信された AWS Scalable Reliable Datagram (SRD) の資格要件を満たすネットワークパケットの数。次のようになります。 [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/AmazonCloudWatch/latest/monitoring/CloudWatch-Agent-network-performance.html) |
| Linux サーバー上の名前: `ena_srd_tx_pkts` Windows サーバー上の名前: `ena srd tx pkts` | 一定期間内に送信した SRD パケット数。 |
| Linux サーバー上の名前: `ena_srd_rx_pkts` Windows サーバー上の名前: `ena srd rx pkts` | 一定期間内に受信した SRD パケット数。 |
| Linux サーバー上の名前: `ena_srd_resource_utilization` Windows サーバー上の名前: `ena srd resource utilization` | インスタンスが消費した同時 SRD 接続の最大許容メモリ使用量の割合。 |
| Linux サーバー上の名前: `linklocal_allowance_exceeded` Windows サーバー上の名前: `Link local packet rate allowance exceeded` | ローカルプロキシサービスへのトラフィックの PPS がネットワークインターフェイスの最大値を超えたためにドロップされたパケットの数。これは、DNS サービス、インスタンスメタデータサービス、および Amazon Time Sync Service へのトラフィックに影響しますが、カスタム DNS レゾルバへのトラフィックには影響しません。 このメトリクスは、CloudWatch エージェント設定ファイルの `ethtool` セクションの `metrics_collected` サブセクションにリストされている場合にのみ収集されます。詳細については、[ネットワークパフォーマンスメトリクスの収集](#CloudWatch-Agent-network-performance) を参照してください。 単位: なし |
| Linux サーバー上の名前: `pps_allowance_exceeded` Windows サーバー上の名前: `PPS allowance exceeded` | 双方向 PPS がインスタンスの最大値を超えたために、キューおよび (または) ドロップされたパケットの数。 このメトリクスは、CloudWatch エージェント設定ファイルの `ethtool` セクションの `metrics_collected` サブセクションにリストされている場合にのみ収集されます。詳細については、[ネットワークパフォーマンスメトリクスの収集](#CloudWatch-Agent-network-performance) を参照してください。 単位: なし |
## Linux の設定
Linux サーバーでは、*ethtool プラグイン*を使用すると、ネットワークパフォーマンスメトリクスを CloudWatch にインポートできます。
ethtool は、Linux サーバー上のイーサネットデバイスに関する統計を収集できる標準の Linux ユーティリティです。収集される統計情報は、ネットワークデバイスとドライバーによって異なります。これらの統計情報の例には、`tx_cnt`、`rx_bytes`、`tx_errors`、`align_errors` などがあります。CloudWatch エージェントで ethtool プラグインを使用する場合、このセクションで前述した EC2 ネットワークパフォーマンスメトリクスとともに、これらの統計を CloudWatch にインポートすることもできます。
**ヒント**
オペレーティングシステムとネットワークデバイスで利用可能な統計を確認するには、`ethtool –S` コマンドを使用します。
CloudWatch エージェントがメトリクスを CloudWatch にインポートすると、インポートされたすべてのメトリクスの名前に `ethtool_` プレフィックスが追加されます。したがって、標準の ethtool 統計 `rx_bytes` は CloudWatch で `ethtool_rx_bytes` として呼び出され、EC2 ネットワークパフォーマンスメトリクス `bw_in_allowance_exceeded` は CloudWatch で `ethtool_bw_in_allowance_exceeded` として呼び出されます。
Linux サーバーで ethtool メトリクスをインポートするには、CloudWatch エージェント設定ファイルの `ethtool` セクションに `metrics_collected` セクションを追加します。`ethtool` セクションでは、次のサブセクションを含めることができます。
+ **interface\$1include** – このセクションを含めると、エージェントは、このセクションにリストされている名前を持つインターフェイスからのみメトリクスを収集します。このセクションを省略すると、`interface_exclude` にリストされていないすべてのイーサネットインターフェイスからメトリクスが収集されます。
デフォルトのイーサネットインターフェイスは `eth0` です。
+ **interface\$1exclude** – このセクションを含める場合は、メトリクスを収集しないイーサネットインターフェイスをリストします。
ethtool プラグインは、常にループバックインターフェイスを無視します。
+ **metrics\$1include** – このセクションには、CloudWatch にインポートするメトリクスがリストされます。ethtool によって収集された標準統計情報と、Amazon EC2 高解像度ネットワークメトリクスの両方を含めることができます。
以下の例では、CloudWatch エージェント設定ファイルの一部が表示されています。この設定では、インターフェイスから標準の ethtool メトリクス `rx_packets` および `tx_packets`、ならびに `eth1` インターフェイスのみから Amazon EC2 ネットワークパフォーマンスメトリクスが収集されます。
CloudWatch エージェント設定ファイルの詳細については、「[CloudWatch エージェント設定ファイルを手動で作成または編集する](CloudWatch-Agent-Configuration-File-Details.md)」を参照してください。
```
{
"metrics": {
"append_dimensions": {
"InstanceId": "${aws:InstanceId}"
},
"metrics_collected": {
"ethtool": {
"interface_include": [
"eth1"
],
"metrics_include": [
"bw_in_allowance_exceeded",
"bw_out_allowance_exceeded",
"conntrack_allowance_exceeded",
"linklocal_allowance_exceeded",
"pps_allowance_exceeded"
]
}
}
}
}
```
## Windows セットアップ
Windows サーバーでは、ネットワークパフォーマンスメトリクスは、CloudWatch エージェントが既にメトリクスを収集している Windows パフォーマンスカウンターから入手できます。そのため、Windows サーバーからこれらのメトリックを収集するのにプラグインは必要ありません。
次は、Windows からネットワークパフォーマンスメトリクスを収集するためのサンプル設定ファイルです。CloudWatch エージェント設定ファイルの編集の詳細については、「[CloudWatch エージェント設定ファイルを手動で作成または編集する](CloudWatch-Agent-Configuration-File-Details.md)」を参照してください。
```
{
"metrics": {
"append_dimensions": {
"InstanceId": "${aws:InstanceId}"
},
"metrics_collected": {
"ENA Packets Shaping": {
"measurement": [
"Aggregate inbound BW allowance exceeded",
"Aggregate outbound BW allowance exceeded",
"Connection tracking allowance exceeded",
"Link local packet rate allowance exceeded",
"PPS allowance exceeded"
],
"metrics_collection_interval": 60,
"resources": [
"*"
]
}
}
}
}
```
## ネットワークパフォーマンスメトリクスの表示
ネットワークパフォーマンスメトリクスを CloudWatch にインポートした後、これらのメトリクスを時系列グラフとして表示し、これらのメトリクスをモニターリングし、指定したしきい値に違反した場合に通知できるアラームを作成できます。以下の手順では、ethtool メトリクスを時系列グラフとして表示する方法を示します。アラームの設定の詳細については、「[Amazon CloudWatch でのアラームの使用](CloudWatch_Alarms.md)」を参照してください。
これらのメトリクスはすべて集計カウンターであるため、`RATE(METRICS())` などの CloudWatch メトリクス数学関数を使用して、これらのメトリクスのレートをグラフで計算したり、アラームを設定したりできます。メトリクス数学関数の詳細については、「[CloudWatch メトリクスでの数式の使用](using-metric-math.md)」を参照してください。
**ネットワークパフォーマンスメトリクスを CloudWatch コンソールに表示するには**
1. CloudWatch コンソールの [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/) を開いてください。
1. ナビゲーションペインで [**Metrics (メトリクス)**] を選択してください。
1. エージェントによって収集されたメトリクスの名前空間を選択します。デフォルトでは、これは **CWAgent** ですが、CloudWatch エージェント設定ファイルで別の名前空間を指定している場合があります。
1. メトリクスのディメンション (例: **インスタンス別メトリクス**) を選択します。
1. [**All metrics**] タブには、名前空間内のそのディメンションのメトリクスがすべて表示されます。以下の操作を行うことができます。
1. メトリクスをグラフ表示するには、メトリクスの横にあるチェックボックスを選択します。すべてのメトリクスを選択するには、テーブルの見出し行にあるチェックボックスを選択します。
1. テーブルを並べ替えるには、列見出しを使用します。
1. リソースでフィルタするには、リソース ID を選択し、[**Add to search**] (検索に追加) を選択します。
1. メトリクスでフィルターするには、メトリクス名を選択し、**[Add to search]** (検索に追加) を選択します。
1. (オプション) このグラフを CloudWatch ダッシュボードに追加するには、[**Actions**] (アクション)、[**Add to dashboard**] (ダッシュボードに追加) の順に選択します。
# Amazon EBS NVMe ドライバーメトリクスを収集する
CloudWatch エージェントが Amazon EC2 インスタンスにアタッチされた Amazon EBS ボリュームの AWS NVMe ドライバーメトリクスを収集するには、CloudWatch エージェント設定ファイルの `metrics_collected` セクション内に `diskio` セクションを追加します。
さらに、CloudWatch エージェントバイナリは、アタッチされた Amazon EBS ボリュームからメトリクスを収集するための、NVMe ドライバーデバイスに対する `ioctl` アクセス許可が必要です。
次のメトリクスを収集できます。
| メトリクス | CloudWatch のメトリクス名 | 説明 |
| --- | --- | --- |
| `ebs_total_read_ops` | `diskio_ebs_total_read_ops` | 完了した読み取りオペレーションの合計回数。 |
| `ebs_total_write_ops` | `diskio_ebs_total_write_ops` | 完了した書き込みオペレーションの合計回数。 |
| `ebs_total_read_bytes` | `diskio_ebs_total_read_bytes` | 転送された読み取りバイトの合計数。 |
| `ebs_total_write_bytes` | `diskio_ebs_total_write_bytes` | 転送された書き込みバイトの合計数。 |
| `ebs_total_read_time` | `diskio_ebs_total_read_time` | 完了したすべての読み取りオペレーションで費やされた合計時間 (マイクロ秒単位)。 |
| `ebs_total_write_time` | `diskio_ebs_total_write_time` | 完了したすべての書き込みオペレーションで費やされた合計時間 (マイクロ秒単位)。 |
| `ebs_volume_performance_exceeded_iops` | `diskio_ebs_volume_performance_exceeded_iops` | IOPS 需要がボリュームのプロビジョンド IOPS パフォーマンスを超えた合計時間 (マイクロ秒単位)。 |
| `ebs_volume_performance_exceeded_tp` | `diskio_ebs_volume_performance_exceeded_tp` | スループット需要がボリュームのプロビジョンドスループットパフォーマンスを超えた合計時間 (マイクロ秒単位)。 |
| `ebs_ec2_instance_performance_exceeded_iops` | `diskio_ebs_ec2_instance_performance_exceeded_iops` | EBS ボリュームがアタッチされた Amazon EC2 インスタンスの最大 IOPS パフォーマンスを超えた合計時間 (マイクロ秒単位)。 |
| `ebs_ec2_instance_performance_exceeded_tp` | `diskio_ebs_ec2_instance_performance_exceeded_tp` | EBS ボリュームがアタッチされた Amazon EC2 インスタンスの最大スループットパフォーマンスを超えた合計時間 (マイクロ秒単位)。 |
| `ebs_volume_queue_length` | `diskio_ebs_volume_queue_length` | 完了を待機している読み取りおよび書き込みオペレーションの数。 |
# Amazon EC2 インスタンスストアボリューム NVMe ドライバーメトリクスを収集する
CloudWatch エージェントが Amazon EC2 インスタンスにアタッチされたインスタンスストアボリュームの AWS NVMe ドライバーメトリクスを収集するには、CloudWatch エージェント設定ファイルの `metrics_collected` セクション内に `diskio` セクションを追加します。
さらに、CloudWatch エージェントバイナリには、アタッチされたインスタンスストアボリュームからメトリクスを収集するための、NVMe ドライバーデバイスに対する `ioctl` アクセス許可が必要です。
次のメトリクスを収集できます。
| メトリクス | CloudWatch のメトリクス名 | 説明 |
| --- | --- | --- |
| `instance_store_total_read_ops` | `diskio_instance_store_total_read_ops` | 完了した読み取りオペレーションの合計回数。 |
| `instance_store_total_write_ops` | `diskio_instance_store_total_write_ops` | 完了した書き込みオペレーションの合計回数。 |
| `instance_store_total_read_bytes` | `diskio_instance_store_total_read_bytes` | 転送された読み取りバイトの合計数。 |
| `instance_store_total_write_bytes` | `diskio_instance_store_total_write_bytes` | 転送された書き込みバイトの合計数。 |
| `instance_store_total_read_time` | `diskio_instance_store_total_read_time` | 完了したすべての読み取りオペレーションで費やされた合計時間 (マイクロ秒単位)。 |
| `instance_store_total_write_time` | `diskio_instance_store_total_write_time` | 完了したすべての書き込みオペレーションで費やされた合計時間 (マイクロ秒単位)。 |
| `instance_store_performance_exceeded_iops` | `diskio_instance_store_performance_exceeded_iops` | IOPS 需要がボリュームの IOPS 最大パフォーマンスを超えた合計時間 (マイクロ秒単位)。 |
| `instance_store_performance_exceeded_tp` | `diskio_instance_store_performance_exceeded_tp` | スループット需要がボリュームの最大スループットパフォーマンスを超えた合計時間 (マイクロ秒単位)。 |
| `instance_store_volume_queue_length` | `diskio_instance_store_volume_queue_length` | 完了を待機している読み取りおよび書き込みオペレーションの数。 |
# NVIDIA GPU メトリクスを収集する
CloudWatch エージェントを使用して、Linux サーバーから NVIDIA GPU メトリクスを収集できます。これを設定するには、CloudWatch エージェント設定ファイルの `metrics_collected` セクション内に `nvidia_gpu` セクションを追加します。詳細については、「[Linux のセクション](CloudWatch-Agent-Configuration-File-Details.md#CloudWatch-Agent-Linux-section)」を参照してください。
さらに、インスタンスには NVIDIA ドライバーがインストールされている必要があります。NVIDIA ドライバーは、一部の Amazon マシンイメージ (AMI) にプリインストールされています。それ以外の場合は、ドライバーを手動でインストールできます。詳細については、「[Linux インスタンスへの NVIDIA ドライバーのインストール](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/install-nvidia-driver.html)」を参照してください。
次のメトリクスを収集できます。これらのメトリクススはすべて CloudWatch `Unit` なしで収集されますが、CloudWatch エージェント設定ファイルにパラメータを追加することで、各メトリクスの単位を指定できます。詳細については、「[Linux のセクション](CloudWatch-Agent-Configuration-File-Details.md#CloudWatch-Agent-Linux-section)」を参照してください。
| メトリクス | CloudWatch のメトリクス名 | 説明 |
| --- | --- | --- |
| `utilization_gpu` | `nvidia_smi_utilization_gpu` | GPU 上の 1 つ以上のカーネルが実行されていた過去のサンプル期間における時間の割合。 |
| `temperature_gpu` | `nvidia_smi_temperature_gpu` | コア GPU 温度 (摂氏)。 |
| `power_draw` | `nvidia_smi_power_draw` | ボード全体で最後に測定された電力消費量 (ワット)。 |
| `utilization_memory` | `nvidia_smi_utilization_memory` | グローバル (デバイス) メモリの読み取りまたは書き込みが行われていた過去のサンプル期間における時間の割合。 |
| `fan_speed` | `nvidia_smi_fan_speed` | デバイスのファンが現在意図している最大ファン速度に対する割合。 |
| `memory_total` | `nvidia_smi_memory_total` | レポートされた合計メモリ (MB)。 |
| `memory_used` | `nvidia_smi_memory_used` | 使用済みメモリ (MB)。 |
| `memory_free` | `nvidia_smi_memory_free` | 利用可能なメモリ (MB)。 |
| `pcie_link_gen_current` | `nvidia_smi_pcie_link_gen_current` | 現在のリンク生成。 |
| `pcie_link_width_current` | `nvidia_smi_pcie_link_width_current` | 現在のリンク幅。 |
| `encoder_stats_session_count` | `nvidia_smi_encoder_stats_session_count` | 現在のエンコーダセッション数。 |
| `encoder_stats_average_fps` | `nvidia_smi_encoder_stats_average_fps` | エンコードフレーム/秒の移動平均。 |
| `encoder_stats_average_latency` | `nvidia_smi_encoder_stats_average_latency` | エンコードレイテンシーの移動平均 (マイクロ秒)。 |
| `clocks_current_graphics` | `nvidia_smi_clocks_current_graphics` | グラフィックス (シェーダー) クロックの現在の周波数。 |
| `clocks_current_sm` | `nvidia_smi_clocks_current_sm` | Streaming Multiprocessor (SM) クロックの現在の周波数。 |
| `clocks_current_memory` | `nvidia_smi_clocks_current_memory` | メモリクロックの現在の周波数。 |
| `clocks_current_video` | `nvidia_smi_clocks_current_video` | 動画 (エンコーダとデコーダ) クロックの現在の周波数。 |
これらのメトリクスはすべて、次のディメンションで収集されます。
| ディメンション | 説明 |
| --- | --- |
| `index` | このサーバー上の GPU の一意の識別子。デバイスの NVIDIA Management Library (NVML) インデックスを表します。 |
| `name` | GPU の種類。例: `NVIDIA Tesla A100` |
| `arch` | サーバーのアーキテクチャ |
# Java Management Extensions (JMX) メトリクスの収集
CloudWatch エージェントを使用し、Java アプリケーションから Java Management Extensions (JMX) メトリクスを収集できます。
CloudWatch エージェントは、次のバージョンからこれらのメトリクスの収集をサポートしています。
+ JVM 8 以降
+ Kafka 0.8.2.x 以降
+ Tomcat 9、10.1、11 (ベータ)
------
#### [ Amazon EC2 ]
**JVM インスタンスで JMX を有効にする方法**
CloudWatch エージェントが JMX メトリクスを収集できるようにするには、アプリケーションの JVM が `com.sun.management.jmxremote.port` システムプロパティを使用してポートにバインドする必要があります。
```
java -Dcom.sun.management.jmxremote.port=port-number -jar example.jar
```
詳細やその他の設定については、「[JMX ドキュメント](https://docs.oracle.com/en/java/javase/17/management/monitoring-and-management-using-jmx-technology.html)」を参照してください。
------
#### [ Amazon EKS ]
**Java アプリケーションポッドで JMX を有効にする方法**
CloudWatch Observability EKS アドオンを使用するとき、注釈を使用して JMX メトリクスを有効にする方法を管理できます。詳細については、「[Amazon CloudWatch Observability EKS アドオンまたは Helm チャートを使用して CloudWatch エージェントをインストールする](install-CloudWatch-Observability-EKS-addon.md)」を参照してください。ワークロードから JMX メトリクスを収集できるようにするには、`PodTemplate` セクションのワークロードマニフェストファイルに次の注釈を追加します。
+ `instrumentation.opentelemetry.io/inject-java: "true"`
+ 次の 1 つ以上。
+ JVM メトリクスの場合: `cloudwatch.aws.amazon.com/inject-jmx-jvm: "true"`
+ Kafka ブローカーメトリクスの場合: `cloudwatch.aws.amazon.com/inject-jmx-kafka: "true"`
+ Kafka コンシューマーメトリクスの場合: `cloudwatch.aws.amazon.com/inject-jmx-kafka-consumer: "true"`
+ Kafka プロデューサーメトリクスの場合: `cloudwatch.aws.amazon.com/inject-jmx-kafka-producer: "true"`
+ Tomcat メトリクスの場合: `cloudwatch.aws.amazon.com/inject-jmx-tomcat: "true"`
------
JMX メトリクスの収集を開始するには、CloudWatch エージェント設定ファイルの `metrics_collected` セクション内に `jmx` セクションを追加します。`jmx` セクションには、次のフィールドを含めることができます。
+ `jvm` - オプション。インスタンスから Java 仮想マシン (JVM) メトリクスを取得するように指定します。詳細については、「[JVM メトリクスの収集](#CloudWatch-Agent-JVM-metrics)」を参照してください。
このセクションには、次のフィールドを含めることができます。
+ `measurement` – 収集する JVM メトリクスの配列を指定します。ここで使用できる値のリストについては、[JVM メトリクスの収集](#CloudWatch-Agent-JVM-metrics) の表の **[Metric]** (メトリクス) 列を参照してください。
各メトリクスのエントリでは、必要に応じて次のいずれかまたは両方を指定できます。
+ `rename` – このメトリクスに別の名前を指定します。
+ `unit` – メトリクスのデフォルト単位を上書きして、このメトリクスに使用する単位を指定します。指定する単位は、「[MetricDatum](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_MetricDatum.html)」の `Unit` に関する説明にリストされている有効な CloudWatch メトリクス単位でなければなりません。
+ `kafka` - オプション。インスタンスから Apache Kafka ブローカーメトリクスを取得するように指定します。詳細については、「[Kafka メトリクスの収集](#CloudWatch-Agent-Kafka-metrics)」を参照してください。
このセクションには、次のフィールドを含めることができます。
+ `measurement` – 収集する Kafka ブローカーメトリクスの配列を指定します。ここで使用できる値のリストについては、[Kafka メトリクスの収集](#CloudWatch-Agent-Kafka-metrics) の最初の表にある **[メトリクス]** 列を参照してください。
各メトリクスのエントリでは、必要に応じて次のいずれかまたは両方を指定できます。
+ `rename` – このメトリクスに別の名前を指定します。
+ `unit` – メトリクスのデフォルト単位を上書きして、このメトリクスに使用する単位を指定します。指定する単位は、「[MetricDatum](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_MetricDatum.html)」の `Unit` に関する説明にリストされている有効な CloudWatch メトリクス単位でなければなりません。
+ `kafka-consumer` - オプション。インスタンスから Apache Kafka コンシューマーメトリクスを取得するように指定します。詳細については、「[Kafka メトリクスの収集](#CloudWatch-Agent-Kafka-metrics)」を参照してください。
このセクションには、次のフィールドを含めることができます。
+ `measurement` – 収集する Kafka ブローカーメトリクスの配列を指定します。ここで使用できる値のリストについては、[Kafka メトリクスの収集](#CloudWatch-Agent-Kafka-metrics) の 2 番目の表にある **[メトリクス]** 列を参照してください。
各メトリクスのエントリでは、必要に応じて次のいずれかまたは両方を指定できます。
+ `rename` – このメトリクスに別の名前を指定します。
+ `unit` – メトリクスのデフォルト単位を上書きして、このメトリクスに使用する単位を指定します。指定する単位は、「[MetricDatum](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_MetricDatum.html)」の `Unit` に関する説明にリストされている有効な CloudWatch メトリクス単位でなければなりません。
+ `kafka-producer` - オプション。インスタンスから Apache Kafka プロデューサーメトリクスを取得するように指定します。詳細については、「[Kafka メトリクスの収集](#CloudWatch-Agent-Kafka-metrics)」を参照してください。
このセクションには、次のフィールドを含めることができます。
+ `measurement` – 収集する Kafka ブローカーメトリクスの配列を指定します。ここで使用できる値のリストについては、[Kafka メトリクスの収集](#CloudWatch-Agent-Kafka-metrics) の 3 番目の表にある **[メトリクス]** 列を参照してください。
各メトリクスのエントリでは、必要に応じて次のいずれかまたは両方を指定できます。
+ `rename` – このメトリクスに別の名前を指定します。
+ `unit` – メトリクスのデフォルト単位を上書きして、このメトリクスに使用する単位を指定します。指定する単位は、「[MetricDatum](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_MetricDatum.html)」の `Unit` に関する説明にリストされている有効な CloudWatch メトリクス単位でなければなりません。
+ `tomcat` - オプション。インスタンスから Tomcat メトリクスを取得するように指定します。詳細については、「[Tomcat メトリクスの収集](#CloudWatch-Agent-Tomcat-metrics)」を参照してください。
このセクションには、次のフィールドを含めることができます。
+ `measurement` – 収集する Tomcat メトリクスの配列を指定します。ここで使用できる値のリストについては、[Tomcat メトリクスの収集](#CloudWatch-Agent-Tomcat-metrics) の表の **[Metric]** (メトリクス) 列を参照してください。
各メトリクスのエントリでは、必要に応じて次のいずれかまたは両方を指定できます。
+ `rename` – このメトリクスに別の名前を指定します。
+ `unit` – メトリクスのデフォルト単位を上書きして、このメトリクスに使用する単位を指定します。指定する単位は、「[MetricDatum](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_MetricDatum.html)」の `Unit` に関する説明にリストされている有効な CloudWatch メトリクス単位でなければなりません。
`jmx` セクションには、オプションの `append_dimensions` フィールドを含めることもできます。
+ `append_dimensions` - オプション。process メトリクスにのみ使用する追加のディメンション。このフィールドを指定した場合、エージェントにより収集されるすべてのタイプのメトリクスに使用される `append_dimensions` フィールドで指定されたディメンションに加えて使用されます。
**次のフィールドは Amazon EC2 専用です。**
+ `endpoint` – JMX クライアントが接続するアドレス。形式は `ip:port` です。エンドポイントが localhost ではない場合、パスワード認証および SSL を有効にする必要があります。
+ `metrics_collection_interval` - オプション。設定ファイルの `metrics_collection_interval` セクションで指定されたグローバルな `agent` を上書きして、processes メトリクスを収集する頻度を指定します。
この値は数秒で指定されます。例えば、10 と設定するとメトリクスが 10 秒ごとに収集されるようになり、300 と設定するとメトリクスが 5 分ごとに収集されように指定されます。
この値を 60 秒未満に設定した場合、各メトリクスは高解像度メトリクスとして収集されます。詳細については、「[高解像度のメトリクス](publishingMetrics.md#high-resolution-metrics)」を参照してください。
JMX がパスワード認証またはリモートアクセス用の SSL で有効になっていた場合、次のフィールドを使用できます。
+ `password_file` - オプション。パスワードへのキーの Java プロパティファイルを指定します。ファイルは読み取り専用であり、CloudWatch エージェントを実行しているユーザーに制限する必要があります。パスワード認証が有効になっている場合、`com.sun.management.jmxremote.password.file` プロパティで指定された JMX パスワードファイルのエントリと同じユーザー名およびパスワードのペアが必要です。SSL が有効になっている場合、`keystore` および `truststore` のエントリが必要であり、それぞれ `javax.net.ssl.keyStorePassword` および `javax.net.ssl.trustStorePassword` に対応します。
+ `username` – パスワード認証が有効になっている場合、指定されたパスワードファイルのユーザー名と一致するユーザー名を指定します。
+ `keystore_path` – SSL が有効になっている場合、Java キーストアへのフルパスを指定します。このキーストアは、プライベートキーおよびパブリックキーへの証明書で構成されます。`javax.net.ssl.keyStore` プロパティに対応します。
+ `keystore_type` – SSL が有効になっている場合、使用されているキーストアの種類を指定します。`javax.net.ssl.keyStoreType` プロパティに対応します。
+ `truststore_path` – SSL が有効になっている場合、Java トラストストアへのフルパスを指定します。これには、リモート JMX サーバーのパブリック証明書が含まれている必要があります。`javax.net.ssl.trustStore` プロパティに対応します。
+ `truststore_type` – SSL が有効になっている場合、使用されているトラストストアの種類を指定します。`javax.net.ssl.trustStoreType` プロパティに対応します。
+ `remote_profile` - オプション。サポートされている JMX リモートプロファイルは、`SASL/PLAIN`、`SASL/DIGEST-MD5`、`SASL/CRAM-MD5` の SASL プロファイルと組み合わせた TLS です。`SASL/PLAIN`、`SASL/DIGEST-MD5`、`SASL/CRAM-MD5`、`TLS SASL/PLAIN`、`TLS SASL/DIGEST-MD5`、`TLS SASL/CRAM-MD5` のいずれかである必要があります。
+ `realm` - オプション。リモートプロファイル `SASL/DIGEST-MD5` が必要な領域。
+ `registry_ssl_enabled` – RMI レジストリ認証が有効になっている場合。JVM が `com.sun.management.jmxremote.registry.ssl=true` で設定されている場合、true に設定します。
+ `insecure` エージェントがローカルホスト以外のエンドポイント用に設定されている場合、`true` に設定して必要な検証をオプトアウトします。
次の内容は、CloudWatch エージェント設定ファイルの `jmx` セクションです。
```
{
"metrics": {
"metrics_collected": {
"jmx": [
{
"endpoint": "remotehost:1314",
"jvm": {
"measurement": [
"jvm.memory.heap.init",
"jvm.memory.nonheap.used"
]
},
"kafka": {
"measurement": [
"kafka.request.count",
{
"name": "kafka.message.count",
"rename": "KAFKA_MESSAGE_COUNT",
"unit": "Count"
}
]
},
"username": "cwagent",
"keystore_path": "/path/to/keystore",
"keystore_type": "PKCS12",
"truststore_path": "/path/to/truststore",
"truststore_type": "PKCS12"
},
{
"endpoint": "localhost:1315",
"kafka-producer": {
"measurement": [
"kafka.producer.request-rate"
]
},
"append_dimensions": {
"service.name": "kafka/1"
}
}
]
}
}
}
```
## JVM メトリクスの収集
CloudWatch エージェントを使用して Java 仮想マシン (JVM) メトリクスを収集できます。これを設定するには、CloudWatch エージェント設定ファイルの `jmx` セクション内に `jvm` セクションを追加します。
次のメトリクスを収集できます。
| メトリクス | ディメンション | 説明 |
| --- | --- | --- |
| `jvm.classes.loaded` | [DEFAULT] | ロードされたクラスの合計数。 **単位:** なし **有意義な統計:** 最小、最大、平均 |
| `jvm.gc.collections.count` | [DEFAULT]、`name` | 発生したガベージコレクションの合計数。 **単位:** なし **有意義な統計:** 最小、最大、平均 |
| `jvm.gc.collections.elapsed` | [DEFAULT]、`name` | 蓄積ガベージコレクションのおおよその経過時間。 **単位:** ミリ秒 **有意義な統計:** 最小、最大、平均 |
| `jvm.memory.heap.init` | [DEFAULT] | JVM がヒープのためにオペレーティングシステムにリクエストするメモリの初期量。 **単位:** バイト **有意義な統計:** 最小、最大、平均 |
| `jvm.memory.heap.max` | [DEFAULT] | ヒープに使用できるメモリの最大量。 **単位:** バイト **有意義な統計:** 最大 |
| `jvm.memory.heap.used` | [DEFAULT] | 現在のヒープメモリの使用量。 **単位:** バイト **有意義な統計:** 最小、最大、平均 |
| `jvm.memory.heap.committed` | [DEFAULT] | ヒープに使用できることが保証されているメモリの量。 **単位:** バイト **有意義な統計:** 最小、最大、平均 |
| `jvm.memory.nonheap.init` | [DEFAULT] | JVM がヒープ以外の目的でオペレーティングシステムにリクエストするメモリの初期量。 **単位:** バイト **有意義な統計:** 最小、最大、平均 |
| `jvm.memory.nonheap.max` | [DEFAULT] | ヒープ以外の目的で使用できるメモリの最大量。 **単位:** バイト **有意義な統計:** 最大 |
| `jvm.memory.nonheap.used` | [DEFAULT] | ヒープ以外の現在のメモリ使用量。 **単位:** バイト **有意義な統計:** 最小、最大、平均 |
| `jvm.memory.nonheap.committed` | [DEFAULT] | ヒープ以外の目的で使用できることが保証されているメモリの量。 **単位:** バイト **有意義な統計:** 最小、最大、平均 |
| `jvm.memory.pool.init` | [DEFAULT]、`name` | JVM がメモリプール用にオペレーティングシステムにリクエストするメモリの初期量。 **単位:** バイト **有意義な統計:** 最小、最大、平均 |
| `jvm.memory.pool.max` | [DEFAULT]、`name` | メモリプールに使用できるメモリの最大量。 **単位:** バイト **有意義な統計:** 最大 |
| `jvm.memory.pool.used` | [DEFAULT]、`name` | 現在のメモリプールのメモリ使用量。 **単位:** バイト **有意義な統計:** 最小、最大、平均 |
| `jvm.memory.pool.committed` | [DEFAULT]、`name` | メモリプールで使用できることが保証されているメモリの量。 **単位:** バイト **有意義な統計:** 最小、最大、平均 |
| `jvm.threads.count` | [DEFAULT] | 現在のスレッドの数。 **単位:** なし **有意義な統計:** 最小、最大、平均 |
JVM メトリクスは次のディメンションで収集されます。
| ディメンション | 説明 |
| --- | --- |
| [DEFAULT] | デフォルトで Amazon EC2 では、`metrics` セクションの `append_dimensions` フィールドを使用している場合を除き、ホストは CloudWatch エージェントによって収集されるメトリクスのディメンションとしても発行されます。詳細については、「[CloudWatch エージェント設定ファイルを手動で作成または編集する](CloudWatch-Agent-Configuration-File-Details.md)」のエージェントセクションの「`omit_hostname`」を参照してください。 Amazon EKS では、k8s に関連したコンテキストはメトリクスのディメンション (`k8s.container.name`、`k8s.deployment.name`、`k8s.namespace.name`、`k8s.node.name`、`k8s.pod.name`、`k8s.replicaset.name`) としても公開されます。これらは `aggregation_dimensions` フィールドを使用してフィルタリングできます。 |
| `name` | `jvm.gc.collections` メトリクスの場合、値はガベージコレクター名です。 `jvm.memory.pool` メトリクスの場合、値はメモリプール名です。 |
## Kafka メトリクスの収集
CloudWatch エージェントを使用して Apache Kafka メトリクスを収集できます。これを設定するには、CloudWatch エージェント設定ファイルの `jmx` セクション内に次のサブセクションを 1 つ以上追加します。
+ `kafka` セクションを使用して Kafka ブローカーメトリクスを収集します。
+ `kafka-consumer` セクションを使用して Kafka コンシューマーメトリクスを収集します。
+ `kafka-producer` セクションを使用して Kafka プロデューサーメトリクスを収集します。
**Kafka ブローカーメトリクス**
次のメトリクスは Kafka ブローカー用に収集できます。
| メトリクス | ディメンション | 説明 |
| --- | --- | --- |
| `kafka.message.count` | [DEFAULT] | Kafka ブローカーが受信するメッセージの数。 **単位:** なし **有意義な統計:** 最小、最大、平均 |
| `kafka.request.count` | [DEFAULT]、`type` | Kafka ブローカーが受信するリクエストの数。 **単位:** なし **有意義な統計:** 最小、最大、平均 |
| `kafka.request.failed` | [DEFAULT]、`type` | 障害が発生した Kafka ブローカーへのリクエストの数。 **単位:** なし **有意義な統計:** 最小、最大、平均 |
| `kafka.request.time.total` | [DEFAULT]、`type` | Kafka ブローカーがサービスリクエストにかかった合計時間。 **単位:** ミリ秒 **有意義な統計:** 最小、最大、平均 |
| `kafka.request.time.50p` | [DEFAULT]、`type` | Kafka ブローカーがサービスリクエストにかかった 50 パーセンタイルの時間。 **単位:** ミリ秒 **有意義な統計:** 最小、最大、平均 |
| `kafka.request.time.99p` | [DEFAULT]、`type` | Kafka ブローカーがサービスリクエストにかかった 99 パーセンタイルの時間。 **単位:** ミリ秒 **有意義な統計:** 最小、最大、平均 |
| `kafka.request.time.avg` | [DEFAULT]、`type` | Kafka ブローカーがサービスリクエストにかかった平均時間。 **単位:** ミリ秒 **有意義な統計:** 平均 |
| `kafka.network.io` | [DEFAULT]、`state` | Kafka ブローカーによって受信または送信されたバイト数。 **単位:** バイト **有意義な統計:** 最小、最大、平均 |
| `kafka.purgatory.size` | [DEFAULT]、`type` | 処理待ち状態で待機中のリクエストの数。 **単位:** なし **有意義な統計:** 最小、最大、平均 |
| `kafka.partition.count` | [DEFAULT] | Kafta ブローカーのパーティションの数。 **単位:** なし **有意義な統計:** 最小、最大、平均 |
| `kafka.partition.offline` | [DEFAULT] | オフラインのパーティションの数。 **単位:** なし **有意義な統計:** 最小、最大、平均 |
| `kafka.partition.under_replicated` | [DEFAULT] | レプリケートが不十分なパーティションの数。 **単位:** なし **有意義な統計:** 最小、最大、平均 |
| `kafka.isr.operation.count` | [DEFAULT]、`operation` | 同期レプリカの縮小および展開オペレーションの数。 **単位:** なし **有意義な統計:** 最小、最大、平均 |
| `kafka.max.lag` | [DEFAULT] | フォロワーレプリカとリーダーレプリカ間のメッセージの最大遅延。 **単位:** なし **有意義な統計:** 最大 |
| `kafka.controller.active.count` | [DEFAULT] | ブローカーでアクティブなコントローラーの数。 **単位:** なし **有意義な統計:** 最小、最大、平均 |
| `kafka.leader.election.rate` | [DEFAULT] | リーダー選出レート。これが増加すると、ブローカーの障害を示します。 **単位:** なし **有意義な統計:** 最小、最大、平均 |
| `kafka.unclean.election.rate` | [DEFAULT] | クリーンでないリーダー選出レート。これが増加すると、ブローカーの障害を示します。 **単位:** なし **有意義な統計:** 最小、最大、平均 |
| `kafka.request.queue` | [DEFAULT] | リクエストキューのサイズ。 **単位:** なし **有意義な統計:** 最小、最大、平均 |
| `kafka.logs.flush.time.count` | [DEFAULT] | ログのフラッシュ数。 **単位:** ミリ秒 **有意義な統計:** 最小、最大、平均 |
| `kafka.logs.flush.time.median` | [DEFAULT] | ログフラッシュカウントの 50 パーセンタイル値。 **単位:** ミリ秒 **有意義な統計:** 最小、最大、平均 |
| `kafka.logs.flush.time.99p` | [DEFAULT] | ログフラッシュカウントの 99 パーセンタイル値。 **単位:** ミリ秒 **有意義な統計:** 最小、最大、平均 |
Kafka ブローカーのメトリクスは次のディメンションで収集されます。
| ディメンション | 説明 |
| --- | --- |
| [DEFAULT] | デフォルトで Amazon EC2 では、`metrics` セクションの `append_dimensions` フィールドを使用している場合を除き、ホストは CloudWatch エージェントによって収集されるメトリクスのディメンションとしても発行されます。詳細については、「[CloudWatch エージェント設定ファイルを手動で作成または編集する](CloudWatch-Agent-Configuration-File-Details.md)」のエージェントセクションの「`omit_hostname`」を参照してください。 Amazon EKS では、k8s に関連したコンテキストはメトリクスのディメンション (`k8s.container.name`、`k8s.deployment.name`、`k8s.namespace.name`、`k8s.node.name`、`k8s.pod.name`、`k8s.replicaset.name`) としても公開されます。これらは `aggregation_dimensions` フィールドを使用してフィルタリングできます。 |
| `type` | リクエストタイプ。指定できる値は `produce`、`fetch`、`fetchconsumer`、`fetchfollower` です。 |
| `state` | ネットワークトラフィックの方向。指定できる値は `in` および `out` です。 |
| `operation` | 同期レプリカのオペレーションタイプ。指定できる値は `shrink` および `expand` です。 |
**Kafka コンシューマーメトリクス**
次のメトリクスは Kafka コンシューマー用に収集できます。
| メトリクス | ディメンション | 説明 |
| --- | --- | --- |
| `kafka.consumer.fetch-rate` | [DEFAULT]、`client-id` | すべてのトピックにおける 1 秒あたりのフェッチリクエストの数。 **単位:** なし **有意義な統計:** 最小、最大、平均 |
| `kafka.consumer.records-lag-max` | [DEFAULT]、`client-id` | コンシューマーがプロデューサーより遅れるメッセージの数。 **単位:** なし **有意義な統計:** 最小、最大、平均 |
| `kafka.consumer.total.bytes-consumed-rate` | [DEFAULT]、`client-id` | すべてのトピックにおける 1 秒あたりの平均消費バイト数 **単位:** バイト **有意義な統計:** 平均 |
| `kafka.consumer.total.fetch-size-avg` | [DEFAULT]、`client-id` | すべてのトピックでリクエストごとにフェッチされたバイト数。 **単位:** バイト **有意義な統計:** 最小、最大、平均 |
| `kafka.consumer.total.records-consumed-rate` | [DEFAULT]、`client-id` | すべてのトピックにおける 1 秒あたりの平均消費レコードの数 **単位:** なし **有意義な統計:** 平均 |
| `kafka.consumer.bytes-consumed-rate` | [DEFAULT]、`client-id`、`topic` | 1 秒あたりの平均消費バイト数。 **単位:** バイト **有意義な統計:** 平均 |
| `kafka.consumer.fetch-size-avg` | [DEFAULT]、`client-id`、`topic` | リクエストごとにフェッチされたバイト数。 **単位:** バイト **有意義な統計:** 最小、最大、平均 |
| `kafka.consumer.records-consumed-rate` | [DEFAULT]、`client-id`、`topic` | 1 秒あたりの平均消費レコードの数。 **単位:** なし **有意義な統計:** 平均 |
Kafka コンシューマーメトリクスは次のディメンションで収集されます。
| ディメンション | 説明 |
| --- | --- |
| [DEFAULT] | デフォルトで Amazon EC2 では、`metrics` セクションの `append_dimensions` フィールドを使用している場合を除き、ホストは CloudWatch エージェントによって収集されるメトリクスのディメンションとしても発行されます。詳細については、「[CloudWatch エージェント設定ファイルを手動で作成または編集する](CloudWatch-Agent-Configuration-File-Details.md)」のエージェントセクションの「`omit_hostname`」を参照してください。 Amazon EKS では、k8s に関連したコンテキストはメトリクスのディメンション (`k8s.container.name`、`k8s.deployment.name`、`k8s.namespace.name`、`k8s.node.name`、`k8s.pod.name`、`k8s.replicaset.name`) としても公開されます。これらは `aggregation_dimensions` フィールドを使用してフィルタリングできます。 |
| `client-id` | クライアントの ID。 |
| `topic` | Kafka トピック。 |
**Kafka プロデューサーメトリクス**
次のメトリクスは Kafka プロデューサー用に収集できます。
| メトリクス | ディメンション | 説明 |
| --- | --- | --- |
| `kafka.producer.io-wait-time-ns-avg` | [DEFAULT]、`client-id` | I/O スレッドが読み取りまたは書き込みの準備が完了したソケットの待機にかかった平均時間。 **単位:** なし **有意義な統計:** 平均 |
| `kafka.producer.outgoing-byte-rate` | [DEFAULT]、`client-id` | すべてのサーバーに 1 秒あたりに送信された送信バイトの平均数。 **単位:** バイト **有意義な統計:** 平均 |
| `kafka.producer.request-latency-avg` | [DEFAULT]、`client-id` | 平均リクエストレイテンシー。 **単位:** ミリ秒 **有意義な統計:** 平均 |
| `kafka.producer.request-rate` | [DEFAULT]、`client-id` | 1 秒あたりの送信リクエストの平均数。 **単位:** なし **有意義な統計:** 平均 |
| `kafka.producer.response-rate` | [DEFAULT]、`client-id` | 1 秒あたりの受信レスポンスの数。 **単位:** なし **有意義な統計:** 最小、最大、平均 |
| `kafka.producer.byte-rate` | [DEFAULT]、`client-id`、`topic` | トピック用に 1 秒あたりに送信された平均バイト数 **単位:** バイト **有意義な統計:** 平均 |
| `kafka.producer.compression-rate` | [DEFAULT]、`client-id`、`topic` | トピックのレコードバッチの平均圧縮率。 **単位:** なし **有意義な統計:** 平均 |
| `kafka.producer.record-error-rate` | [DEFAULT]、`client-id`、`topic` | トピックのエラーの原因となった 1 秒あたりの送信レコードの平均数。 **単位:** なし **有意義な統計:** 平均 |
| `kafka.producer.record-retry-rate` | [DEFAULT]、`client-id`、`topic` | トピックにおける 1 秒あたりのレコード送信を再試行した平均数。 **単位:** なし **有意義な統計:** 平均 |
| `kafka.producer.record-send-rate` | [DEFAULT]、`client-id`、`topic` | トピック用に 1 秒あたりに送信された平均レコード数 **単位:** なし **有意義な統計:** 平均 |
Kafka プロデューサーメトリクスは次のディメンションで収集されます。
| ディメンション | 説明 |
| --- | --- |
| [DEFAULT] | デフォルトで Amazon EC2 では、`metrics` セクションの `append_dimensions` フィールドを使用している場合を除き、ホストは CloudWatch エージェントによって収集されるメトリクスのディメンションとしても発行されます。詳細については、「[CloudWatch エージェント設定ファイルを手動で作成または編集する](CloudWatch-Agent-Configuration-File-Details.md)」のエージェントセクションの「`omit_hostname`」を参照してください。 Amazon EKS では、k8s に関連したコンテキストはメトリクスのディメンション (`k8s.container.name`、`k8s.deployment.name`、`k8s.namespace.name`、`k8s.node.name`、`k8s.pod.name`、`k8s.replicaset.name`) としても公開されます。これらは `aggregation_dimensions` フィールドを使用してフィルタリングできます。 |
| `client-id` | クライアントの ID。 |
| `topic` | Kafka トピック。 |
## Tomcat メトリクスの収集
CloudWatch エージェントを使用して Apache Tomcat メトリクスを収集できます。これを設定するには、CloudWatch エージェント設定ファイルの `metrics_collected` セクション内に `tomcat` セクションを追加します。
次のメトリクスを収集できます。
| メトリクス | ディメンション | 説明 |
| --- | --- | --- |
| `tomcat.sessions` | [DEFAULT] | アクティブなセッションの数。 **単位:** なし **有意義な統計:** 最小、最大、平均 |
| `tomcat.errors` | [DEFAULT]、`proto_handler` | 発生したエラーの数。 **単位:** なし **有意義な統計:** 最小、最大、平均 |
| `tomcat.processing_time` | [DEFAULT]、`proto_handler` | 合計処理時間。 **単位:** ミリ秒 **有意義な統計:** 最小、最大、平均 |
| `tomcat.traffic` | [DEFAULT]、`proto_handler` | 送信および受信バイト数。 **単位:** バイト **有意義な統計:** 最小、最大、平均 |
| `tomcat.threads` | [DEFAULT]、`proto_handler` | スレッドの数。 **単位:** なし **有意義な統計:** 最小、最大、平均 |
| `tomcat.max_time` | [DEFAULT]、`proto_handler`、`direction` | リクエストを処理する最大時間。 **単位:** ミリ秒 **有意義な統計:** 最大 |
| `tomcat.request_count` | [DEFAULT]、`proto_handler` | 合計リクエスト。 **単位:** なし **有意義な統計:** 最小、最大、平均 |
Tomcat メトリクスは次のディメンションで収集されます。
| ディメンション | 説明 |
| --- | --- |
| [DEFAULT] | デフォルトで Amazon EC2 では、`metrics` セクションの `append_dimensions` フィールドを使用している場合を除き、ホストは CloudWatch エージェントによって収集されるメトリクスのディメンションとしても発行されます。詳細については、「[CloudWatch エージェント設定ファイルを手動で作成または編集する](CloudWatch-Agent-Configuration-File-Details.md)」のエージェントセクションの「`omit_hostname`」を参照してください。 Amazon EKS では、k8s に関連したコンテキストはメトリクスのディメンション (`k8s.container.name`、`k8s.deployment.name`、`k8s.namespace.name`、`k8s.node.name`、`k8s.pod.name`、`k8s.replicaset.name`) としても公開されます。これらは `aggregation_dimensions` フィールドを使用してフィルタリングできます。 |
| `proto_handler` | `proto_handler` はコネクタの識別子であり、`--` 形式で提供されます (例えば、`http-nio-8080` など)。 |
| `direction` | トラフィックの方向。指定できる値は `received` および `sent` です。 |
# OpenTelemetry を使用してメトリクスとトレースを収集する
一般的なオープンソースソリューションである OpenTelemetry Protocol (OTLP) で CloudWatch エージェントを使用し、アプリケーションまたはサービスからメトリクスおよびトレースを収集できます。任意の OpenTelemetry SDK を使用し、メトリクスおよびトレースを CloudWatch エージェントに送信できます。利用可能な OpenTelemetry SDKs の詳細については、「[OpenTelemetry がサポートする言語 API と SDK](https://opentelemetry.io/docs/languages/)」を参照してください。
OpenTelemetry メトリクスおよびトレースを収集するには、CloudWatch エージェント設定ファイルに `otlp` セクションを追加します。セクションには次のフィールドが含まれます。
+ `grpc_endpoint` - オプション。gRPC リモートプロシージャコールを使用して送信された OpenTelemetry メトリクスまたはトレースをリッスンするために使用する CloudWatch エージェントのアドレスを指定します。形式は `ip:port` です。このアドレスは、OpenTelemetry SDK の gRPC エクスポーター用に設定されたアドレスと一致する必要があります。このフィールドを省略した場合、`127.0.0.1:4317` のデフォルトが使用されます。
+ `http_endpoint` - オプション。HTTP 経由で送信される OpenTelemetry メトリクスまたはトレースをリッスンするために CloudWatch エージェントが使用するアドレスを指定します。形式は `ip:port` です。このアドレスは、OpenTelemetry SDK の HTTP エクスポーター用に設定されたアドレスと一致する必要があります。このフィールドを省略した場合、`127.0.0.1:4318` のデフォルトが使用されます。
+ `tls` - オプション。サーバーが TLS で設定されることを指定します。
+ `cert_file` – TLS が必要な接続に使用する TLS 証明書へのパス。
+ `key_file` – TLS が必要な接続に使用する TLS キーへのパス。
メトリクスおよびトレースを送信する方法および場所に応じて、`otlp` セクションは CloudWatch エージェント設定ファイル内の複数のセクションに配置することができます。
**重要**
`otlp` セクションごとに一意のエンドポイントとポートが必要です。メトリクスとトレースエンドポイントの分割の詳細については、OpenTelemetry SDK ドキュメントの「[OTLP Exporter Configuration](https://opentelemetry.io/docs/languages/sdk-configuration/otlp-exporter/)」を参照してください。
CloudWatch または Amazon Managed Service for Prometheus にメトリクスを送信するには、`metrics` セクション内の `metrics_collected` に `otlp` セクションを追加します。さまざまな送信先にメトリクスを送信する方法の詳細については、「[CloudWatch エージェント設定ファイルを手動で作成または編集する](CloudWatch-Agent-Configuration-File-Details.md)」を参照してください。次の例では、CloudWatch にメトリクスを送信する設定が示されています。
**注記**
コンテナ化された環境でエージェントを実行しているときに、エージェントコンテナのネットワークの外部からテレメトリを送信する場合は、デフォルトエンドポイント `127.0.0.1` ではなく `0.0.0.0` をエンドポイントとして指定するようにしてください。
```
{
"metrics": {
"metrics_collected": {
"otlp": {
"grpc_endpoint": "127.0.0.1:4317",
"http_endpoint": "127.0.0.1:4318"
}
}
}
}
```
埋め込みメトリクス形式 (EMF) を使用して Amazon CloudWatch Logs にメトリクスを送信するには、`logs` セクション内の `metrics_collected` セクションに `otlp` セクションを追加します。これにより、デフォルトで EMF ログが `/aws/cwagent` ロググループおよび生成されたログストリームに送信されます。デフォルトでは、メトリクスは `CWAgent` 名前空間に抽出されます。次の例では、メトリクスを EMF ログとして CloudWatch Logs に送信する設定が示されています。
```
{
"logs": {
"metrics_collected": {
"otlp": {
"grpc_endpoint": "127.0.0.1:4317",
"http_endpoint": "127.0.0.1:4318"
}
}
}
}
```
トレースを AWS X-Ray に送信するには、`traces` セクション内の `traces_collected` に `otlp` セクションを追加します。次の例では、X-Ray にトレースを送信する設定が示されています。
```
{
"traces": {
"traces_collected": {
"otlp": {
"grpc_endpoint": "127.0.0.1:4317",
"http_endpoint": "127.0.0.1:4318"
}
}
}
}
```
# procstat プラグインでプロセスメトリクスを収集する
*procstat* プラグインでは、個別のプロセスからメトリクスを収集できます。このプラグインは Linux サーバーと、Windows Server のサポート対象バージョンを実行しているサーバーでサポートされます。このセクションでは、procstat 用に CloudWatch エージェントを設定し、CloudWatch エージェントによってインポートされるメトリクスを表示する方法について説明します。また、procstat によって収集されるメトリクスをリストします。
**注記**
`procstat` プラグインは、Amazon ECS 環境の Fargate 起動タイプではサポートされていません。
**Topics**
+ [
## procstat 用の CloudWatch エージェントの設定
](#CloudWatch-Agent-procstat-configuration)
+ [
## Procstat で収集されるメトリクス
](#CloudWatch-Agent-procstat-process-metrics-collected)
+ [
## CloudWatch エージェントによってインポートされたプロセスメトリクスの表示
](#CloudWatch-view-procstat-metrics)
## procstat 用の CloudWatch エージェントの設定
procstat プラグインを使用するには、CloudWatch エージェント設定ファイルの `procstat` セクションに `metrics_collected` セクションを追加します。モニターリングするプロセスを指定するには 3 つの方法があります。これらの方法のうち使用できるのは 1 つのみですが、この 1 つの方法を使用して複数のプロセスを指定してモニターリングできます。
+ `pid_file`: 作成するプロセス識別番号 (PID) ファイルの名前でプロセスを選択します。
+ `exe`: 正規表現の照合ルールを使用して、指定した文字列と一致するプロセス名のプロセスを選択します。一致は「含む」一致です。つまり、一致する用語として `agent` を指定した場合、`cloudwatchagent` のような名前を持つプロセスは、その用語に一致します。詳細については、「[Syntax](https://github.com/google/re2/wiki/Syntax)」を参照してください。
+ `pattern`: プロセスの起動に使用するコマンドラインでプロセスを選択します。正規表現の照合ルールを使用して指定した文字列と一致するコマンドラインを持つすべてのプロセスが選択されます。コマンドで使用されるパラメータやオプションも含めて、コマンドライン全体がチェックされます。
一致は「含む」一致です。つまり、一致する用語として `-c` を指定した場合、`-config` のようなパラメータを持つプロセスは、その用語に一致します。
以上の複数のセクションを含めた場合でも、CloudWatch エージェントで使用される方法は 1 つのみです。複数のセクションを指定すると、CloudWatch エージェントは `pid_file` セクションを使用します (ある場合)。これが存在しない場合は、`exe` セクションを使用します。
Linux サーバーの場合、`exe` セクションまたは `pattern` セクションで指定した文字列は正規表現として評価されます。Windows Server を実行するサーバーの場合、これらの文字列は WMI クエリとして評価されます。文字列の例は `pattern: "%apache%"` などです。詳細については、「[LIKE Operator](https://docs.microsoft.com/en-us/windows/desktop/WmiSdk/like-operator)」を参照してください。
どの方法を使用する場合でも、省略可能な `metrics_collection_interval` パラメータを含めることができます。このパラメータは、これらのメトリクスを収集する間隔を秒単位で指定します。このパラメータを省略すると、デフォルト値の 60 秒が使用されます。
以下のセクションの例では、`procstat` セクションのみをエージェント設定ファイルの `metrics_collected` セクションに追加しています。実際の設定ファイルでは、他のセクションも `metrics_collected` に追加できます。詳細については、「[CloudWatch エージェント設定ファイルを手動で作成または編集する](CloudWatch-Agent-Configuration-File-Details.md)」を参照してください。
### pid\$1file で設定する
次の例の `procstat` セクションでは、PID ファイルの `example1.pid` および `example2.pid` の作成プロセスをモニターリングします。プロセスごとに異なるメトリクスが収集されます。`example2.pid` の作成プロセスからのメトリクスは、10 秒間隔で収集されます。`example1.pid` プロセスからのメトリクスは、デフォルト値の 60 秒間隔で収集されます。
```
{
"metrics": {
"metrics_collected": {
"procstat": [
{
"pid_file": "/var/run/example1.pid",
"measurement": [
"cpu_usage",
"memory_rss"
]
},
{
"pid_file": "/var/run/example2.pid",
"measurement": [
"read_bytes",
"read_count",
"write_bytes"
],
"metrics_collection_interval": 10
}
]
}
}
}
```
### exe による設定
次の例の `procstat` セクションでは、文字列の `agent` または `plugin` と一致する名前を持つすべてのプロセスをモニターリングします。各プロセスから同じメトリクスが収集されます。
```
{
"metrics": {
"metrics_collected": {
"procstat": [
{
"exe": "agent",
"measurement": [
"cpu_time",
"cpu_time_system",
"cpu_time_user"
]
},
{
"exe": "plugin",
"measurement": [
"cpu_time",
"cpu_time_system",
"cpu_time_user"
]
}
]
}
}
}
```
### pattern による設定
次の例の `procstat` セクションでは、文字列の `config` または `-c` と一致するコマンドラインを持つすべてのプロセスをモニターリングします。各プロセスから同じメトリクスが収集されます。
```
{
"metrics": {
"metrics_collected": {
"procstat": [
{
"pattern": "config",
"measurement": [
"rlimit_memory_data_hard",
"rlimit_memory_data_soft",
"rlimit_memory_stack_hard",
"rlimit_memory_stack_soft"
]
},
{
"pattern": "-c",
"measurement": [
"rlimit_memory_data_hard",
"rlimit_memory_data_soft",
"rlimit_memory_stack_hard",
"rlimit_memory_stack_soft"
]
}
]
}
}
}
```
## Procstat で収集されるメトリクス
次の表は、`procstat` プラグインで収集できるメトリクスの一覧です。
CloudWatch エージェントは、以下のメトリクス名の先頭に `procstat` を追加します。収集元が Linux サーバーであるか、Windows Server を実行するサーバーであるかに応じて構文は異なります。たとえば、`cpu_time` メトリクスは、収集元が Linux である場合は `procstat_cpu_time` と表示され、収集元が Windows Server である場合は `procstat cpu_time` と表示されます。
| メトリクス名 | 次で利用可能 | 説明 |
| --- | --- | --- |
| `cpu_time` | Linux | プロセスで CPU を使用する時間。このメトリクスは、1/100 秒単位で測定されます。 単位: 数 |
| `cpu_time_guest` | Linux | プロセスがゲストモードになっている時間です。このメトリクスは、1/100 秒単位で測定されます。 タイプ: 浮動小数点 単位: なし |
| `cpu_time_guest_nice` | Linux | プロセスが nice ゲストで実行されている時間です。このメトリクスは、1/100 秒単位で測定されます。 タイプ: 浮動小数点 単位: なし |
| `cpu_time_idle` | Linux | プロセスがアイドルモードになっている時間です。このメトリクスは、1/100 秒単位で測定されます。 タイプ: 浮動小数点 単位: なし |
| `cpu_time_iowait` | Linux | プロセスが I/O 操作の完了を待機している時間です。このメトリクスは、1/100 秒単位で測定されます。 タイプ: 浮動小数点 単位: なし |
| `cpu_time_irq` | Linux | プロセスが中断を処理している時間です。このメトリクスは、1/100 秒単位で測定されます。 タイプ: 浮動小数点 単位: なし |
| `cpu_time_nice` | Linux | プロセスが nice モードになっている時間です。このメトリクスは、1/100 秒単位で測定されます。 タイプ: 浮動小数点 単位: なし |
| `cpu_time_soft_irq` | Linux | プロセスがソフトウェアの中断を処理している時間です。このメトリクスは、1/100 秒単位で測定されます。 タイプ: 浮動小数点 単位: なし |
| `cpu_time_steal` | Linux | 仮想化環境で実行中に、他のオペレーティングシステムでの実行に費やされる時間です。このメトリクスは、1/100 秒単位で測定されます。 タイプ: 浮動小数点 単位: なし |
| `cpu_time_stolen` | Linux、Windows Server | プロセスが盗まれた時間になっている時間です。これは、仮想化環境で他のオペレーティングシステムに費やされる時間です。このメトリクスは、1/100 秒単位で測定されます。 タイプ: 浮動小数点 単位: なし |
| `cpu_time_system` | Linux、Windows Server、macOS | プロセスがシステムモードになっている時間。このメトリクスは、1/100 秒単位で測定されます。 タイプ: 浮動小数点 単位: カウント |
| `cpu_time_user` | Linux、Windows Server、macOS | プロセスがユーザーモードになっている時間。このメトリクスは、1/100 秒単位で測定されます。 単位: カウント |
| `cpu_usage` | Linux、Windows Server、macOS | 任意の容量でプロセスがアクティブになっている時間の割合。 単位: パーセント |
| `memory_data` | Linux、macOS | プロセスで使用するデータ用メモリの量。 単位: バイト |
| `memory_locked` | Linux、macOS | プロセスでロックされているメモリの量。 単位: バイト |
| `memory_rss` | Linux、Windows Server、macOS | プロセスが使用している実際のメモリ (常駐セット) の量。 単位: バイト |
| `memory_stack` | Linux、macOS | プロセスで使用されているスタックメモリの量。 単位: バイト |
| `memory_swap` | Linux、macOS | プロセスで使用されているスワップメモリの量。 単位: バイト |
| `memory_vms` | Linux、Windows Server、macOS | プロセスで使用されている仮想メモリの量。 単位: バイト |
| `num_fds` | Linux | このプロセスが開いているファイルディスクリプタの数です。 単位: なし |
| `num_threads` | Linux、Windows、macOS | このプロセス内におけるスレッドの数です。 単位: なし |
| `pid` | Linux、Windows Server、macOS | プロセス識別子 (ID)。 単位: なし |
| `pid_count` | Linux、Windows Server、macOS | プロセスに関連付けられたプロセス ID の数。 このメトリクスのフルネームは、Linux サーバーおよび macOS コンピュータでは `procstat_lookup_pid_count`、Windows サーバーでは `procstat_lookup pid_count` です。 単位: なし |
| `read_bytes` | Linux、Windows Server | プロセスがディスクから読み取ったバイト数。 単位: バイト |
| `write_bytes` | Linux、Windows Server | プロセスがディスクに書き込んだバイト数。 単位: バイト |
| `read_count` | Linux、Windows Server | プロセスが実行したディスク読み込みオペレーションの数。 単位: なし |
| `rlimit_realtime_priority_hard` | Linux | このプロセスに設定できる最大リアルタイム優先度のハード制限です。 単位: なし |
| `rlimit_realtime_priority_soft` | Linux | このプロセスに設定できる最大リアルタイム優先度のソフト制限です。 単位: なし |
| `rlimit_signals_pending_hard` | Linux | このプロセスでキューに入れられる最大シグナル数のハード制限です。 単位: なし |
| `rlimit_signals_pending_soft` | Linux | このプロセスでキューに入れられる最大シグナル数のソフト制限です。 単位: なし |
| `rlimit_nice_priority_hard` | Linux | このプロセスで設定できる最大 nice 優先度のハード制限です。 単位: なし |
| `rlimit_nice_priority_soft` | Linux | このプロセスで設定できる最大 nice 優先度のソフト制限です。 単位: なし |
| `rlimit_num_fds_hard` | Linux | このプロセスが開くことができるファイルディスクリプタの最大数のハード制限です。 単位: なし |
| `rlimit_num_fds_soft` | Linux | このプロセスが開くことができるファイルディスクリプタの最大数のソフト制限です。 単位: なし |
| `write_count` | Linux、Windows Server | プロセスが実行したディスク書き込みオペレーションの数。 単位: なし |
| `involuntary_context_switches` | Linux | プロセスのコンテキストが意図せずに切り替えられた回数。 単位: なし |
| `voluntary_context_switches` | Linux | プロセスのコンテキストが意図的に切り替えられた回数。 単位: なし |
| `realtime_priority` | Linux | プロセスで現在使用されているリアルタイム優先度。 単位: なし |
| `nice_priority` | Linux | プロセスで現在使用されている nice 優先度。 単位: なし |
| `signals_pending` | Linux | プロセスによる処理待ち中のシグナルの数。 単位: なし |
| `rlimit_cpu_time_hard` | Linux | プロセスの CPU 時間のハードリソース制限。 単位: なし |
| `rlimit_cpu_time_soft` | Linux | プロセスの CPU 時間のソフトリソース制限。 単位: なし |
| `rlimit_file_locks_hard` | Linux | プロセスのファイルロックのハードリソース制限。 単位: なし |
| `rlimit_file_locks_soft` | Linux | プロセスのファイルロックのソフトリソース制限。 単位: なし |
| `rlimit_memory_data_hard` | Linux | プロセスのデータ用メモリに関するハードリソース制限。 単位: バイト |
| `rlimit_memory_data_soft` | Linux | プロセスのデータ用メモリに関するソフトリソース制限。 単位: バイト |
| `rlimit_memory_locked_hard` | Linux | プロセスのロックされたメモリに関するハードリソース制限。 単位: バイト |
| `rlimit_memory_locked_soft` | Linux | プロセスのロックされたメモリに関するソフトリソース制限。 単位: バイト |
| `rlimit_memory_rss_hard` | Linux | プロセスの物理メモリに関するハードリソース制限。 単位: バイト |
| `rlimit_memory_rss_soft` | Linux | プロセスの物理メモリに関するソフトリソース制限。 単位: バイト |
| `rlimit_memory_stack_hard` | Linux | プロセススタックに関するハードリソース制限。 単位: バイト |
| `rlimit_memory_stack_soft` | Linux | プロセススタックに関するソフトリソース制限。 単位: バイト |
| `rlimit_memory_vms_hard` | Linux | プロセスの仮想メモリに関するハードリソース制限。 単位: バイト |
| `rlimit_memory_vms_soft` | Linux | プロセスの仮想メモリに関するソフトリソース制限。 単位: バイト |
## CloudWatch エージェントによってインポートされたプロセスメトリクスの表示
プロセスメトリクスを CloudWatch にインポートした後、これらのメトリクスを時系列グラフとして表示し、これらのメトリクスをモニターリングし、指定したしきい値に違反した場合に通知できるアラームを作成できます。以下の手順では、プロセスメトリクスを時系列グラフとして表示する方法を示します。アラームの設定の詳細については、「[Amazon CloudWatch でのアラームの使用](CloudWatch_Alarms.md)」を参照してください。
**CloudWatch コンソールでプロセスメトリクスを表示するには**
1. CloudWatch コンソールの [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/) を開いてください。
1. ナビゲーションペインで [**Metrics (メトリクス)**] を選択してください。
1. エージェントによって収集されたメトリクスの名前空間を選択します。デフォルトでは、これは **CWAgent** ですが、CloudWatch エージェント設定ファイルで別の名前空間を指定している場合があります。
1. メトリクスのディメンション (例: **インスタンス別メトリクス**) を選択します。
1. [**All metrics**] タブには、名前空間内のそのディメンションのメトリクスがすべて表示されます。以下の操作を行うことができます。
1. メトリクスをグラフ表示するには、メトリクスの横にあるチェックボックスを選択します。すべてのメトリクスを選択するには、テーブルの見出し行にあるチェックボックスを選択します。
1. テーブルを並べ替えるには、列見出しを使用します。
1. リソースでフィルタするには、リソース ID を選択し、[**Add to search**] を選択します。
1. メトリクスでフィルタするには、メトリクスの名前を選択し、[**Add to search**] を選択します。
1. (オプション) このグラフを CloudWatch ダッシュボードに追加するには、[**Actions**] (アクション)、[**Add to dashboard**] (ダッシュボードに追加) の順に選択します。
# StatsD を使用してカスタムメトリクスを取得する
CloudWatch エージェントで `StatsD` プロトコルを使用することで、アプリケーションやサービスから追加のカスタムメトリクスを取得できます。StatsDは、さまざまなアプリケーションからメトリクスを収集できる一般的なオープンソースソリューションです。StatsD は、独自のメトリクスを計測する場合に特に便利です。CloudWatch エージェントと StatsD を一緒に使用する例については、「[Amazon CloudWatch エージェントを使用してカスタムアプリケーションメトリクスをより効率的にモニターリングする方法](https://aws.amazon.com/blogs/devops/new-how-to-better-monitor-your-custom-application-metrics-using-amazon-cloudwatch-agent/)」を参照してください。
`StatsD` は、Linux サーバーと、Windows Server を実行するサーバーの両方でサポートされます。CloudWatch では、次の `StatsD` 形式がサポートされています。
```
MetricName:value|type|@sample_rate|#tag1:
value,tag1...
```
+ `MetricName` – コロン、バー、\$1 文字、または @ 文字を含まない文字列。
+ `value` – これは整数または浮動小数点のいずれかです。
+ `type` – カウンターには `c`、ゲージには `g`、タイマーには `ms`、ヒストグラムには `h`、セットには `s` を指定します。
+ `sample_rate` – (オプション) 0 から 1 の間の浮動小数点数 (0 と 1 を含む)。カウンター、ヒストグラム、およびタイマーメトリクスに対してのみ使用します。デフォルト値は 1 (時間の 100% サンプリング) です。
+ `tags` – (オプション) タグのカンマ区切りリスト。`StatsD` タグは CloudWatch のディメンションと似ています。キー/値タグにはコロンを使用します、例 `env:prod`。
この形式に従う任意の `StatsD` クライアントを使用して、CloudWatch エージェントにメトリクスを送信することができます。一部の利用可能な `StatsD` クライアントの詳細については、「[GitHub の StatsD クライアントページ](https://github.com/etsy/statsd/wiki#client-implementations)」を参照してください。
これらのカスタムメトリクスを収集するには、`"statsd": {}` 行をエージェント設定ファイルの `metrics_collected` セクションに追加します。この行を手動で追加することができます。設定ファイルの作成にウィザードを使用する場合は、自動的に設定されます。詳細については、「[CloudWatch エージェント設定ファイルを作成する](create-cloudwatch-agent-configuration-file.md)」を参照してください。
`StatsD` のデフォルト設定は、ほとんどのユーザーに有効です。また、必要に応じてエージェント設定ファイルの **[statsd]** セクションに追加できるオプションフィールドがあります。
+ `service_address` – CloudWatch エージェントがリッスンする必要のあるサービスアドレス。形式は `ip:port` です。IP アドレスを省略すると、エージェントは使用可能なすべてのインターフェイスをリッスンします。UDP 形式のみがサポートされているため、UDP プレフィックスを指定する必要はありません。
デフォルト値は `:8125` です。
+ `metrics_collection_interval` – `StatsD` プラグインが実行され、メトリクスを収集する秒単位の頻度。デフォルト値は 10 秒です。範囲は 1～172,000 です。
+ `metrics_aggregation_interval` – CloudWatch がメトリクスを 1 つのデータポイントに集約する秒単位の頻度。デフォルト値は 60 秒です。
例えば、`metrics_collection_interval` が 10 で `metrics_aggregation_interval` が 60 の場合、CloudWatch は 10 秒ごとにデータを収集します。1 分ごとに、その 1 分間に読み取った 6 つのデータ読み取り値が 1 つのデータポイントに集約され、それが CloudWatch に送信されます。
範囲は 0～172,000 です。`metrics_aggregation_interval` を 0 に設定すると、`StatsD` メトリクスの集計が無効になります。
+ `allowed_pending_messages` — キューに入れることができる UDP メッセージの数です。キューがフルになると、StatsD サーバーはパケットのドロップを開始します。デフォルト値は 10000 です。
+ `drop_original_metrics` - オプション。`metrics` セクションの `aggregation_dimensions` フィールドを使用してメトリクスを集計結果にロールアップしている場合、デフォルトでは、エージェントは集計メトリクスと、ディメンションの値ごとに分離された元のメトリクスの両方を送信します。元のメトリクスを CloudWatch に送信したくない場合は、メトリクスのリストを使用してこのパラメータを指定できます。このパラメータとともに指定されたメトリクスには、CloudWatch にレポートされるディメンションごとのメトリクスがありません。代わりに、集計されたメトリクスのみがレポートされます。これにより、エージェントが収集するメトリクスの数が減り、コストが削減されます。
次に示すのは、デフォルトポートとカスタム収集および集約間隔を使用した、エージェント設定ファイルの [**statsd**] セクションの例です。
```
{
"metrics":{
"metrics_collected":{
"statsd":{
"service_address":":8125",
"metrics_collection_interval":60,
"metrics_aggregation_interval":300
}
}
}
}
```
## CloudWatch エージェントによってインポートされた StatsD メトリクスの表示
StatsD メトリクスを CloudWatch にインポートした後、これらのメトリクスを時系列グラフとして表示し、これらのメトリクスをモニターリングし、指定したしきい値に違反した場合に通知できるアラームを作成できます。以下の手順では、StatsD メトリクスを時系列グラフとして表示する方法を示します。アラームの設定の詳細については、「[Amazon CloudWatch でのアラームの使用](CloudWatch_Alarms.md)」を参照してください。
**CloudWatch コンソールで StatsD メトリクスを表示する**
1. CloudWatch コンソールの [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/) を開いてください。
1. ナビゲーションペインで [**Metrics (メトリクス)**] を選択してください。
1. エージェントによって収集されたメトリクスの名前空間を選択します。デフォルトでは、これは **CWAgent** ですが、CloudWatch エージェント設定ファイルで別の名前空間を指定している場合があります。
1. メトリクスのディメンション (例: **インスタンス別メトリクス**) を選択します。
1. [**All metrics**] タブには、名前空間内のそのディメンションのメトリクスがすべて表示されます。以下の操作を行うことができます。
1. メトリクスをグラフ表示するには、メトリクスの横にあるチェックボックスを選択します。すべてのメトリクスを選択するには、テーブルの見出し行にあるチェックボックスを選択します。
1. テーブルを並べ替えるには、列見出しを使用します。
1. リソースでフィルタするには、リソース ID を選択し、[**Add to search**] を選択します。
1. メトリクスでフィルタするには、メトリクスの名前を選択し、[**Add to search**] を選択します。
1. (オプション) このグラフを CloudWatch ダッシュボードに追加するには、[**Actions**] (アクション)、[**Add to dashboard**] (ダッシュボードに追加) の順に選択します。
# collectd を使用してカスタムメトリクスを取得する
CloudWatch エージェントで collectd プロトコルを使用することで、アプリケーションやサービスから追加のメトリクスを取得できます。collectd プロトコルは Linux サーバーでのみサポートされています。collectd は、さまざまなアプリケーションのシステム統計を収集できるプラグインを備えた、一般的なオープンソースソリューションです。CloudWatch エージェントが既に収集できるシステムメトリクスと collectd からの追加のメトリクスを組み合わせることで、システムやアプリケーションのモニターリング、分析、トラブルシューティングを強化できます。collectd の詳細については、「[collectd - The system statistics collection daemon](https://collectd.org/)」を参照してください。
collectd ソフトウェアを使用して CloudWatch エージェントにメトリクスを送信します。collectd メトリクスでは、CloudWatch エージェントはサーバーとして機能するのに対し、collectd プラグインはクライアントとして機能します。
collectd ソフトウェアは、すべてのサーバーに自動的にインストールされるわけではありません。Amazon Linux 2 を実行するサーバーで、次の手順に従って collectd をインストールします。
```
sudo amazon-linux-extras install collectd
```
他のシステムに collectd をインストールする方法については、[collectd の ダウンロードページ](https://www.collectd.org/download.html)を参照してください。
これらのカスタムメトリクスを収集するには、[**"collectd": \$1\$1**] 行をエージェント設定ファイルの [**metrics\$1collected**] セクションに追加します。この行を手動で追加することができます。設定ファイルの作成にウィザードを使用する場合は、自動的に設定されます。詳細については、「[CloudWatch エージェント設定ファイルを作成する](create-cloudwatch-agent-configuration-file.md)」を参照してください。
オプションパラメータも使用可能です。collectd を使用していて [**collectd\$1auth\$1file**] として `/etc/collectd/auth_file` を使用しない場合は、これらのオプションのいくつかを設定する必要があります。
+ **service\$1address**: CloudWatch エージェントが聞く必要のあるサービスアドレス。形式は `"udp://ip:port` です。デフォルトは `udp://127.0.0.1:25826` です。
+ **name\$1prefix**: 各 collectd メトリクスの名前の先頭にアタッチするプレフィックスです。デフォルトは `collectd_` です。最大長は 255 文字です。
+ **collectd\$1security\$1level**: ネットワーク通信のセキュリティレベルを設定します。デフォルトは [**encrypt**] です。
[**encrypt**] は、暗号化されたデータのみが受け入れられることを指定します。[**sign**] は、署名され暗号化されたデータのみが受け入れられることを指定します。[**none**] は、すべてのデータが受け入れられることを指定します。[**collectd\$1auth\$1file**] の値を指定すると、暗号化されたデータは可能であれば復号されます。
詳細については、collectd Wiki の「[クライアント設定](https://collectd.org/wiki/index.php/Networking_introduction#Client_setup)」および「[可能なインタラクション](https://collectd.org/wiki/index.php/Networking_introduction#Possible_interactions)」を参照してください。
+ **collectd\$1auth\$1file**: ユーザー名がパスワードにマッピングされるファイルを設定します。これらのパスワードは、署名の検証と暗号化されたネットワークパケットの復号に使用されます。指定された場合、署名されたデータが検証され、暗号化されたパケットが復号されます。それ以外の場合は、署名されたデータは署名をチェックすることなく受け入れられ、暗号化されたデータを復号することはできません。
デフォルトは `/etc/collectd/auth_file` です。
[**collectd\$1security\$1level**] が [**none**] に設定されている場合、これはオプションです。[**collectd\$1security\$1level**] を `encrypt` または [**sign**] に設定した場合は、[**collectd\$1auth\$1file**] を指定する必要があります。
auth ファイルの形式は、各行はユーザー名とそれに続くコロン、さらに任意の数のスペースとそれに続くパスワードの構成です。次に例を示します。
`user1: user1_password`
`user2: user2_password`
+ **collectd\$1typesdb**: データセットの説明を含む 1 つ以上のファイルのリストです。リストにエントリが 1 つしかない場合でも、リストは角括弧で囲まれている必要があります。リストの各エントリは二重引用符で囲む必要があります。複数のエントリがある場合は、カンマで区切ります Linux サーバーのデフォルトは `["/usr/share/collectd/types.db"]` です。macOS コンピュータのデフォルトは、collectd のバージョンによって異なります。例えば、`["/usr/local/Cellar/collectd/5.12.0/share/collectd/types.db"]` です。
詳細については、「[https://www.collectd.org/documentation/manpages/types.db.html](https://www.collectd.org/documentation/manpages/types.db.html)」を参照してください。
+ **metrics\$1aggregation\$1interval**: CloudWatch がメトリクスを 1 つのデータポイントに集約する秒単位の頻度。デフォルト値は 60 秒です。範囲は 0 ～ 172,000 です。0 に設定すると、collectd メトリクスの集計が無効になります。
エージェント設定ファイルの collectd セクションの例を次に示します。
```
{
"metrics":{
"metrics_collected":{
"collectd":{
"name_prefix":"My_collectd_metrics_",
"metrics_aggregation_interval":120
}
}
}
}
```
## CloudWatch エージェントによってインポートされた collectd メトリクスを表示する
collectd メトリクスを CloudWatch にインポートした後、これらのメトリクスを時系列グラフとして表示し、これらのメトリクスをモニターリングし、指定したしきい値に違反した場合に通知できるアラームを作成できます。以下の手順では、collectd メトリクスを時系列グラフとして表示する方法を示します。アラームの設定の詳細については、「[Amazon CloudWatch でのアラームの使用](CloudWatch_Alarms.md)」を参照してください。
**CloudWatch コンソールで collectd メトリクスを表示するには**
1. CloudWatch コンソールの [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/) を開いてください。
1. ナビゲーションペインで [**Metrics (メトリクス)**] を選択してください。
1. エージェントによって収集されたメトリクスの名前空間を選択します。デフォルトでは、これは **CWAgent** ですが、CloudWatch エージェント設定ファイルで別の名前空間を指定している場合があります。
1. メトリクスのディメンション (例: **インスタンス別メトリクス**) を選択します。
1. [**All metrics**] タブには、名前空間内のそのディメンションのメトリクスがすべて表示されます。以下の操作を行うことができます。
1. メトリクスをグラフ表示するには、メトリクスの横にあるチェックボックスを選択します。すべてのメトリクスを選択するには、テーブルの見出し行にあるチェックボックスを選択します。
1. テーブルを並べ替えるには、列見出しを使用します。
1. リソースでフィルタするには、リソース ID を選択し、[**Add to search**] を選択します。
1. メトリクスでフィルタするには、メトリクスの名前を選択し、[**Add to search**] を選択します。
1. (オプション) このグラフを CloudWatch ダッシュボードに追加するには、[**Actions**] (アクション)、[**Add to dashboard**] (ダッシュボードに追加) の順に選択します。
# Amazon EC2 インスタンスでの Prometheus メトリクスコレクションのセットアップと設定
次のセクションでは、EC2 インスタンスに Prometheus モニターリングを使用して CloudWatch エージェントをインストールする方法と、追加のターゲットをスクレイプするようにエージェントを設定する方法について説明します。また、Prometheus モニターリングでのテストに使用するサンプルワークロードを設定するためのオチュートリアルも提供します。
Linux と Windows の両方のインスタンスがサポートされています。
CloudWatch エージェントがサポートするオペレーティングシステムについては、「[CloudWatch エージェントを使用してメトリクス、ログ、トレースを収集する](Install-CloudWatch-Agent.md)」を参照してください。
**VPC セキュリティグループの要件**
VPC を使用している場合は、次の要件が適用されます。
+ Prometheus ワークロードのセキュリティグループの受信ルールでは、Prometheus のメトリクスをプライベート IP でスクレイピングするために、CloudWatch エージェントへの Prometheus ポートを開く必要があります。
+ CloudWatch エージェントのセキュリティグループの出力ルールでは、CloudWatch エージェントがプライベート IP によって Prometheus ワークロードのポートに接続できるようにする必要があります。
**Topics**
+ [
## ステップ 1: CloudWatch エージェントをインストールする
](#CloudWatch-Agent-PrometheusEC2-install)
+ [
## ステップ 2: Prometheus ソースとインポートメトリクスをスクレイプする
](#CloudWatch-Agent-PrometheusEC2-configure)
+ [
## 例: Prometheus メトリクステスト用に Java/JMX サンプルワークロードを設定する
](#CloudWatch-Agent-Prometheus-Java)
## ステップ 1: CloudWatch エージェントをインストールする
最初のステップは、EC2 インスタンスに CloudWatch エージェントをインストールすることです。手順については、「[CloudWatch エージェントのインストール](install-CloudWatch-Agent-on-EC2-Instance.md)」を参照してください。
## ステップ 2: Prometheus ソースとインポートメトリクスをスクレイプする
Prometheus モニターリングを使用した CloudWatch エージェントは、Prometheus メトリクスをスクレイプするために 2 つの設定が必要です。1 つは標準の Prometheus 設定用で、Prometheus ドキュメントの「[](https://prometheus.io/docs/prometheus/latest/configuration/configuration/#scrape_config)」に記載されています。もう 1 つは CloudWatch エージェント設定用です。
### Prometheus スクレイプ設定
この CloudWatch エージェントは、Prometheus のドキュメントの「[](https://prometheus.io/docs/prometheus/latest/configuration/configuration/#scrape_config)」に記載されているように、標準の Prometheus スクレイプ設定をサポートしています。このセクションを編集して、このファイルに既に含まれている設定を更新したり、Prometheus スクレイピングターゲットを追加したりできます。サンプル設定ファイルに次のグローバル設定行が含まれています。
```
PS C:\ProgramData\Amazon\AmazonCloudWatchAgent> cat prometheus.yaml
global:
scrape_interval: 1m
scrape_timeout: 10s
scrape_configs:
- job_name: MY_JOB
sample_limit: 10000
file_sd_configs:
- files: ["C:\\ProgramData\\Amazon\\AmazonCloudWatchAgent\\prometheus_sd_1.yaml", "C:\\ProgramData\\Amazon\\AmazonCloudWatchAgent\\prometheus_sd_2.yaml"]
```
`global` セクションでは、すべての設定コンテキストで有効なパラメータを指定します。また、これらは他の設定セクションのデフォルトとしても機能します。これには以下のパラメータが含まれています。
+ `scrape_interval` – ターゲットをスクレイプする頻度を定義します。
+ `scrape_timeout` – スクレイプリクエストがタイムアウトするまでの待機時間を定義します。
`scrape_configs` セクションでは、ターゲットとパラメータのセットを指定し、それらをスクレイプする方法を定義します。これには以下のパラメータが含まれています。
+ `job_name` – デフォルトでスクレイプされたメトリクスに割り当てられたジョブ名。
+ `sample_limit` – スクレイプごとに受け入れられるスクレイプされたサンプルの数の制限。
+ `file_sd_configs` – ファイルサービスの検出設定のリスト。これは、ゼロ個以上の静的設定のリストを含むファイルのセットを読み取ります。`file_sd_configs` セクションには、ターゲットグループの抽出元となるファイルのパターンを定義する `files` パラメータが含まれています。
CloudWatch エージェントは、次のサービス検出設定タイプをサポートします。
**`static_config`** ターゲットのリストと、それらに共通のラベルセットを指定できます。これは、スクレイプ設定で静的ターゲットを指定するための標準的な方法です。
以下に、ローカルホストから Prometheus メトリクスをスクレーピングするための静的設定の例を示します。エージェントが実行されているサーバーに対して Prometheus ポートが開いている場合は、メトリクスを他のサーバーからスクレイプすることもできます。
```
PS C:\ProgramData\Amazon\AmazonCloudWatchAgent> cat prometheus_sd_1.yaml
- targets:
- 127.0.0.1:9404
labels:
key1: value1
key2: value2
```
この例には、以下のキー要素が含まれています。
+ `targets` – 静的設定によってスクレイプされたターゲット。
+ `labels` – ターゲットからスクレイプされたすべてのメトリクスに割り当てられたラベル。
**`ec2_sd_config`** Amazon EC2 インスタンスからスクレイプターゲットを取得できます。EC2 インスタンスのリストから Prometheus メトリクスをスクレイプするサンプル `ec2_sd_config` を次に示します。これらのインスタンスの Prometheus ポートは、CloudWatch エージェントが実行されているサーバーに対して開く必要があります。CloudWatch エージェントが実行される EC2 インスタンスの IAM ロールには、`ec2:DescribeInstance` アクセス許可を含める必要があります。例えば、管理ポリシー **AmazonEC2ReadOnlyAccess** を CloudWatch エージェントを実行するインスタンスにアタッチできます。
```
PS C:\ProgramData\Amazon\AmazonCloudWatchAgent> cat prometheus.yaml
global:
scrape_interval: 1m
scrape_timeout: 10s
scrape_configs:
- job_name: MY_JOB
sample_limit: 10000
ec2_sd_configs:
- region: us-east-1
port: 9404
filters:
- name: instance-id
values:
- i-98765432109876543
- i-12345678901234567
```
この例には、以下のキー要素が含まれています。
+ `region` — ターゲット EC2 インスタンスがある AWS リージョン。これを空白のままにすると、インスタンスメタデータのリージョンが使用されます。
+ `port` – メトリクスをスクレイプするポート。
+ `filters` – インスタンスリストのフィルタリングに使用するオプションのフィルター。この例では、EC2 インスタンス ID に基づいてフィルタリングします。フィルタリングできるその他の条件については、「[DescribeInstances](https://docs.aws.amazon.com/AWSEC2/latest/APIReference/API_DescribeInstances.html)」を参照してください。
### Prometheus の CloudWatch エージェント設定
CloudWatch エージェント設定ファイルには、`prometheus` と `logs` の両方の `metrics_collected` セクションが含まれています。それには次のパラメータが含まれます。
+ **cluster\$1name** – ログイベントのラベルとして追加されるクラスター名を指定します。このフィールドはオプションです。
+ **log\$1group\$1name** – スクレイプされた Prometheus メトリクスのロググループ名を指定します。
+ **prometheus\$1config\$1path** – Prometheus スクレイプ設定ファイルパスを指定します。
+ **emf\$1processor** – 埋め込みメトリクス形式のプロセッサ設定を指定します。埋め込みメトリックフォーマットの詳細については、「[ログ内へのメトリクスの埋め込み](CloudWatch_Embedded_Metric_Format.md)」を参照してください。
`emf_processor` セクションには、次のパラメータを含めることができます。
+ **metric\$1declaration\$1dedup** – trueに設定すると、埋め込まれたメトリクスフ形式の重複除外機能が有効になります。
+ **metric\$1namespace** – 出力される CloudWatch メトリクスのメトリクス名前空間を指定します。
+ **metric\$1unit** – メートルの name:metric 単位マップを指定します。サポートされているメトリクス単位については、「[MetricDatum](https://docs.aws.amazon.com/AmazonCloudWatch/latest/APIReference/API_MetricDatum.html)」を参照してください。
+ **metric\$1declaration** – 生成されるメトリクス形式が埋め込まれたログの配列を指定するセクションです。CloudWatch エージェントがインポートする各 Prometheus ソースには、デフォルトで `metric_declaration` セクションがあります。これらの各セクションには、次のフィールドが含まれています。
+ `source_labels` は、`label_matcher` 行によってチェックされるラベルの値を指定します。
+ `label_matcher` は、 `source_labels` に表示されているラベルの値をチェックする正規表現です。一致するメトリクスは、CloudWatch に送信される埋め込みメトリクス形式に含めることができます。
+ `metric_selectors` は、収集され、CloudWatch に送信されるメトリクスを指定する正規表現です。
+ `dimensions` は、選択した各メトリクスの CloudWatch ディメンションとして使用されるラベルのリストです。
以下に、Prometheus の CloudWatch エージェントの設定例を示します。
```
{
"logs":{
"metrics_collected":{
"prometheus":{
"cluster_name":"prometheus-cluster",
"log_group_name":"Prometheus",
"prometheus_config_path":"C:\\ProgramData\\Amazon\\AmazonCloudWatchAgent\\prometheus.yaml",
"emf_processor":{
"metric_declaration_dedup":true,
"metric_namespace":"CWAgent-Prometheus",
"metric_unit":{
"jvm_threads_current": "Count",
"jvm_gc_collection_seconds_sum": "Milliseconds"
},
"metric_declaration":[
{
"source_labels":[
"job", "key2"
],
"label_matcher":"MY_JOB;^value2",
"dimensions":[
[
"key1", "key2"
],
[
"key2"
]
],
"metric_selectors":[
"^jvm_threads_current$",
"^jvm_gc_collection_seconds_sum$"
]
}
]
}
}
}
}
}
```
前の例では、次の条件が満たされた場合にログイベントとして送信される埋め込みメトリクス形式セクションを設定します。
+ `job` ラベルの値は `MY_JOB` です
+ `key2` ラベルの値は `value2` です
+ Prometheus メトリクス `jvm_threads_current` および `jvm_gc_collection_seconds_sum` には、`job` ラベルおよび `key2` ラベルの両方が含まれます。
送信されるログイベントには、次の強調表示されたセクションが含まれます。
```
{
"CloudWatchMetrics": [
{
"Metrics": [
{
"Unit": "Count",
"Name": "jvm_threads_current"
},
{
"Unit": "Milliseconds",
"Name": "jvm_gc_collection_seconds_sum"
}
],
"Dimensions": [
[
"key1",
"key2"
],
[
"key2"
]
],
"Namespace": "CWAgent-Prometheus"
}
],
"ClusterName": "prometheus-cluster",
"InstanceId": "i-0e45bd06f196096c8",
"Timestamp": "1607966368109",
"Version": "0",
"host": "EC2AMAZ-PDDOIUM",
"instance": "127.0.0.1:9404",
"jvm_threads_current": 2,
"jvm_gc_collection_seconds_sum": 0.006000000000000002,
"prom_metric_type": "gauge",
...
}
```
## 例: Prometheus メトリクステスト用に Java/JMX サンプルワークロードを設定する
JMX Exporter は、Prometheus メトリクスとして JMX mBeans をスクレイプおよび公開できる公式の Prometheus エクスポーターです。詳細については、[prometheus/jmx\$1exporter](https://github.com/prometheus/jmx_exporter) を参照してください。
CloudWatch エージェントは、EC2 インスタンスの JMX Exporter から Java 仮想マシン (JVM)、Hjava、Tomcat (Catalina) から事前定義された Prometheus メトリクスを収集できます。
### ステップ 1: CloudWatch エージェントをインストールする
最初のステップは、EC2 インスタンスに CloudWatch エージェントをインストールすることです。手順については、「[CloudWatch エージェントのインストール](install-CloudWatch-Agent-on-EC2-Instance.md)」を参照してください。
### ステップ 2: Java/JMX ワークロードを開始する
次のステップは、Java/JMX ワークロードを開始することです。
まず、次の場所から最新の JMX Exporter の jar ファイルをダウンロードします: [prometheus/jmx\$1exporter](https://github.com/prometheus/jmx_exporter)。
**サンプルアプリケーションに jar を使用する**
次のセクションのコマンド例では、`SampleJavaApplication-1.0-SNAPSHOT.jar` を jar ファイルとして使用します。コマンドのこれらの部分をアプリケーションの jar に置き換えます。
#### JMX Exporter 設定ファイルを準備する
`config.yaml` ファイルは JMX Exporter 設定ファイルです。詳細については、JMX Exporter ドキュメントの「[設定](https://github.com/prometheus/jmx_exporter#Configuration)」を参照してください。
Java と Tomcat の設定のサンプルを次に示します。
```
---
lowercaseOutputName: true
lowercaseOutputLabelNames: true
rules:
- pattern: 'java.lang<>(FreePhysicalMemorySize|TotalPhysicalMemorySize|FreeSwapSpaceSize|TotalSwapSpaceSize|SystemCpuLoad|ProcessCpuLoad|OpenFileDescriptorCount|AvailableProcessors)'
name: java_lang_OperatingSystem_$1
type: GAUGE
- pattern: 'java.lang<>(TotalStartedThreadCount|ThreadCount)'
name: java_lang_threading_$1
type: GAUGE
- pattern: 'Catalina<>(\w+)'
name: catalina_globalrequestprocessor_$3_total
labels:
port: "$2"
protocol: "$1"
help: Catalina global $3
type: COUNTER
- pattern: 'Catalina<>(requestCount|maxTime|processingTime|errorCount)'
name: catalina_servlet_$3_total
labels:
module: "$1"
servlet: "$2"
help: Catalina servlet $3 total
type: COUNTER
- pattern: 'Catalina<>(currentThreadCount|currentThreadsBusy|keepAliveCount|pollerThreadCount|connectionCount)'
name: catalina_threadpool_$3
labels:
port: "$2"
protocol: "$1"
help: Catalina threadpool $3
type: GAUGE
- pattern: 'Catalina<>(processingTime|sessionCounter|rejectedSessions|expiredSessions)'
name: catalina_session_$3_total
labels:
context: "$2"
host: "$1"
help: Catalina session $3 total
type: COUNTER
- pattern: ".*"
```
#### Prometheus エクスポーターで Java アプリケーションを起動する
サンプルアプリケーションを起動する これにより、Prometheus メトリクスをポート 9404 に出力します。エントリポイント `com.gubupt.sample.app.App` は、必ずサンプル Java アプリケーションの正しい情報に置き換えてください。
Linux では、以下のコマンドを入力します。
```
$ nohup java -javaagent:./jmx_prometheus_javaagent-0.14.0.jar=9404:./config.yaml -cp ./SampleJavaApplication-1.0-SNAPSHOT.jar com.gubupt.sample.app.App &
```
Windows では、以下のコマンドを入力します。
```
PS C:\> java -javaagent:.\jmx_prometheus_javaagent-0.14.0.jar=9404:.\config.yaml -cp .\SampleJavaApplication-1.0-SNAPSHOT.jar com.gubupt.sample.app.App
```
#### Prometheus メトリクスの放出を確認する
Prometheus メトリクスが出力されていることを確認します。
Linux では、以下のコマンドを入力します。
```
$ curl localhost:9404
```
Windows では、以下のコマンドを入力します。
```
PS C:\> curl http://localhost:9404
```
Linux での出力例:
```
StatusCode : 200
StatusDescription : OK
Content : # HELP jvm_classes_loaded The number of classes that are currently loaded in the JVM
# TYPE jvm_classes_loaded gauge
jvm_classes_loaded 2526.0
# HELP jvm_classes_loaded_total The total number of class...
RawContent : HTTP/1.1 200 OK
Content-Length: 71908
Content-Type: text/plain; version=0.0.4; charset=utf-8
Date: Fri, 18 Dec 2020 16:38:10 GMT
# HELP jvm_classes_loaded The number of classes that are currentl...
Forms : {}
Headers : {[Content-Length, 71908], [Content-Type, text/plain; version=0.0.4; charset=utf-8], [Date, Fri, 18
Dec 2020 16:38:10 GMT]}
Images : {}
InputFields : {}
Links : {}
ParsedHtml : System.__ComObject
RawContentLength : 71908
```
### ステップ 3: Prometheus メトリクスをスクレイプするように CloudWatch エージェントを設定する
次に、CloudWatch エージェント設定ファイルで Prometheus スクレイプ設定をセットアップします。
**Java/JMX の例の Prometheus スクレイプ設定を行うには**
1. `file_sd_config` および `static_config` の設定をセットアップします。
Linux では、以下のコマンドを入力します。
```
$ cat /opt/aws/amazon-cloudwatch-agent/var/prometheus.yaml
global:
scrape_interval: 1m
scrape_timeout: 10s
scrape_configs:
- job_name: jmx
sample_limit: 10000
file_sd_configs:
- files: [ "/opt/aws/amazon-cloudwatch-agent/var/prometheus_file_sd.yaml" ]
```
Windows では、以下のコマンドを入力します。
```
PS C:\ProgramData\Amazon\AmazonCloudWatchAgent> cat prometheus.yaml
global:
scrape_interval: 1m
scrape_timeout: 10s
scrape_configs:
- job_name: jmx
sample_limit: 10000
file_sd_configs:
- files: [ "C:\\ProgramData\\Amazon\\AmazonCloudWatchAgent\\prometheus_file_sd.yaml" ]
```
1. スクレイプターゲットの設定を行います。
Linux では、以下のコマンドを入力します。
```
$ cat /opt/aws/amazon-cloudwatch-agent/var/prometheus_file_sd.yaml
- targets:
- 127.0.0.1:9404
labels:
application: sample_java_app
os: linux
```
Windows では、以下のコマンドを入力します。
```
PS C:\ProgramData\Amazon\AmazonCloudWatchAgent> cat prometheus_file_sd.yaml
- targets:
- 127.0.0.1:9404
labels:
application: sample_java_app
os: windows
```
1. `ec2_sc_config` によって Prometheus スクレイプ設定を行います。*your-ec2-instance-id* を正しい EC2 インスタンス ID に置き換えます。
Linux では、以下のコマンドを入力します。
```
$ cat .\prometheus.yaml
global:
scrape_interval: 1m
scrape_timeout: 10s
scrape_configs:
- job_name: jmx
sample_limit: 10000
ec2_sd_configs:
- region: us-east-1
port: 9404
filters:
- name: instance-id
values:
- your-ec2-instance-id
```
Windows では、以下のコマンドを入力します。
```
PS C:\ProgramData\Amazon\AmazonCloudWatchAgent> cat prometheus_file_sd.yaml
- targets:
- 127.0.0.1:9404
labels:
application: sample_java_app
os: windows
```
1. CloudWatch エージェント設定を行います。まず、正しいディレクトリに移動します。Linux では、それは `/opt/aws/amazon-cloudwatch-agent/var/cwagent-config.json` です。Windows では、それは `C:\ProgramData\Amazon\AmazonCloudWatchAgent\cwagent-config.json` です。
次に、Java/JHX Prometheus メトリクスが定義されている設定例を示します。必ず *path-to-Prometheus-Scrape-Configuration-file* へのパスを正しいパスに置き換えてください。
```
{
"agent": {
"region": "us-east-1"
},
"logs": {
"metrics_collected": {
"prometheus": {
"cluster_name": "my-cluster",
"log_group_name": "prometheus-test",
"prometheus_config_path": "path-to-Prometheus-Scrape-Configuration-file",
"emf_processor": {
"metric_declaration_dedup": true,
"metric_namespace": "PrometheusTest",
"metric_unit":{
"jvm_threads_current": "Count",
"jvm_classes_loaded": "Count",
"java_lang_operatingsystem_freephysicalmemorysize": "Bytes",
"catalina_manager_activesessions": "Count",
"jvm_gc_collection_seconds_sum": "Seconds",
"catalina_globalrequestprocessor_bytesreceived": "Bytes",
"jvm_memory_bytes_used": "Bytes",
"jvm_memory_pool_bytes_used": "Bytes"
},
"metric_declaration": [
{
"source_labels": ["job"],
"label_matcher": "^jmx$",
"dimensions": [["instance"]],
"metric_selectors": [
"^jvm_threads_current$",
"^jvm_classes_loaded$",
"^java_lang_operatingsystem_freephysicalmemorysize$",
"^catalina_manager_activesessions$",
"^jvm_gc_collection_seconds_sum$",
"^catalina_globalrequestprocessor_bytesreceived$"
]
},
{
"source_labels": ["job"],
"label_matcher": "^jmx$",
"dimensions": [["area"]],
"metric_selectors": [
"^jvm_memory_bytes_used$"
]
},
{
"source_labels": ["job"],
"label_matcher": "^jmx$",
"dimensions": [["pool"]],
"metric_selectors": [
"^jvm_memory_pool_bytes_used$"
]
}
]
}
}
},
"force_flush_interval": 5
}
}
```
1. 次のコマンドのいずれかを入力して、CloudWatch エージェントを再起動します。
Linux では、以下のコマンドを入力します。
```
sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -a fetch-config -m ec2 -s -c file:/opt/aws/amazon-cloudwatch-agent/var/cwagent-config.json
```
Windows では、以下のコマンドを入力します。
```
& "C:\Program Files\Amazon\AmazonCloudWatchAgent\amazon-cloudwatch-agent-ctl.ps1" -a fetch-config -m ec2 -s -c file:C:\ProgramData\Amazon\AmazonCloudWatchAgent\cwagent-config.json
```
### Prometheus のメトリクスとログの表示
これで、収集されている Java/JMX メトリクスを表示できるようになりました。
**サンプル Java/JMX ワークロードのメトリクスを表示するには**
1. CloudWatch コンソールの [https://console.aws.amazon.com/cloudwatch/](https://console.aws.amazon.com/cloudwatch/) を開いてください。
1. クラスターが実行されているリージョンにおいて、左のナビゲーションペインで [**Metrics**] (メトリクス) を選択します。**PrometheusTest** 名前空間を検索して、メトリクスを確認します。
1. CloudWatch Logs イベントを表示するには、ナビゲーションペインで [**Log Groups (ロググループ)**] を選択します。イベントは、ロググループの **prometheus-test** にあります。
# 関連エンティティの CloudWatch エージェントサービスと環境名の設定
CloudWatch コンソールの [[関連するペインの探索]](ExploreRelated.md)をサポートするため、CloudWatch エージェントはエンティティデータを持つメトリクスおよびログを送信できます。サービス名または環境名は、[CloudWatch エージェント JSON 設定](CloudWatch-Agent-Configuration-File-Details.md)で設定できます。
**注記**
エージェント設定は上書きされる場合があります。エージェントが関連エンティティに送信するデータを決定する方法の詳細については、「[関連するテレメトリで CloudWatch エージェントの使用](CloudWatch-Agent-RelatedEntities.md)」を参照してください。
メトリクスの場合、エージェント、メトリクス、プラグインのレベルで設定できます。ログの場合、エージェント、ログ、ファイルのレベルで設定できます。最も具体的な設定が常に使用されます。例えば、設定がエージェントレベルおよびメトリクスレベルで存在する場合、メトリクスはメトリクス設定を使用し、それ以外のもの (ログ) はエージェント設定を使用します。次の例では、サービス名および環境名を設定するさまざまな方法が示されています。
```
{
"agent": {
"service.name": "agent-level-service",
"deployment.environment": "agent-level-environment"
},
"metrics": {
"service.name": "metric-level-service",
"deployment.environment": "metric-level-environment",
"metrics_collected": {
"statsd": {
"service.name": "statsd-level-service",
"deployment.environment": "statsd-level-environment",
},
"collectd": {
"service.name": "collectdd-level-service",
"deployment.environment": "collectd-level-environment",
}
}
},
"logs": {
"service.name": "log-level-service",
"deployment.environment": "log-level-environment",
"logs_collected": {
"files": {
"collect_list": [
{
"file_path": "/opt/aws/amazon-cloudwatch-agent/logs/amazon-cloudwatch-agent.log",
"log_group_name": "amazon-cloudwatch-agent.log",
"log_stream_name": "amazon-cloudwatch-agent.log",
"service.name": "file-level-service",
"deployment.environment": "file-level-environment"
}
]
}
}
}
}
```
# CloudWatch エージェントの起動
CloudWatch エージェントは、Systems Manager Run Command またはコマンドラインを使用して開始できます。
Security-Enhanced Linux (SELinux) が有効になっているシステムでエージェントを設定する方法については、「[Security-Enhanced Linux (SELinux) で CloudWatch エージェントをセットアップする](CloudWatch-Agent-SELinux.md)」を参照してください。
## Amazon EC2 でコマンドラインを使用して CloudWatch エージェントを起動する
コマンドラインを使用して Amazon EC2 で CloudWatch エージェントを起動するには、以下のステップを実行します。
Security-Enhanced Linux (SELinux) が有効になっているシステムでエージェントを設定する方法については、「[Security-Enhanced Linux (SELinux) で CloudWatch エージェントをセットアップする](CloudWatch-Agent-SELinux.md)」を参照してください。
**コマンドラインを使用して Amazon EC2 で CloudWatch エージェントを起動するには**
1. 使用するエージェント設定ファイルを、エージェントを実行するサーバーにコピーします。設定ファイルのコピー先のパス名を書き留めます。
1. このコマンドで、`-a fetch-config` によりエージェントは最新バージョンの CloudWatch エージェント設定ファイルをロードし、`-s` がエージェントを開始します。
以下のいずれかのコマンドを入力します。*configuration-file-path* は、エージェント設定ファイルへのパスに置き換えます。このファイルの名前は、ウィザードで作成した場合は `config.json` になり、手動で作成した場合は `amazon-cloudwatch-agent.json` になる場合があります。
Linux を実行する EC2 インスタンスで、次のコマンドを入力します。
```
sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -a fetch-config -m ec2 -s -c file:configuration-file-path
```
Linux を実行しているオンプレミスサーバーでは、次のように入力します。
```
sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -a fetch-config -m onPremise -s -c file:configuration-file-path
```
Windows Server を実行する EC2 インスタンスでは、PowerShell コンソールから次のように入力します。
```
& "C:\Program Files\Amazon\AmazonCloudWatchAgent\amazon-cloudwatch-agent-ctl.ps1" -a fetch-config -m ec2 -s -c file:configuration-file-path
```
Windows Server を実行するオンプレミスサーバーでは、PowerShell コンソールから次のように入力します。
```
& "C:\Program Files\Amazon\AmazonCloudWatchAgent\amazon-cloudwatch-agent-ctl.ps1" -a fetch-config -m onPremise -s -c file:configuration-file-path
```
## オンプレミスサーバーで CloudWatch エージェントを起動する
オンプレミスサーバーで CloudWatch エージェントを起動するには、以下のステップを実行します。
**SSM Agent を使用して、オンプレミスサーバーで CloudWatch エージェントを開始するには**
1. Systems Manager コンソール ([https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)) を開きます。
1. ナビゲーションペインで、[**Run Command**] を選択します。
-または-
AWS Systems Manager のホームページが表示された場合は、スクロールダウンして [**Explore Run Command**] (Run Command の詳細) を選択します。
1. [**Run command (コマンドの実行)**] を選択します。
1. [**Command document**] リストで、[**AmazonCloudWatch-ManageAgent**] の横のボタンを選択します。
1. [**Targets**] 領域で、エージェントをインストールしたインスタンスを選択します。
1. [**Action**] リストで、[**configure**] を選択します。
1. [**Mode**] リストで、[**onPremise**] を選択します。
1. [**Optional Configuration Location (オプションの設定場所)**] ボックスで、ウィザードで作成して Parameter Store に保存したエージェント設定ファイルの名前を入力します。
1. [**Run (実行)**] を選択します。
エージェントが、設定ファイルで指定した設定で開始されます。
**コマンドラインを使用してオンプレミスサーバーで CloudWatch エージェントを開始するには**
+ このコマンドで、`-a fetch-config` によりエージェントは最新バージョンの CloudWatch エージェント設定ファイルをロードし、`-s` がエージェントを開始します。
Linux: Systems Manager Parameter Store に設定ファイルを保存した場合は、次のように入力します。
```
sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -a fetch-config -m onPremise -s -c ssm:configuration-parameter-store-name
```
Linux: 設定ファイルをローカルコンピュータに保存した場合は、次のコマンドを入力します。*configuration-file-path* は、エージェント設定ファイルへのパスに置き換えます。このファイルの名前は、ウィザードで作成した場合は `config.json` になり、手動で作成した場合は `amazon-cloudwatch-agent.json` になる場合があります。
```
sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -a fetch-config -m onPremise -s -c file:configuration-file-path
```
Windows Server: エージェント設定ファイルを Systems Manager Parameter Store に保存した場合は、PowerShell コンソールから次のように入力します。
```
& "C:\Program Files\Amazon\AmazonCloudWatchAgent\amazon-cloudwatch-agent-ctl.ps1" -a fetch-config -m onPremise -s -c ssm:configuration-parameter-store-name
```
Windows Server: エージェント設定ファイルをローカルコンピュータに保存した場合は、PowerShell コンソールから次のように入力します。*configuration-file-path* は、エージェント設定ファイルへのパスに置き換えます。このファイルの名前は、ウィザードで作成した場合は `config.json` になり、手動で作成した場合は `amazon-cloudwatch-agent.json` になる場合があります。
```
& "C:\Program Files\Amazon\AmazonCloudWatchAgent\amazon-cloudwatch-agent-ctl.ps1" -a fetch-config -m onPremise -s -c file:configuration-file-path
```
# CloudWatch エージェントにより収集されるメトリクス
サーバーの CloudWatch エージェントをインストールすることで、サーバーからメトリクスを収集できます。エージェントを Amazon EC2 インスタンスとオンプレミスサーバーのどちらにもインストールできます。また、Linux、Windows Server、または macOS を実行するコンピュータにエージェントをインストールできます。Amazon EC2 インスタンスにエージェントをインストールした場合、Amazon EC2 インスタンスでデフォルトで有効なメトリクスに加えて、エージェントによってもメトリクスが収集されます。インスタンスに CloudWatch エージェントをインストールする方法については、「[CloudWatch エージェントを使用してメトリクス、ログ、トレースを収集する](Install-CloudWatch-Agent.md)」を参照してください。このセクションを使用すると、CloudWatch エージェントによって収集されるメトリクスについてよく知ることができます。
## Windows Server インスタンスで CloudWatch エージェントにより収集されるメトリクス
Windows Server を実行しているサーバーで、CloudWatch エージェントをインストールすると、Windows パフォーマンスモニターでカウンタに関連付けられているメトリクスを参照できます。これらのカウンタの CloudWatch メトリクス名は、オブジェクト名とカウンタ名の間にスペースを配置することによって作成されます。例えば、CloudWatch では、`% Interrupt Time` オブジェクトの `Processor` カウンタにメトリクス名 `Processor % Interrupt Time` が指定されます。Windows パフォーマンスモニターカウンタの詳細については、Microsoft Windows Server のドキュメントを参照してください。
CloudWatch エージェントにより収集されるメトリクスのデフォルトの名前空間は `CWAgent` ですが、エージェントを構成するときに別の名前空間を指定できます。
## Linux および macOS インスタンスで CloudWatch エージェントにより収集されるメトリクス
次の表では、Linux サーバーおよび macOS コンピュータ上の CloudWatch エージェントで収集できるメトリクスを示しています。
| メトリクス | 説明 |
| --- | --- |
| `cpu_time_active` | 任意の容量で CPU がアクティブになっている時間の長さ。このメトリクスは、1/100 秒単位で測定されます。 単位: なし |
| `cpu_time_guest` | ゲストオペレーティングシステムで CPU が仮想 CPU を実行している時間の長さ。このメトリクスは、1/100 秒単位で測定されます。 単位: なし |
| `cpu_time_guest_nice` | 優先度が低く、他のプロセスにより中断される場合がある、ゲストオペレーティングシステムの仮想 CPU を CPU で実行している時間。このメトリクスは、1/100 秒単位で測定されます。 単位: なし |
| `cpu_time_idle` | CPU がアイドル状態の時間の長さ。このメトリクスは、1/100 秒単位で測定されます。 単位: なし |
| `cpu_time_iowait` | CPU が I/O 操作の完了を待機している時間の長さ。このメトリクスは、1/100 秒単位で測定されます。 単位: なし |
| `cpu_time_irq` | CPU が中断を処理している時間の長さ。このメトリクスは、1/100 秒単位で測定されます。 単位: なし |
| `cpu_time_nice` | プロセスの優先度が低く、優先度の高いプロセスによって簡単に中断される場合がある、ユーザーモードになっている CPU の時間。このメトリクスは、1/100 秒単位で測定されます。 単位: なし |
| `cpu_time_softirq` | CPU がソフトウェアの中断を処理している時間の長さ。このメトリクスは、1/100 秒単位で測定されます。 単位: なし |
| `cpu_time_steal` | CPU が*盗まれた時間*になっている時間の長さ。これは、仮想化環境で他のオペレーティングシステムに費やされる時間です。このメトリクスは、1/100 秒単位で測定されます。 単位: なし |
| `cpu_time_system` | CPU がシステムモードになっている時間の長さ。このメトリクスは、1/100 秒単位で測定されます。 単位: なし |
| `cpu_time_user` | CPU がユーザーモードになっている時間の長さ。このメトリクスは、1/100 秒単位で測定されます。 単位: なし |
| `cpu_usage_active` | 任意の容量で CPU がアクティブになっている時間の割合。 単位: パーセント |
| `cpu_usage_guest` | ゲストオペレーティングシステムで CPU が仮想 CPU を実行している時間の割合。 単位: パーセント |
| `cpu_usage_guest_nice` | 優先度が低く、他のプロセスにより中断される場合がある、ゲストオペレーティングシステムの仮想 CPU を CPU で実行している時間の割合。 単位: パーセント |
| `cpu_usage_idle` | CPU がアイドル状態の時間の割合。 単位: パーセント |
| `cpu_usage_iowait` | CPU が I/O 操作の完了を待機している時間の割合。 単位: パーセント |
| `cpu_usage_irq` | CPU が中断を処理している時間の割合。 単位: パーセント |
| `cpu_usage_nice` | プロセスの優先度が低く、優先度の高いプロセスによって簡単に中断される場合がある、ユーザーモードになっている CPU の時間の割合。 単位: パーセント |
| `cpu_usage_softirq` | CPU がソフトウェアの中断を処理している時間の割合。 単位: パーセント |
| `cpu_usage_steal` | CPU が*盗まれた時間*になっている時間の割合。つまり、仮想化環境で他のオペレーティングシステムに費やされる時間です。 単位: パーセント |
| `cpu_usage_system` | CPU がシステムモードになっている時間の割合。 単位: パーセント |
| `cpu_usage_user` | CPU がユーザーモードになっている時間の割合。 単位: パーセント |
| `disk_free` | ディスクの空き容量。 単位: バイト |
| `disk_inodes_free` | ディスクで使用可能なインデックスノードの数。 単位: カウント |
| `disk_inodes_total` | ディスクで予約されているインデックスノードの合計数。 単位: カウント |
| `disk_inodes_used` | ディスクで使用されているインデックスノードの数。 単位: カウント |
| `disk_total` | 使用済み容量と空き容量を含む、ディスクの合計容量。 単位: バイト |
| `disk_used` | ディスクの使用済み容量。 単位: バイト |
| `disk_used_percent` | ディスクスペース合計に対する使用済みの割合。 単位: パーセント |
| `diskio_iops_in_progress` | デバイスドライバーに発行されたがまだ完了していない I/O リクエストの数。 単位: カウント |
| `diskio_io_time` | ディスクが I/O リクエストをキューに入れている時間の長さ。 単位: ミリ秒 このメトリクスに使用する必要がある唯一の統計は `Sum` です。使用しません。`Average` |
| `diskio_reads` | ディスク読み取り操作の回数。 単位: カウント このメトリクスに使用する必要がある唯一の統計は `Sum` です。使用しません。`Average` |
| `diskio_read_bytes` | ディスクから読み込まれたバイト数。 単位: バイト このメトリクスに使用する必要がある唯一の統計は `Sum` です。使用しません。`Average` |
| `diskio_read_time` | 読み取りリクエストがディスクで待機した時間の長さ。複数の読み込みリクエストが同時に待機している場合、その分数値が増えます。たとえば、5 つのリクエストが平均 100 ミリ秒待機している場合、500 と報告されます。 単位: ミリ秒 このメトリクスに使用する必要がある唯一の統計は `Sum` です。使用しません。`Average` |
| `diskio_writes` | ディスク書き込み操作の回数。 単位: カウント このメトリクスに使用する必要がある唯一の統計は `Sum` です。使用しません。`Average` |
| `diskio_write_bytes` | ディスクへの書き込みバイト数。 単位: バイト このメトリクスに使用する必要がある唯一の統計は `Sum` です。使用しません。`Average` |
| `diskio_write_time` | 書き込みリクエストがディスクで待機した時間の長さ。複数の書き込みリクエストが同時に待機している場合、その分数値が増えます。たとえば、8 つのリクエストが平均 1000 ミリ秒待機している場合、8000 と報告されます。 単位: ミリ秒 このメトリクスに使用する必要がある唯一の統計は `Sum` です。`Average` を使用しないでください。 |
| `ethtool_bw_in_allowance_exceeded` | インバウンド集計の帯域幅がインスタンスの最大値を超えたために、キューおよび (または) ドロップされたパケットの数。 このメトリクスは、CloudWatch エージェント設定ファイルの `ethtool` セクションの `metrics_collected` サブセクションにリストされている場合にのみ収集されます。詳細については、[ネットワークパフォーマンスメトリクスの収集](CloudWatch-Agent-network-performance.md) を参照してください。 単位: なし |
| `ethtool_bw_out_allowance_exceeded` | アウトバウンド集計の帯域幅がインスタンスの最大値を超えたために、キューおよび (または) ドロップされたパケットの数。 このメトリクスは、CloudWatch エージェント設定ファイルの `ethtool` セクションの `metrics_collected` サブセクションにリストされている場合にのみ収集されます。詳細については、[ネットワークパフォーマンスメトリクスの収集](CloudWatch-Agent-network-performance.md) を参照してください。 単位: なし |
| `ethtool_conntrack_allowance_exceeded` | 接続トラッキングがインスタンスの最大数を超え、新しい接続を確立できなかったためにドロップされたパケットの数。これにより、インスタンスとの間で送受信されるトラフィックのパケット損失が発生する可能性があります。 このメトリクスは、CloudWatch エージェント設定ファイルの `ethtool` セクションの `metrics_collected` サブセクションにリストされている場合にのみ収集されます。詳細については、[ネットワークパフォーマンスメトリクスの収集](CloudWatch-Agent-network-performance.md) を参照してください。 単位: なし |
| `ethtool_linklocal_allowance_exceeded` | ローカルプロキシサービスへのトラフィックの PPS がネットワークインターフェイスの最大値を超えたためにドロップされたパケットの数。これは、DNS サービス、インスタンスメタデータサービス、および Amazon Time Sync Service へのトラフィックに影響します。 このメトリクスは、CloudWatch エージェント設定ファイルの `ethtool` セクションの `metrics_collected` サブセクションにリストされている場合にのみ収集されます。詳細については、[ネットワークパフォーマンスメトリクスの収集](CloudWatch-Agent-network-performance.md) を参照してください。 単位: なし |
| `ethtool_pps_allowance_exceeded` | 双方向 PPS がインスタンスの最大値を超えたために、キューおよび (または) ドロップされたパケットの数。 このメトリクスは、CloudWatch エージェント設定ファイルの `ethtool` セクションの `metrics_collected` サブセクションにリストされている場合にのみ収集されます。詳細については、「[ネットワークパフォーマンスメトリクスの収集](CloudWatch-Agent-network-performance.md)」を参照してください。 単位: なし |
| `mem_active` | 最後のサンプル期間中に何らかの方法で使用されたメモリの量。 単位: バイト |
| `mem_available` | すぐにプロセスに渡すことができる使用可能なメモリの量。 単位: バイト |
| `mem_available_percent` | すぐにプロセスに渡すことができる使用可能なメモリの割合。 単位: パーセント |
| `mem_buffered` | バッファに使用されているメモリの量。 単位: バイト |
| `mem_cached` | ファイルキャッシュに使用されているメモリの量。 単位: バイト |
| `mem_free` | 使用されていないメモリの量。 単位: バイト |
| `mem_inactive` | 最後のサンプル期間中に何らかの方法で使用されていないメモリの量 単位: バイト |
| `mem_shared` | プロセス間で共有されるメモリの量。 単位: バイト |
| `mem_total` | メモリの合計量。 単位: バイト |
| `mem_used` | 現在使用中のメモリの量。 単位: バイト |
| `mem_used_percent` | 現在使用中のメモリの割合。 単位: パーセント |
| `net_bytes_recv` | ネットワークインターフェイスで受信されたバイトの数。 単位: バイト このメトリクスに使用する必要がある唯一の統計は `Sum` です。使用しません。`Average` |
| `net_bytes_sent` | ネットワークインターフェイスで送信されたバイトの数。 単位: バイト このメトリクスに使用する必要がある唯一の統計は `Sum` です。使用しません。`Average` |
| `net_drop_in` | このネットワークインターフェイスで受信されたパケットのうち、削除されたものの数。 単位: カウント このメトリクスに使用する必要がある唯一の統計は `Sum` です。使用しません。`Average` |
| `net_drop_out` | このネットワークインターフェイスで送信されたパケットのうち、削除されたものの数。 単位: カウント このメトリクスに使用する必要がある唯一の統計は `Sum` です。使用しません。`Average` |
| `net_err_in` | このネットワークインターフェイスによって検出された受信エラーの数。 単位: カウント このメトリクスに使用する必要がある唯一の統計は `Sum` です。使用しません。`Average` |
| `net_err_out` | このネットワークインターフェイスによって検出された送信エラーの数。 単位: カウント このメトリクスに使用する必要がある唯一の統計は `Sum` です。使用しません。`Average` |
| `net_packets_sent` | このネットワークインターフェイスで送信されたパケットの数。 単位: カウント このメトリクスに使用する必要がある唯一の統計は `Sum` です。使用しません。`Average` |
| `net_packets_recv` | このネットワークインターフェイスで受信されたパケットの数。 単位: カウント このメトリクスに使用する必要がある唯一の統計は `Sum` です。使用しません。`Average` |
| `netstat_tcp_close` | 状態のない TCP 接続の数。 単位: カウント |
| `netstat_tcp_close_wait` | クライアントからの終了リクエストを待機している TCP 接続の数。 単位: 数 |
| `netstat_tcp_closing` | クライアントからの確認付き終了リクエストを待機している TCP 接続の数。 単位: 数 |
| `netstat_tcp_established` | 確立された TCP 接続の数。 単位: カウント |
| `netstat_tcp_fin_wait1` | 接続の終了プロセス時に `FIN_WAIT1` 状態になっている TCP 接続の数。 単位: カウント |
| `netstat_tcp_fin_wait2` | 接続の終了プロセス時に `FIN_WAIT2` 状態になっている TCP 接続の数。 単位: 数 |
| `netstat_tcp_last_ack` | クライアントが接続終了メッセージの確認を送信するのを待機している TCP 接続の数。これは、接続が終了する直前の最後の状態です。 単位: カウント |
| `netstat_tcp_listen` | 現在接続リクエストをリッスンしている TCP ポートの数。 単位: カウント |
| `netstat_tcp_none` | 非アクティブなクライアントを持つ TCP 接続の数。 単位: カウント |
| `netstat_tcp_syn_sent` | 接続リクエストを送信したあとに一致する接続リクエストを待機している TCP 接続の数。 単位: 数 |
| `netstat_tcp_syn_recv` | 接続リクエストを送受信したあとに接続リクエスト確認を待機している TCP 接続の数。 単位: 数 |
| `netstat_tcp_time_wait` | クライアントが接続終了リクエストの確認を受信したことが確認されるのを現在待機している TCP 接続の数。 単位: 数 |
| `netstat_udp_socket` | 現在の UDP 接続の数。 単位: カウント |
| `processes_blocked` | ブロックされているプロセスの数。 単位: カウント |
| `processes_dead` | 「dead」となっているプロセスの数。Linux では、`X` 状態コードにより示されます。 このメトリクスは macOS コンピュータでは収集されません。 単位: カウント |
| `processes_idle` | アイドル状態になっているプロセスの数 (20 秒以上スリープ状態)。FreeBSD インスタンスでのみ使用できます。 単位: カウント |
| `processes_paging` | 「paging」となっているプロセスの数。Linux では、`W` 状態コードにより示されます。 このメトリクスは macOS コンピュータでは収集されません。 単位: カウント |
| `processes_running` | 実行されているプロセスの数。`R` 状態コードにより示されます。 単位: カウント |
| `processes_sleeping` | スリープ状態になっているプロセスの数。`S` 状態コードにより示されます。 単位: カウント |
| `processes_stopped` | 停止されているプロセスの数。`T` 状態コードにより示されます。 単位: カウント |
| `processes_total` | インスタンス上でのプロセスの合計数。 単位: カウント |
| `processes_total_threads` | プロセスを構成するスレッドの合計数。このメトリクスは、Linux インスタンスでのみご利用いただけます。 このメトリクスは macOS コンピュータでは収集されません。 単位: カウント |
| `processes_wait` | ページングしているプロセスの数。FreeBSD インスタンスでは、`W` 状態コードにより示されます。このメトリクスは FreeBSD インスタンスでのみ使用でき、Linux、Windows サーバー、macOS インスタンスでは使用できません。 単位: カウント |
| `processes_zombies` | ゾンビ状態のプロセスの数。`Z` 状態コードにより示されます。 単位: カウント |
| `swap_free` | 使用されていないスワップスペースの量。 単位: バイト |
| `swap_used` | 現在使用中のスワップスペースの量。 単位: バイト |
| `swap_used_percent` | 現在使用中のスワップスペースの割合。 単位: パーセント |
## CloudWatch エージェントにより収集されるメモリメトリクスの定義
CloudWatch エージェントがメモリメトリクスを収集する場合、ソースはホストのメモリ管理サブシステムです。例えば、Linux カーネルは OS が管理する `/proc` 内のデータを公開します。メモリについては、データは `/proc/meminfo` にあります。
オペレーティングシステムとアーキテクチャが異なれば、プロセスが使用するリソースの計算も異なります。詳細については、次のセクションを参照してください。
各収集間隔において、各インスタンスの CloudWatch エージェントはインスタンスリソースを収集し、そのインスタンスで実行されているすべてのプロセスが使用しているリソースを計算します。この情報は CloudWatch メトリクスに報告されます。収集間隔の長さは、CloudWatch エージェント設定ファイルで設定できます。詳細については、「[CloudWatch エージェント設定ファイル: Agent セクション](CloudWatch-Agent-Configuration-File-Details.md#CloudWatch-Agent-Configuration-File-Agentsection)」を参照してください。
次のリストで、CloudWatch エージェントが収集するメモリメトリクスの定義方法を説明します。
+ **アクティブメモリ** — プロセスが使用しているメモリです。つまり、現在実行中のアプリで使用されているメモリのことです。
+ **使用可能なメモリ** — システムがスワップ状態にならずにプロセスに瞬時に割り当てられるメモリ (仮想メモリとも呼ばれます) です。
+ **バッファメモリ** — さまざまな速度と優先順位で動作するハードウェアデバイスまたはプログラムプロセスによって共有されるデータ領域です。
+ **キャッシュされたメモリ** — CPU が次に必要とする可能性のあるプログラムの操作で繰り返し使用されるプログラム手順とデータを保存します。
+ **空きメモリ** — まったく使用されておらず、すぐに使用できるメモリです。このメモリは完全に空で、必要なときにシステムで使用できます。
+ **非アクティブなメモリ**— 「最近は」アクセスされていないページです。
+ **合計メモリ** — 実際の物理メモリ RAM のサイズです。
+ **使用済みメモリ**— プログラムやプロセスによって現在使用されているメモリです。
**Topics**
+ [
### Linux: 収集されたメトリクスと使用された計算
](#CloudWatch-agent-metrics-definitions-calculations)
+ [
### macOS: 収集されたメトリクスと使用された計算
](#CloudWatch-agent-metrics-definitions-calculations)
+ [
### Windows: 収集されたメトリクス
](#CloudWatch-agent-metrics-definitions-calculations)
+ [
### 例: Linux でのメモリメトリクスの計算
](#CloudWatch-agent-metrics-definitions-LinuxExample)
### Linux: 収集されたメトリクスと使用された計算
収集されたメトリクスと単位:
+ アクティブ (バイト)
+ 使用可能 (バイト)
+ 使用可能率 (パーセント)
+ バッファ済み (バイト)
+ キャッシュ済み (バイト)
+ 空き (バイト)
+ 非アクティブ (バイト)
+ 合計 (バイト)
+ 使用済み (バイト)
+ 使用率 (パーセント)
**使用済みメモリ** = 合計メモリ - 空きメモリ - キャッシュされたメモリ - バッファメモリ
**合計メモリ** = 使用済みメモリ \$1 空きメモリ \$1 キャッシュされたメモリ \$1 バッファメモリ
### macOS: 収集されたメトリクスと使用された計算
収集されたメトリクスと単位:
+ アクティブ (バイト)
+ 使用可能 (バイト)
+ 使用可能率 (パーセント)
+ 空き (バイト)
+ 非アクティブ (バイト)
+ 合計 (バイト)
+ 使用済み (バイト)
+ 使用率 (パーセント)
**使用可能なメモリ** = 空きメモリ \$1 非アクティブなメモリ
**使用済みメモリ** = 合計メモリ - 使用可能なメモリ
**合計メモリ** = 使用可能なメモリ \$1 使用済みメモリ
### Windows: 収集されたメトリクス
Windows ホストで収集されたメトリクスは以下のとおりです。これらのメトリクスの `Unit` はすべて `None` です。
+ 使用可能バイト
+ キャッシュ障害数/秒
+ ページ障害数/秒
+ ページ数/秒
CloudWatch エージェントはパフォーマンスカウンターからイベントを解析するため、Windows メトリクスの計算は行われません。
### 例: Linux でのメモリメトリクスの計算
例として、Linux ホストで **cat /proc/meminfo** のコマンドを入力すると、次の結果が表示されるとします。
```
MemTotal: 3824388 kB
MemFree: 462704 kB
MemAvailable: 2157328 kB
Buffers: 126268 kB
Cached: 1560520 kB
SReclaimable: 289080 kB>
```
この例では、CloudWatch エージェントは次の値を収集します。CloudWatch エージェントが収集してレポートする値はすべてバイト単位です。
+ `mem_total`: 3916173312 バイト
+ `mem_available`: 2209103872 バイト (メモリフリー \$1 キャッシュ)
+ `mem_free`: 473808896 バイト
+ `mem_cached`: 1893990400 バイト (`cached` \$1 `SReclaimable`)
+ `mem_used`: 1419075584 バイト (`MemTotal` — (`MemFree` \$1 `Buffers` \$1 (`Cached` \$1 `SReclaimable`)))
+ `mem_buffered`: 129667072 バイト
+ `mem_available_percent`: 56.41%
+ `mem_used_percent`: 36.24% (`mem_used` / `mem_total`) \$1 100
# 関連するテレメトリで CloudWatch エージェントの使用
CloudWatch に送信されるメトリクスおよびログには、テレメトリを関連付けるオプションのエンティティを含めることができます。エンティティは、[関連情報の探索](ExploreRelated.md)ペインで使用されます。CloudWatch エージェントは、サービス名および環境名を含むエンティティを送信します。
エージェントは、次のデータからサービス名および環境名を選択します。
[**サービス名**]
エージェントは、優先順位で次のオプションからサービス名を選択します。
+ **Application Signals の計測** – エージェントは Application Signals で使用されるサービス名を送信します。サポートされている OpenTelemetry 計測ライブラリで使用される `OTEL_SERVICE_NAME` 環境変数を変更することによって上書きできます。
+ **CloudWatch エージェント設定** – 特定のサービス名を使用するように[エージェントを設定できます](CloudWatch-Agent-configure-related-telemetry.md)。エージェント、プラグイン、メトリクス、ログ、ログファイルのレベルで設定できます。
+ **Kubernetes ワークロード名** – Kubernetes ワークロードの場合、エージェントは次の優先順位で対応するポッドのワークロードの名前を送信します。
+ デプロイ名
+ ReplicaSet 名
+ StatefulSet 名
+ DaemonSet 名
+ CronJob 名
+ ジョブ名
+ ポッド名
+ コンテナ名
+ **インスタンスメタデータからのリソースタグ** – Amazon EC2 ワークロードの場合、エージェントはタグから名前を次の順序で送信します。
+ サービス
+ アプリケーション
+ できます
エージェントがタグにアクセスするには、[インスタンスメタデータを設定する](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/work-with-tags-in-IMDS.html#allow-access-to-tags-in-IMDS)必要があります。
+ **デフォルト** – その他のサービス名が見つからなかった場合、エージェントは `Unknown` の名前を送信します。
**環境名**
エージェントは、優先順位で次のオプションから環境名を選択します。
+ **Application Signals の計測** — エージェントは Application Signals で使用される環境名を送信します。サポートされている OpenTelemetry 計測ライブラリで使用される `deployment.environment` 環境変数を設定することによって上書きできます。例えば、アプリケーションは環境変数 `OTEL_RESOURCE_ATTRIBUTES=deployment.environment=MyEnvironment` を設定できます。
+ **CloudWatch エージェント設定** – 特定の環境名を使用するように[エージェントを設定](CloudWatch-Agent-configure-related-telemetry.md)できます。エージェント、プラグイン、メトリクス、ログ、ログファイルのレベルで設定できます。
+ **クラスター名とワークスペース** – Amazon EKS の場合は `eks:cluster-name/Namespace`。Amazon EC2 で実行されているネイティブ Kubernetes の場合は `k8s:cluster-name/Namespace`。
+ **インスタンスメタデータからのリソースタグ** – Amazon EC2 ワークロードの場合、エージェントは `AutoScalingGroup` タグを使用できます。
エージェントがタグにアクセスするには、[インスタンスメタデータを設定する](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/work-with-tags-in-IMDS.html#allow-access-to-tags-in-IMDS)必要があります。
+ デフォルトでは、Kubernetes を実行していない Amazon EC2 インスタンスは環境名 `ec2:default` を取得します。
# CloudWatch エージェントの一般的なシナリオ
このセクションでは、CloudWatch エージェントに共通する設定とカスタマイズのタスクを完了する方法をまとめたさまざまなシナリオについて説明します。
**Topics**
+ [
## CloudWatch エージェントの別のユーザーとしての実行
](#CloudWatch-Agent-run-as-user)
+ [
## CloudWatch エージェントがスパースログファイルを処理する方法
](#CloudWatch-Agent-sparse-log-files)
+ [
## CloudWatch エージェントにより収集されるメトリクスへのカスタムディメンションの追加
](#CloudWatch-Agent-adding-custom-dimensions)
+ [
## CloudWatch エージェントによって収集されるメトリクスの集約またはロールアップ
](#CloudWatch-Agent-aggregating-metrics)
+ [
## CloudWatch エージェントを使用した高解像度メトリクスの収集
](#CloudWatch-Agent-collect-high-resolution-metrics)
+ [
## 別のアカウントへのメトリクス、ログ、トレースの送信
](#CloudWatch-Agent-send-to-different-AWS-account)
+ [
## CloudWatch エージェントと前の CloudWatch Logs エージェントとの間のタイムスタンプの違い
](#CloudWatch-Agent-logs-timestamp-differences)
+ [
## OpenTelemetry コレクター設定ファイルの追加
](#CloudWatch-Agent-appending-OpenTelemetry-config-files)
## CloudWatch エージェントの別のユーザーとしての実行
Linux サーバーでは、CloudWatch はデフォルトで root ユーザーとして実行されます。エージェントを別のユーザーとして実行するには、CloudWatch エージェント設定ファイルの `agent` セクションで `run_as_user` パラメータを使用します。このオプションは、Linux サーバーでのみ使用できます。
エージェントを root ユーザーとして既に実行している場合、別のユーザーに変更するには、以下のいずれかの手順を使用します。
**Linux を実行する EC2 インスタンスで CloudWatch エージェントを別のユーザーとして実行するには**
1. 新しい CloudWatch エージェントパッケージをダウンロードしてインストールします。
1. 新しい Linux ユーザーを作成するか、RPM ファイルまたは DEB ファイルで作成した `cwagent` という名前のデフォルトユーザーを使用します。
1. 次のいずれかの方法で、このユーザーの認証情報を指定します。
+ このファイル `.aws/credentials` が root ユーザーのホームディレクトリに存在する場合は、CloudWatch エージェントの実行に使用するユーザーの認証情報ファイルを作成する必要があります。この認証情報ファイルは `/home/username/.aws/credentials` になります。次に、`shared_credential_file` の `common-config.toml` パラメータの値を認証情報ファイルのパス名に設定します。詳細については、「[AWS Systems Manager を使用して CloudWatch エージェントをインストールする](installing-cloudwatch-agent-ssm.md)」を参照してください。
+ ファイル `.aws/credentials` が root ユーザーのホームディレクトリに存在しない場合は、次のいずれかの操作を実行できます。
+ CloudWatch エージェントの実行に使用するユーザーの認証情報ファイルを作成します。この認証情報ファイルは `/home/username/.aws/credentials` になります。次に、`shared_credential_file` の `common-config.toml` パラメータの値を認証情報ファイルのパス名に設定します。詳細については、「[AWS Systems Manager を使用して CloudWatch エージェントをインストールする](installing-cloudwatch-agent-ssm.md)」を参照してください。
+ 認証情報ファイルを作成する代わりに、IAM ロールをインスタンスにアタッチします。エージェントは、このロールを認証情報プロバイダーとして使用します。
1. CloudWatch エージェント設定ファイルで、`agent` セクションに次の行を追加します。
```
"run_as_user": "username"
```
必要に応じて、設定ファイルに他の変更を行います。詳細については、[CloudWatch エージェント設定ファイルを作成する](create-cloudwatch-agent-configuration-file.md)を参照してください。
1. 必要なアクセス許可をユーザーに付与します。ユーザーには、収集するログファイルの読み取り (r) アクセス許可と、ログファイルのパス内のすべてのディレクトリに対する実行 (x) アクセス許可が必要です。
1. 先ほど作成した設定ファイルを使用してエージェントを起動します。
```
sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -a fetch-config -m ec2 -s -c file:configuration-file-path
```
**Linux を実行しているオンプレミスサーバーで CloudWatch エージェントを別のユーザーとして実行するには**
1. 新しい CloudWatch エージェントパッケージをダウンロードしてインストールします。
1. 新しい Linux ユーザーを作成するか、RPM ファイルまたは DEB ファイルで作成した `cwagent` という名前のデフォルトユーザーを使用します。
1. このユーザーの認証情報をユーザーがアクセスできるパス (`/home/username/.aws/credentials` など) に保存します。
1. `shared_credential_file` の `common-config.toml` パラメータの値を認証情報ファイルのパス名に指定します。詳細については、「[AWS Systems Manager を使用して CloudWatch エージェントをインストールする](installing-cloudwatch-agent-ssm.md)」を参照してください。
1. CloudWatch エージェント設定ファイルで、`agent` セクションに次の行を追加します。
```
"run_as_user": "username"
```
必要に応じて、設定ファイルに他の変更を行います。詳細については、[CloudWatch エージェント設定ファイルを作成する](create-cloudwatch-agent-configuration-file.md)を参照してください。
1. 必要なアクセス許可をユーザーに付与します。ユーザーには、収集するログファイルの読み取り (r) アクセス許可と、ログファイルのパス内のすべてのディレクトリに対する実行 (x) アクセス許可が必要です。
1. 先ほど作成した設定ファイルを使用してエージェントを起動します。
```
sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -a fetch-config -m ec2 -s -c file:configuration-file-path
```
## CloudWatch エージェントがスパースログファイルを処理する方法
スパースファイルは、空のブロックと実際のコンテンツの両方を持つファイルです。スパースファイルは、ブロックを構成する実際の null バイトの代わりに、空のブロックを表す簡単な情報をディスクに書き込むことによって、より効率的にディスク領域を使用します。これにより、スパースファイルの実際のサイズは、通常、見かけのサイズよりもずっと小さくなります。
ただし、CloudWatch エージェントはスパースファイルを通常のファイルと同じ方法で処理します。エージェントがスパースファイルを読み取ると、空のブロックは null バイトで満たされた「実」ブロックとして扱われます。このため、CloudWatch エージェントは、スパースファイルの見かけ上のサイズと同じバイト数を CloudWatch に発行します。
スパースファイルを発行するように CloudWatch エージェントを設定すると、予想よりも CloudWatch コストが高くなる可能性があるため、この設定を避けるようお勧めします。例えば、Linux の `/var/logs/lastlog` は非常にスパースなファイルであることが多いため、これを CloudWatch に発行しないようお勧めします。
## CloudWatch エージェントにより収集されるメトリクスへのカスタムディメンションの追加
エージェントによって収集されるメトリクスにタグなどのカスタムディメンションを追加するには、それらのメトリクスをリストするエージェント設定ファイルのセクションに `append_dimensions` フィールドを追加します。
たとえば、設定ファイルの次のサンプルセクションでは、値が `stackName` の `Prod` というカスタムディメンションを、エージェントによって収集される `cpu` および `disk` メトリクスに追加します。
```
"cpu":{
"resources":[
"*"
],
"measurement":[
"cpu_usage_guest",
"cpu_usage_nice",
"cpu_usage_idle"
],
"totalcpu":false,
"append_dimensions":{
"stackName":"Prod"
}
},
"disk":{
"resources":[
"/",
"/tmp"
],
"measurement":[
"total",
"used"
],
"append_dimensions":{
"stackName":"Prod"
}
}
```
エージェント設定ファイルを変更するときは必ず、エージェントを再起動して変更を有効にする必要がある点に注意してください。
## CloudWatch エージェントによって収集されるメトリクスの集約またはロールアップ
エージェントにより収集されたメトリクスを集約 (ロールアップ) するには、`aggregation_dimensions` フィールドをエージェント設定ファイル内のそのメトリクスのセクションに追加します。
たとえば、次の設定ファイルスニペットでは、`AutoScalingGroupName` ディメンションでメトリクスをロールアップします。各 Auto Scaling グループ内のすべてのインスタンスのメトリクスが集約され、全体として参照できるようになります。
```
"metrics": {
"cpu":{...}
"disk":{...}
"aggregation_dimensions" : [["AutoScalingGroupName"]]
}
```
Auto Scaling グループ名でのロールアップのほかに、各 `InstanceId` および `InstanceType` ディメンションの組み合わせでもロールアップするには、次の内容を追加します。
```
"metrics": {
"cpu":{...}
"disk":{...}
"aggregation_dimensions" : [["AutoScalingGroupName"], ["InstanceId", "InstanceType"]]
}
```
代わりにメトリクスを 1 つのコレクションにロールアップするには、`[]` を使用します。
```
"metrics": {
"cpu":{...}
"disk":{...}
"aggregation_dimensions" : [[]]
}
```
エージェント設定ファイルを変更するときは必ず、エージェントを再起動して変更を有効にする必要がある点に注意してください。
## CloudWatch エージェントを使用した高解像度メトリクスの収集
`metrics_collection_interval` フィールドは、収集されるメトリクスの時間間隔 (秒単位) を指定します。このフィールドに 60 未満の値を指定することによって、メトリクスは、高解像度メトリクスとして収集されます。
たとえば、すべてのメトリクスを高解像度で 10 秒ごとに収集する必要がある場合は、`metrics_collection_interval` セクションで、グローバルメトリクス収集間隔として `agent` の値を 10 に指定します。
```
"agent": {
"metrics_collection_interval": 10
}
```
または、次の例では `cpu` メトリクスを 1 秒ごとに収集し、他のすべてのメトリクスを 1 分ごとに収集するように設定します。
```
"agent":{
"metrics_collection_interval": 60
},
"metrics":{
"metrics_collected":{
"cpu":{
"resources":[
"*"
],
"measurement":[
"cpu_usage_guest"
],
"totalcpu":false,
"metrics_collection_interval": 1
},
"disk":{
"resources":[
"/",
"/tmp"
],
"measurement":[
"total",
"used"
]
}
}
}
```
エージェント設定ファイルを変更するときは必ず、エージェントを再起動して変更を有効にする必要がある点に注意してください。
## 別のアカウントへのメトリクス、ログ、トレースの送信
CloudWatch エージェントがメトリクス、ログ、またはトレースを別のアカウントに送信するには、送信サーバーのエージェント設定ファイルで `role_arn` パラメータを指定します。`role_arn` 値は、エージェントがターゲットアカウントにデータを送信する際に使用するターゲットアカウントの IAM ロールを指定します。このロールにより、メトリクスまたはログをターゲットアカウントに配信するときに、送信アカウントがターゲットアカウントの対応するロールを担うことができます。
エージェント設定ファイルには、個別の `role_arn` 文字列を指定することもできます。1 つはメトリクスを送信するときに、1 つはログを送信するために、もう 1 つはトレースを送信するために使用します。
次の設定ファイルの `agent` セクションの一部の例は、データを別のアカウントに送信するときにエージェントが `CrossAccountAgentRole` を使用するように設定します。
```
{
"agent": {
"credentials": {
"role_arn": "arn:aws:iam::123456789012:role/CrossAccountAgentRole"
}
},
.....
}
```
または、次の例では、送信アカウントがメトリクス、ログ、トレースを送信するために使用する別々のロールを設定しています。
```
"metrics": {
"credentials": {
"role_arn": "RoleToSendMetrics"
},
"metrics_collected": {....
```
```
"logs": {
"credentials": {
"role_arn": "RoleToSendLogs"
},
....
```
**必要なポリシー**
エージェント設定ファイルで `role_arn` を指定する場合は、送信アカウントとターゲットアカウントの IAM ロールに特定のポリシーが設定されていることも確認する必要があります。送信アカウントとターゲットアカウントの両方のロールに、[`CloudWatchAgentServerPolicy`] が必要です。このポリシーをロールに割り当てる方法の詳細については、「[前提条件](prerequisites.md)」を参照してください。
また、送信側アカウントのロールに次のポリシーも含まれている必要があります。このポリシーは、ロールを編集するときに IAM コンソールの [**アクセス許可**] タブで追加します。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"sts:AssumeRole"
],
"Resource": [
"arn:aws:iam::111122223333:role/agent-role-in-target-account"
]
}
]
}
```
------
また、ターゲットアカウントのロールには、送信側アカウントで使用される IAM ロールを認識できるように、次のポリシーが含まれている必要があります。このポリシーは、ロールを編集するときに IAM コンソールの [**信頼関係**] タブで追加します。このロールは、送信側アカウントで使用されるポリシーの `agent-role-in-target-account` で指定したロールです。
------
#### [ JSON ]
****
```
{
"Version":"2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": [
"arn:aws:iam::111122223333:role/role-in-sender-account"
]
},
"Action": "sts:AssumeRole"
}
]
}
```
------
## CloudWatch エージェントと前の CloudWatch Logs エージェントとの間のタイムスタンプの違い
CloudWatch エージェントでは、前の CloudWatch Logs エージェントと比べて、タイムスタンプ形式のさまざまな記号のセットがサポートされています。これらの違いを次の表に示します。
| 両方のエージェントがサポートする記号 | CloudWatch エージェントのみがサポートする記号 | 前の CloudWatch Logs エージェントでのみサポートされている記号 |
| --- | --- | --- |
| %A､%a、%b、%B、%d、%f、%H、%l、%m、%M、%p、%S、%y、%Y、%Z、%z | %-d、%-l、%m、%M、%-S | %c、% j、%U、%W、%w |
新しい CloudWatch エージェントでサポートされる記号の意味の詳細については、*Amazon CloudWatch ユーザーガイド*の「[CloudWatch エージェント設定ファイル: ログセクション](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/CloudWatch-Agent-Configuration-File-Details.html#CloudWatch-Agent-Configuration-File-Logssection)」を参照してください。CloudWatch Logs エージェントでサポートされる記号については、*Amazon CloudWatch Logs ユーザーガイド*の「[エージェント設定ファイル](https://docs.aws.amazon.com/AmazonCloudWatch/latest/logs/AgentReference.html#agent-configuration-file)」を参照してください。
## OpenTelemetry コレクター設定ファイルの追加
CloudWatch エージェントは、独自の設定ファイルとともに、補足的な OpenTelemetry コレクター設定ファイルをサポートします。この機能を使用すると、CloudWatch エージェント設定を通じて CloudWatch Application Signals や Container Insights などの CloudWatch エージェント機能が使用できます。また、単一のエージェントで既存の OpenTelemetry コレクター設定を取り込むこともできます。
CloudWatch エージェントによって自動的に作成されたパイプラインとのマージ競合を防ぐには、OpenTelemetry コレクター設定の各コンポーネントおよびパイプラインにカスタムサフィックスを追加することをお勧めします。
```
receivers:
otlp/custom-suffix:
protocols:
http:
exporters:
awscloudwatchlogs/custom-suffix:
log_group_name: "test-group"
log_stream_name: "test-stream"
service:
pipelines:
logs/custom-suffix:
receivers: [otlp/custom-suffix]
exporters: [awscloudwatchlogs/custom-suffix]
```
CloudWatch エージェントを設定するには、`fetch-config` オプションを使用して CloudWatch エージェントを起動し、CloudWatch エージェントの設定ファイルを指定します。CloudWatch エージェントには、少なくとも 1 つの CloudWatch エージェント設定ファイルが必要です。
```
/opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -a fetch-config -c file:/tmp/agent.json -s
```
次に、OpenTelemetry コレクター設定ファイルを指定するときに `append-config`オプションを使用します。
```
/opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -a append-config -c file:/tmp/otel.yaml -s
```
エージェントは起動時に 2 つの設定ファイルをマージし、解決された設定をログ記録します。
# CloudWatch エージェント認証情報の優先設定
このセクションでは、CloudWatch エージェントが他の AWS サービスや API と通信する際に認証情報を取得するために使用する認証情報プロバイダーチェーンの概要を説明します。順序は次のとおりです。
**注記**
2 番目から 5 番目までの設定は、AWS SDK で定義されている優先順位と同じです。詳細については、SDK ドキュメントの「[認証情報の指定](https://docs.aws.amazon.com/sdk-for-go/v1/developer-guide/configuring-sdk.html#specifying-credentials)」を参照してください。
1. CloudWatch エージェントの `common-config.toml` ファイルに定義されている共有設定ファイルおよび認証情報ファイル。詳細については、「[AWS Systems Manager を使用して CloudWatch エージェントをインストールする](installing-cloudwatch-agent-ssm.md)」を参照してください。
1. AWS SDK 環境変数
**重要**
Linux では、`amazon-cloudwatch-agent-ctl` スクリプトを使用して CloudWatch エージェントを実行する場合、スクリプトはエージェントを `systemd` サービスとして起動します。この場合、`HOME`、`AWS_ACCESS_KEY_ID`、`AWS_SECRET_ACCESS_KEY` などの環境変数にはエージェントからアクセスできません。
1. `$HOME/%USERPROFILE%` にある共有設定ファイルおよび認証情報ファイル。
**注記**
CloudWatch エージェントは、Linux と MacOS の場合は `$HOME` の `.aws/credentials` を検索し、Windows の場合は `%USERPROFILE%` を検索します。AWS SDK とは異なり、CloudWatch エージェントには、環境変数にアクセスできない場合にホームディレクトリを決定するフォールバックメソッドはありません。この動作の違いは、AWS SDK の以前の実装との下位互換性を維持するためです。
さらに、`common-config.toml` にある共有認証情報とは異なり、AWS SDK から派生した共有認証情報が期限切れになってローテーションされても、更新された認証情報は CloudWatch エージェントによって自動的に取得されないため、エージェントの再起動が必要になります。
1. Amazon Elastic Container Service タスク定義または RunTask API オペレーションを使用するアプリケーションが存在する場合、タスクの AWS Identity and Access Management ロール。
1. Amazon EC2 インスタンスにアタッチされたインスタンスプロファイル。
ベストプラクティスとして、CloudWatch エージェントを使用するときは、次の順序で認証情報を指定することをお勧めします。
1. アプリケーションが Amazon Elastic Container Service タスク定義または RunTask API オペレーションを使用している場合は、タスクの IAM ロールを使用します。
1. アプリケーションが Amazon EC2 インスタンスで実行される場合は、IAM ロールを使用します。
1. CloudWatch エージェントの `common-config.toml` ファイルを使用して認証情報ファイルを指定します。この認証情報ファイルと同じものが他の AWS SDK や AWS CLI でも使用されます。共有の認証情報ファイルを既に使用している場合は、そのファイルを当目的にも使用できます。CloudWatch エージェントの `common-config.toml` ファイルを使用して提供する場合、認証情報の有効期限が切れて置き換えられるときに、エージェントを再起動しなくてもローテーションされた認証情報をエージェントが使用できるようになります。
1. 環境変数を使用します。Amazon EC2 インスタンス以外のコンピュータで開発作業を行う場合は、環境変数を設定すると便利です。
**注記**
「[別のアカウントへのメトリクス、ログ、トレースの送信](CloudWatch-Agent-common-scenarios.md#CloudWatch-Agent-send-to-different-AWS-account)」で説明されているように、テレメトリを別のアカウントに送信する場合、CloudWatch エージェントは、このセクションで説明する認証情報プロバイダーチェーンを使用して、認証情報の初期セットを取得します。その後、CloudWatch エージェント設定ファイルの `role_arn` で指定された IAM ロールを引き受けるときに、これらの認証情報を使用します。
# CloudWatch エージェントのトラブルシューティング
このセクションの情報を使用すると、CloudWatch エージェントで発生しうる問題をトラブルシューティングできます。
CloudWatch エージェントで問題が発生したときは、`AWSSupport-TroubleshootCloudWatchAgent` 自動化ランブックを使用できます。AWS トラブルシューティングツールでは、以下のことができます。
+ IAM アクセス許可およびインスタンスプロファイルを検証する
+ エージェントのステータスをチェックし、ログを分析する
+ エンドポイントの接続性をテストする
+ 関連するログを自動的に収集して Amazon S3 にアップロードする
AWS トラブルシューティングツールの詳細については、「[Support Automation Workflow (SAW) Runbook - Troubleshoot CloudWatch agent](https://repost.aws/articles/ARDFhNRgSMRcahrIbGJaIC4g/support-automation-workflow-saw-runbook-troubleshoot-amazon-cloudwatch-agent)」を参照してください。
**Topics**
+ [
## CloudWatch エージェントのコマンドラインパラメータ
](#CloudWatch-Agent-options-help)
+ [
## Run Command を使用した CloudWatch エージェントのインストールが失敗する
](#CloudWatch-Agent-installation-fails)
+ [
## CloudWatch エージェントが開始されない
](#CloudWatch-Agent-troubleshooting-cannot-start)
+ [
## CloudWatch エージェントが実行されていることを確認する
](#CloudWatch-Agent-troubleshooting-verify-running)
+ [
## CloudWatch エージェントが起動ぜず、Amazon EC2 リージョンに関するエラーが発生する
](#CloudWatch-Agent-troubleshooting-EC2-region)
+ [
## CloudWatch エージェントが Windows Server で開始されない
](#CloudWatch-Agent-troubleshooting-Windows-start)
+ [
## メトリクスの場所
](#CloudWatch-Agent-troubleshooting-no-metrics)
+ [
## CloudWatch エージェントが、コンテナで実行に長い時間がかかる、またはホップ制限のエラーをログに記録する
](#CloudWatch-Agent-container-slow)
+ [
## エージェントの設定を更新しましたが、CloudWatch コンソールに新しいメトリクスやログが表示されません
](#CloudWatch-Agent-troubleshooting-update-no-new-metrics)
+ [
## CloudWatch エージェントファイルとロケーション
](#CloudWatch-Agent-files-and-locations)
+ [
## CloudWatch エージェントのバージョンについての情報の検索
](#CloudWatch-Agent-troubleshooting-agent-version)
+ [
## CloudWatch エージェントによって生成されたログ
](#CloudWatch-Agent-troubleshooting-loginfo)
+ [
## CloudWatch エージェントの停止と再起動
](#CloudWatch-Agent-troubleshooting-stopping-restarting)
## CloudWatch エージェントのコマンドラインパラメータ
CloudWatch エージェントでサポートされているパラメータの完全なリストを表示するには、エージェントがインストールされているコンピュータで、コマンドラインに以下のコマンドを入力します。
```
amazon-cloudwatch-agent-ctl -help
```
## Run Command を使用した CloudWatch エージェントのインストールが失敗する
Systems Manager Run Command を使用して CloudWatch エージェントをインストールするには、ターゲットサーバー上の SSM Agent がバージョン 2.2.93.0 以降の SSM Agent エージェントである必要があります。SSM Agent のバージョンが適切でない場合は、次のエラーメッセージが表示されることがあります。
```
no latest version found for package AmazonCloudWatchAgent on platform linux
```
```
failed to download installation package reliably
```
SSM Agent バージョンの更新については、*AWS Systems Manager ユーザーガイド*の [SSM Agent のインストールと設定](https://docs.aws.amazon.com/systems-manager/latest/userguide/ssm-agent.html)を参照してください。
## CloudWatch エージェントが開始されない
CloudWatch エージェントが開始されない場合、設定に問題がある可能性があります。設定情報は、`configuration-validation.log` ファイルにログ記録されます。このファイルは、Linux サーバーでは `/opt/aws/amazon-cloudwatch-agent/logs/configuration-validation.log` に、Windows Server を実行しているサーバーでは `$Env:ProgramData\Amazon\AmazonCloudWatchAgent\Logs\configuration-validation.log` にあります。
## CloudWatch エージェントが実行されていることを確認する
CloudWatch エージェントのクエリを実行して、実行中か停止中かを調べることができます。これをリモートに行うには、AWS Systems Manager を使用できます。コマンドラインを使用することもできますが、チェックできるのはローカルサーバーだけです。
**Run Command を使用して CloudWatch エージェントのステータスをクエリするには**
1. Systems Manager コンソール ([https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)) を開きます。
1. ナビゲーションペインで、[**Run Command**] を選択します。
-または-
AWS Systems Manager のホームページが表示された場合は、スクロールダウンして [**Explore Run Command**] (Run Command の詳細) を選択します。
1. [**Run command (コマンドの実行)**] を選択します。
1. [**コマンドドキュメント**] リストで、[**AmazonCloudWatch-ManageAgent**] の横のボタンをクリックします。
1. [**Action**] リストで、[**status**] を選択します。
1. [**オプションの設定ソース**] で [**デフォルト**] を選択し、[**オプションの設定場所**] を空白のままにします。
1. [**Target**] 領域で、確認するインスタンスを選択します。
1. [**Run (実行)**] を選択します。
エージェントが実行されている場合、出力は次のようになります。
```
{
"status": "running",
"starttime": "2017-12-12T18:41:18",
"version": "1.73.4"
}
```
エージェントが停止した場合、`"status"` フィールドには `"stopped"` が表示されます。
**コマンドラインを使用して CloudWatch エージェントのステータスのクエリをローカルで実行するには**
+ Linux サーバーで、次のように入力します。
```
sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -m ec2 -a status
```
Windows Server を実行しているサーバーの場合、管理者として PowerShell で次のように入力します。
```
& $Env:ProgramFiles\Amazon\AmazonCloudWatchAgent\amazon-cloudwatch-agent-ctl.ps1 -m ec2 -a status
```
## CloudWatch エージェントが起動ぜず、Amazon EC2 リージョンに関するエラーが発生する
エージェントが起動せず、エラーメッセージに Amazon EC2 リージョンのエンドポイントが示されている場合は、Amazon EC2 エンドポイントへのアクセス権を必要とするエージェントを設定しただけで、そのアクセス権を付与していない可能性があります。
例えば、エージェントの設定ファイルで Amazon EC2 メタデータに依存する値を `append_dimensions` パラメータに指定し、プロキシー使用する場合は、そのサーバーが Amazon EC2 のエンドポイントにアクセスできることを確認する必要があります。これらのエンドポイントの詳細については、「Amazon Web Services 全般のリファレンス」の「[Amazon Elastic Compute Cloud (Amazon EC2)](https://docs.aws.amazon.com/general/latest/gr/rande.html#ec2_region)」を参照してください。
## CloudWatch エージェントが Windows Server で開始されない
Windows Server では、次のエラーが表示されることがあります。
```
Start-Service : Service 'Amazon CloudWatch Agent (AmazonCloudWatchAgent)' cannot be started due to the following
error: Cannot start service AmazonCloudWatchAgent on computer '.'.
At C:\Program Files\Amazon\AmazonCloudWatchAgent\amazon-cloudwatch-agent-ctl.ps1:113 char:12
+ $svc | Start-Service
+ ~~~~~~~~~~~~~
+ CategoryInfo : OpenError: (System.ServiceProcess.ServiceController:ServiceController) [Start-Service],
ServiceCommandException
+ FullyQualifiedErrorId : CouldNotStartService,Microsoft.PowerShell.Commands.StartServiceCommand
```
これを修正するには、まずサーバーサービスが実行中であることを確認します。このエラーは、サーバーサービスが実行されていないときにエージェントが起動しようとした場合に表示されます。
サーバーサービスがすでに実行されている場合は、以下の点が問題である可能性があります。一部の Windows Server インストールでは、CloudWatch エージェントの起動に 30 秒以上かかります。Windows Server では、サービスの起動に許容されるデフォルトの時間が 30 秒のみであるため、エージェントが失敗して次のようなエラーが表示される場合があります。
この問題を修正するには、サービスのタイムアウト値を増やします。詳細については、「[サービスが開始されず、イベント 7000 および 7011 が Windows イベントログに記録される](https://support.microsoft.com/en-us/help/922918/a-service-does-not-start-and-events-7000-and-7011-are-logged-in-window)」を参照してください。
## メトリクスの場所
CloudWatch エージェントが実行されているが、そのエージェントによって収集されたメトリクスが AWS マネジメントコンソール または AWS CLI で見つからない場合、適切な名前空間を使用していることを確認します。エージェントによって収集されるメトリクスの名前空間は、デフォルトでは `CWAgent` です。この名前空間は、エージェント設定ファイルの [`namespace`] セクションの [`metrics`] フィールドを使用してカスタマイズできます。予想されるメトリクスが表示されない場合、設定ファイルで、使用している名前空間を確認してください。
CloudWatch エージェントパッケージを初めてダウンロードした場合、エージェント設定ファイルは `amazon-cloudwatch-agent.json` です。このファイルは、設定ウィザードを実行したディレクトリにあります。または、別のディレクトリに自分で移動した可能性があります。設定ウィザードを使用した場合は、ウィザードからのエージェント設定ファイル出力の名前は `config.json` です。`namespace` フィールドなど、設定ファイルの詳細については、「[CloudWatch エージェント設定ファイル: Metrics セクション](CloudWatch-Agent-Configuration-File-Details.md#CloudWatch-Agent-Configuration-File-Metricssection)」を参照してください。
## CloudWatch エージェントが、コンテナで実行に長い時間がかかる、またはホップ制限のエラーをログに記録する
CloudWatch エージェントをコンテナサービスとして実行し、エージェントによって収集されたすべてのメトリクスに Amazon EC2 メトリクスのディメンションを追加する場合、エージェントのバージョン v1.247354.0 で次のエラーが表示されることがあります。
```
2022-06-07T03:36:11Z E! [processors.ec2tagger] ec2tagger: Unable to retrieve Instance Metadata Tags. This plugin must only be used on an EC2 instance.
2022-06-07T03:36:11Z E! [processors.ec2tagger] ec2tagger: Please increase hop limit to 2 by following this document https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-options.html#configuring-IMDS-existing-instances.
2022-06-07T03:36:11Z E! [telegraf] Error running agent: could not initialize processor ec2tagger: EC2MetadataRequestError: failed to get EC2 instance identity document
caused by: EC2MetadataError: failed to make EC2Metadata request
status code: 401, request id:
caused by:
```
このエラーは、エージェントが適切なホップ制限なしでコンテナ内の IMDSv2 からメタデータを取得しようとした場合に表示されることがあります。v1.247354.0 より前のバージョンのエージェントでは、ログメッセージが表示されることなくこの問題が発生する可能性があります。
これを解決するには、「[インスタンスメタデータオプションの設定](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/configuring-instance-metadata-options.html#configuring-IMDS-existing-instances.)」の指示に従い、ホップ制限を 2 に増やします。
## エージェントの設定を更新しましたが、CloudWatch コンソールに新しいメトリクスやログが表示されません
CloudWatch エージェント設定ファイルを更新した場合、次回にエージェントを起動したときに、**fetch-config** オプションを使用する必要があります。例えば、更新したファイルをローカルコンピュータに保存した場合は、次のコマンドを入力します。
```
sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -a fetch-config -s -m ec2 -c file:configuration-file-path
```
## CloudWatch エージェントファイルとロケーション
次の表は、Linux や Windows Server を実行しているサーバー上に CloudWatch エージェントによってインストールされて使用されるファイルおよびインストール先の一覧です。
| ファイル | Linux のロケーション | Windows Server のロケーション |
| --- | --- | --- |
| エージェントの起動、停止、再起動を制御する制御スクリプト。 | `/opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl` 、、または `/usr/bin/amazon-cloudwatch-agent-ctl` | `$Env:ProgramFiles\Amazon\AmazonCloudWatchAgent\amazon-cloudwatch-agent-ctl.ps1` |
| エージェントが書き込むログファイル。AWS サポート に問い合わせる際は、このファイルを添付する必要があります。 | `/opt/aws/amazon-cloudwatch-agent/logs/amazon-cloudwatch-agent.log` 、、または `/var/log/amazon/amazon-cloudwatch-agent/amazon-cloudwatch-agent.log` | `$Env:ProgramData\Amazon\AmazonCloudWatchAgent\Logs\amazon-cloudwatch-agent.log` |
| エージェント妥当性確認検証ファイル。 | `/opt/aws/amazon-cloudwatch-agent/logs/configuration-validation.log` 、、または `/var/log/amazon/amazon-cloudwatch-agent/configuration-validation.log` | `$Env:ProgramData\Amazon\AmazonCloudWatchAgent\Logs\configuration-validation.log` |
| ウィザードが作成した直後に、エージェントの設定に使用される JSON ファイル。詳細については、「[CloudWatch エージェント設定ファイルを作成する](create-cloudwatch-agent-configuration-file.md)」を参照してください。 | `/opt/aws/amazon-cloudwatch-agent/bin/config.json` | `$Env:ProgramFiles\Amazon\AmazonCloudWatchAgent\config.json` |
| この設定ファイルが Parameter Store からダウンロードした場合に、エージェントの設定に使用される JSON ファイル。 | `/opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.json` または `/etc/amazon/amazon-cloudwatch-agent/amazon-cloudwatch-agent.json` | `$Env:ProgramData\Amazon\AmazonCloudWatchAgent\amazon-cloudwatch-agent.json` |
| エージェントで使用するリージョン情報と認証情報を指定するための TOML ファイル (システムのデフォルト値を上書きします)。 | `/opt/aws/amazon-cloudwatch-agent/etc/common-config.toml`、または `/etc/amazon/amazon-cloudwatch-agent/common-config.toml` | `$Env:ProgramData\Amazon\AmazonCloudWatchAgent\common-config.toml` |
| JSON 設定ファイルの変換された内容を含む TOML ファイル。`amazon-cloudwatch-agent-ctl` スクリプトは、このファイルを生成します。このファイルは直接変更しないでください。JSON から TOML への変換が正常に完了したことを確認するのに役立ちます。 | `/opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.toml`、または `/etc/amazon/amazon-cloudwatch-agent/amazon-cloudwatch-agent.toml` | `$Env:ProgramData\Amazon\AmazonCloudWatchAgent\amazon-cloudwatch-agent.toml` |
| JSON 設定ファイルの変換された内容を含む YAML ファイル。`amazon-cloudwatch-agent-ctl` スクリプトは、このファイルを生成します。このファイルは直接変更しないでください。このファイルは、JSON から YAML への変換が正常に完了したことを確認するのに役立ちます。 | `/opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.yaml or /etc/amazon/amazon-cloudwatch-agent/amazon-cloudwatch-agent.yaml` | `$Env:ProgramData\Amazon\AmazonCloudWatchAgent\amazon-cloudwatch-agent.yaml` |
## CloudWatch エージェントのバージョンについての情報の検索
Linux サーバー上の CloudWatch エージェントのバージョン番号を検索するには、次のコマンドを入力します。
```
sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -a status
```
Windows Server 上の CloudWatch エージェントのバージョン番号を検索するには、次のコマンドを入力します。
```
& $Env:ProgramFiles\Amazon\AmazonCloudWatchAgent\amazon-cloudwatch-agent-ctl.ps1 -m ec2 -a status
```
**注記**
このコマンドを使用することは、CloudWatch エージェントのバージョンを検索する正しい方法です。コントロールパネルの [**Programs and Features (プログラムと機能)**] を使用すると、誤ったバージョン番号が表示されます。
エージェントに対する最新の変更に関する README ファイル、およびダウンロード可能なバージョン番号を示すファイルをダウンロードすることもできます。これらのファイルは次の場所にあります。
+ `https://amazoncloudwatch-agent.s3.amazonaws.com/info/latest/RELEASE_NOTES` 、、または `https://amazoncloudwatch-agent-us-east-1.s3.us-east-1.amazonaws.com/info/latest/RELEASE_NOTES`
+ `https://amazoncloudwatch-agent.s3.amazonaws.com/info/latest/CWAGENT_VERSION` 、、または `https://amazoncloudwatch-agent-us-east-1.s3.us-east-1.amazonaws.com/info/latest/CWAGENT_VERSION`
## CloudWatch エージェントによって生成されたログ
エージェントは、実行されている間ログを生成します。このログには、トラブルシューティング情報が含まれています。このログは、`amazon-cloudwatch-agent.log` ファイルで確認できます。このファイルは、Linux サーバーでは `/opt/aws/amazon-cloudwatch-agent/logs/amazon-cloudwatch-agent.log` に、Windows Server を実行しているサーバーでは `$Env:ProgramData\Amazon\AmazonCloudWatchAgent\Logs\amazon-cloudwatch-agent.log` にあります。
`amazon-cloudwatch-agent.log` ファイルに追加の詳細を記録するようにエージェントを設定できます。エージェント設定ファイルの `agent` セクションで、`debug` フィールドを `true` に設定した後、CloudWatch エージェントを再設定して再起動します。この追加情報のログ記録を無効にするには、`debug` フィールドを `false` に設定します。次に、エージェントを再設定して再起動します。(詳細については、[CloudWatch エージェント設定ファイルを手動で作成または編集する](CloudWatch-Agent-Configuration-File-Details.md) を参照してください)。
バージョン 1.247350.0 以降の CloudWatch エージェントでは、必要に応じて、エージェント設定ファイルの `agent` セクションの `aws_sdk_log_level` フィールドに、次のオプションの 1 つまたは複数を指定できます。複数のオプションは、`|` 文字で区切ります。
+ `LogDebug`
+ `LogDebugWithSigning`
+ `LogDebugWithHTTPBody`
+ `LogDebugRequestRetries`
+ `LogDebugWithEventStreamBody`
これらのオプションの詳細については、「[LogLevelType](https://docs.aws.amazon.com/sdk-for-go/api/aws/#LogLevelType)」を参照してください。
## CloudWatch エージェントの停止と再起動
AWS Systems Manager またはコマンドラインを使用して CloudWatch エージェントを手動で停止できます。
**Run Command を使用して CloudWatch エージェントを停止するには**
1. Systems Manager コンソール ([https://console.aws.amazon.com/systems-manager/](https://console.aws.amazon.com/systems-manager/)) を開きます。
1. ナビゲーションペインで、[**Run Command**] を選択します。
-または-
AWS Systems Manager のホームページが表示された場合は、スクロールダウンして [**Explore Run Command**] (Run Command の詳細) を選択します。
1. [**Run command (コマンドの実行)**] を選択します。
1. [**Command document**] リストで、[**AmazonCloudWatch-ManageAgent**] を選択します。
1. [**Targets**] 領域で、CloudWatch エージェントをインストールしたインスタンスを選択します。
1. [**Action**] リストで、[**stop**] を選択します。
1. [**Optional Configuration Source**] と [**Optional Configuration Location**] は空白のままにします。
1. [**Run (実行)**] を選択します。
**コマンドラインを使用して CloudWatch エージェントをローカルで停止するには**
+ Linux サーバーで、次のように入力します。
```
sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -m ec2 -a stop
```
Windows Server を実行しているサーバーの場合、管理者として PowerShell で次のように入力します。
```
& $Env:ProgramFiles\Amazon\AmazonCloudWatchAgent\amazon-cloudwatch-agent-ctl.ps1 -m ec2 -a stop
```
エージェントを再起動するには、「[(オプション) CloudWatch エージェントの一般的な設定と名前付きプロファイルを変更する](installing-cloudwatch-agent-ssm.md#CloudWatch-Agent-profile-instance-fleet)」の手順に従います。