翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# EC2 インスタンスとオンプレミスサーバー用の CloudWatch エージェントの設定
多くの組織は、物理的なサーバーと仮想マシン (VM) の両方でワークロードを実行します。通常、これらのワークロードは、メトリクスのキャプチャと取り込みに関する固有のインストールおよび構成要件を持つ異なる OS 上で実行されます。
EC2 インスタンスを使用することを選択した場合、インスタンスと OS の設定を高いレベルで制御できます。ただし、この高いレベルの制御と責任では、より効率的な使用を実現するために、構成をモニタリングおよび調整する必要があります。ロギングとモニタリングの標準を確立し、ログとメトリクスのキャプチャと取り込みのための標準的なインストールと構成のアプローチを適用することで、運用効率を向上させることができます。
IT 投資を AWS クラウドに移行または拡張する組織は、CloudWatch を活用して、統合されたログ記録とモニタリングソリューションを実現できます。CloudWatch 料金は、取得するメトリクスとログに対して段階的に料金を支払うことを意味します。Amazon EC2 の場合と同様の CloudWatch エージェントインストールプロセスを使用して、オンプレミスサーバーのログとメトリクスをキャプチャすることもできます。
CloudWatch のインストールとデプロイを開始する前に、システムとアプリケーションのロギングとメトリクス設定を必ず評価してください。使用する OS のキャプチャに必要な標準ログとメトリクスを定義していることを確認します。システムログとメトリクスは、OS によって生成され、Linux と Windows では異なるため、ロギングおよびモニタリングソリューションの基盤および標準です。Linux バージョンまたはディストリビューションに固有のメトリクスとログファイルに加えて、Linux ディストリビューション全体で利用できる重要なメトリクスとログファイルがあります。この差異は、異なる Windows バージョン間でも発生します。
## CloudWatch エージェントを設定します。
CloudWatch は、各 OS に固有の [CloudWatch エージェントとエージェント設定ファイル](https://docs.aws.amazon.com//AmazonCloudWatch/latest/monitoring/Install-CloudWatch-Agent.html) を使用して Amazon EC2 サーバーとオンプレミスサーバーのメトリクスとログをキャプチャします。CloudWatch エージェントをアカウントに大規模にインストールする前に、組織の標準メトリクスとログキャプチャ設定を定義することをお勧めします。
複数の CloudWatch エージェント設定を組み合わせて、複合 CloudWatch エージェント設定を構成できます。推奨されるアプローチの 1 つは、システムレベルとアプリケーションレベルでログとメトリクスの構成を定義して分割することです。次の図は、異なる要件に対する複数の CloudWatch 設定ファイルタイプを組み合わせて、複合 CloudWatch 設定を形成する方法を示しています。
![\[さまざまな要件の設定を組み合わせて、複合 CloudWatch 設定を形成します。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/implementing-logging-monitoring-cloudwatch/images/logging-monitoring-image-1.png)
これらのログとメトリクスは、特定の環境や要件に合わせてさらに分類して構成することもできます。例えば、規制されていない開発環境では低い精度でログとメトリクスの小さなサブセットを定義し、規制された本番環境ではより精度の高い大規模で完全なセットを定義できます。
## EC2 インスタンスのログキャプチャの設定
デフォルトでは、Amazon EC2 はログファイルをモニタリングまたはキャプチャしません。代わりに、EC2 インスタンス、 AWS API、または AWS Command Line Interface () にインストールされた CloudWatch エージェントソフトウェアによってログファイルがキャプチャされ、CloudWatch Logs に取り込まれますAWS CLI。CloudWatch エージェントを使用して、Amazon EC2 とオンプレミスサーバーの CloudWatch Logs にログファイルを取り込むことをお勧めします。
CloudWatch のログファイルからのパターンパッチ適用に基づいて、ログを検索してフィルタリングしたり、メトリクスを抽出したり、自動化を実行したりできます。CloudWatch は、プレーンテキスト、スペース区切り、および JSON 形式のフィルタおよびパターン構文オプションをサポートし、JSON 形式のログが最も柔軟になります。フィルタリングと分析オプションを増やすには、プレーンテキストではなくフォーマットされたログ出力を使用する必要があります。
CloudWatch エージェントは、CloudWatch に送信するログとメトリクスを定義する設定ファイルを使用します。CloudWatch は、各ログファイルを [ログストリーム](https://docs.aws.amazon.com//AmazonCloudWatch/latest/logs/Working-with-log-groups-and-streams.html) としてキャプチャし、これらのログストリームを [ロググループ](https://docs.aws.amazon.com//AmazonCloudWatch/latest/logs/Working-with-log-groups-and-streams.html) にグループ化します。これにより、一致する文字列の検索など、EC2 インスタンスからのログ間でオペレーションを実行できます。
デフォルトのログストリーム名は EC2 インスタンス ID と同じで、デフォルトのロググループ名はログファイルのパスと同じです。ログストリーム名は CloudWatch ロググループ内で一意である必要があります。ログストリームとロググループ名の動的置換の場合、`instance_id`、`hostname`、`local_hostname`、または `ip_address` を使用できます。つまり、複数の EC2 インスタンス間で同じ CloudWatch エージェント設定ファイルを使用できます。
次の図は、ログをキャプチャするための CloudWatch エージェント設定を示しています。ロググループは、キャプチャされたログファイルによって定義され、EC2 インスタンスごとに個別のログストリームが含まれます。`{instance_id}` 変数はログストリーム名に使用され、EC2 インスタンス ID は一意です。
![\[ログをキャプチャするための CloudWatch エージェント設定。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/implementing-logging-monitoring-cloudwatch/images/cloudwatch-image-1.png)
ロググループは、それらに含まれるログストリームの保存期間、タグ、セキュリティ、メトリクスフィルタ、および検索範囲を定義します。ログファイル名に基づくデフォルトのグループ化動作は、アカウントとリージョン内の EC2 インスタンス間でログファイルに固有のデータの検索、メトリクスの作成、およびアラームに役立ちます。ロググループの細分化が必要かどうかを評価する必要があります。例えば、アカウントが複数のビジネスユニットによって共有され、異なる技術所有者またはオペレーションの所有者がいる場合があります。つまり、分離と所有権を反映するように、ロググループ名をさらに絞り込む必要があります。このアプローチにより、関連する EC2 インスタンスに分析とトラブルシューティングを集中させることができます。
複数の環境で 1 つのアカウントを使用する場合は、各環境で実行されるワークロードのログ記録を分けることができます。次の表に、ビジネスユニット、プロジェクトまたはアプリケーション、および環境を含むロググループの命名規則を示します。
| | |
| --- |--- |
| ロググループ名 | //// |
| ログストリーム名 | |
EC2 インスタンスのすべてのログファイルを同じロググループにグループ化することもできます。これにより、単一の EC2 インスタンスについて一連のログファイルを検索および分析することが容易になります。これは、ほとんどの EC2 インスタンスが 1 つのアプリケーションまたはワークロードを処理し、各 EC2 インスタンスが特定の目的を果たす場合に便利です。次の表に、この方法をサポートするようにロググループとログストリームの名前をフォーマットする方法を示します。
| | |
| --- |--- |
| ロググループ名 | //// |
| ログストリーム名 | |
## EC2 インスタンスのメトリクスキャプチャの設定
デフォルトでは、EC2 インスタンスで基本モニタリングが有効になり、[標準メトリクスセット](https://docs.aws.amazon.com//AWSEC2/latest/UserGuide/viewing_metrics_with_cloudwatch.html) (CPU、ネットワーク、ストレージ関連のメトリクスなど) は、5 分ごとに自動的に CloudWatch に送信されます。CloudWatch メトリクスは、インスタンスファミリーによって異なる場合があります。例えば、[バーストパフォーマンスインスタンス](https://docs.aws.amazon.com//AWSEC2/latest/UserGuide/burstable-performance-instances.html) は CPU クレジットのメトリクスがあります。Amazon EC2 標準メトリクスは、インスタンス料金に含まれます。EC2 インスタンスで [詳細モニタリング](https://docs.aws.amazon.com//AWSEC2/latest/UserGuide/using-cloudwatch-new.html) を有効にすると、1 分間隔でデータを受信できます。期間の頻度が CloudWatch のコストに影響するため、EC2 インスタンスのすべてまたは一部のみに詳細モニタリングが必要かどうかを評価してください。例えば、実稼働ワークロードの詳細モニタリングを有効にし、非運用ワークロードには基本モニタリングを使用できます。
オンプレミスサーバーには CloudWatch のデフォルトのメトリクスが含まれていないため AWS CLI、CloudWatch エージェント、、または AWS SDK を使用してメトリクスをキャプチャする必要があります。つまり、CloudWatch 設定ファイルでキャプチャするメトリクス (CPU 使用率など) を定義する必要があります。オンプレミスサーバーの標準 EC2 インスタンスメトリクスを含む一意の CloudWatch 設定ファイルを作成し、標準の CloudWatch 設定に加えて適用できます。
CloudWatch の [メトリクス](https://docs.aws.amazon.com//AmazonCloudWatch/latest/monitoring/working_with_metrics.html) では、メトリクス名とゼロ以上のディメンションで一意に定義され、メトリクス名前空間に一意にグループ化されます。 AWS サービスによって提供されるメトリクスには、 で始まる名前空間 `AWS` ( など`AWS/EC2`) があり、非AWS メトリクスはカスタムメトリクスと見なされます。CloudWatch エージェントで設定してキャプチャするメトリクスは、すべてカスタムメトリクスと見なされます。作成されたメトリクスの数は CloudWatch のコストに影響を与えるため、各メトリクスがすべての EC2 インスタンスまたは一部にのみ必要かどうかを評価する必要があります。例えば、実稼働ワークロードのメトリクスの完全なセットを定義し、非運用ワークロードにはこれらのメトリクスの小さなサブセットを使用できます。
`CWAgent` は、CloudWatch エージェントによって公開されるメトリクスのデフォルトの名前空間です。ロググループと同様に、メトリクス名前空間は一連のメトリクスを整理して、それらを 1 か所でまとめて見つけることができます。ビジネスユニット、プロジェクト、アプリケーション、および環境 (例えば、`///`) を反映するように名前空間を変更する必要があります。このアプローチは、複数の無関係なワークロードが同じアカウントを使用する場合に便利です。また、名前空間の命名規則を CloudWatch ロググループの命名規則に関連付けることもできます。
指標はディメンションによって識別され、一連の条件に対して分析するのに役立ち、観測値が記録されるプロパティです。Amazon EC2 には EC2 インスタンス用の [個別のメトリクス](https://docs.aws.amazon.com//AWSEC2/latest/UserGuide/viewing_metrics_with_cloudwatch.html#ec2-cloudwatch-dimensions) が `InstanceId` および`AutoScalingGroupName` ディメンションで含まれます。また、詳細モニタリングを有効にする場合、`ImageId` および `InstanceType` ディメンションでメトリクスを受け取ります。例えば、Amazon EC2 は、`InstanceId` ディメンション用の別の CPU 使用率メトリクスに加えて、`InstanceType` ディメンション CPU 使用率に関する別個の EC2 インスタンスメトリクスを提供します。これにより、固有の[インスタンスタイプ](https://docs.aws.amazon.com//AWSEC2/latest/UserGuide/instance-types.html) のすべての EC2 インスタンスに加えて、一意の EC2 インスタンスの CPU 使用率を分析できます。
ディメンションを追加すると、分析能力は向上しますが、全体的なコストも増加します。これは、各メトリクスと固有のディメンション値の組み合わせによって新しいメトリクスが作成されるためです。例えば、`InstanceId` ディメンションに対してメモリ使用率のメトリクスを作成した場合、これは各 EC2 インスタンスの新しいメトリクスです。組織が数千の EC2 インスタンスを実行している場合、これにより数千のメトリクスが発生し、コストが高くなります。コストを制御および予測するには、メトリクスのカーディナリティと、最も価値の高いディメンションを決定する必要があります。例えば、実稼働ワークロードメトリクスのディメンションの完全なセットを定義し、非本番ワークロードではこれらのディメンションの小さなサブセットを定義できます。
CloudWatch 設定で定義された 1 つまたはすべてのメトリクスにディメンションを追加する `append_dimensions` プロパティを使用できます。また、`ImageId`、`InstanceId`、`InstanceType`、および `AutoScalingGroupName` を CloudWatch 設定のすべてのメトリクスに動的に追加することもできます。または、`append_dimensions` そのメトリクスのプロパティを使用することで、特定のメトリクスに任意のディメンション名と値を追加することもできます。。CloudWatch は、`aggregation_dimensions` プロパティで定義したメトリクスディメンションに関する統計を集計することもできます。
例えば、`InstanceType` ディメンションに使用されたメモリを集計できるので、インスタンスタイプごとにすべての EC2 インスタンスが使用している平均メモリを確認します。`t2.micro` リージョンで実行されているインスタンスを使用すると、`t2.micro` クラスを使用しているワークロードが提供されたメモリを過度に利用している、または過小利用しているかを判断できます。使用率の低下は、不要なメモリ容量を持つ EC2 クラスを使用するワークロードの兆候である可能性があります。対照的に、過剰使用率は、メモリ不足の Amazon EC2 クラスを使用するワークロードの兆候である可能性があります。
次の図は、`InstanceType` によってカスタム名前空間、追加されたディメンション、および集計を使用する CloudWatch メトリクス設定のサンプルを示しています。
![\[CloudWatch エージェントを使用した CloudWatch メトリクス設定の例。\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/implementing-logging-monitoring-cloudwatch/images/cloudwatch-image-2.png)
# CloudWatch システムレベルの設定
システムレベルのメトリクスとログは、モニタリングおよびロギングソリューションの中心的なコンポーネントであり、CloudWatch エージェントには Windows および Linux 用の特定の設定オプションがあります。
サポートする予定の各 OS の CloudWatch エージェント設定ファイルを定義するために、[CloudWatch 設定ファイルウィザード](https://docs.aws.amazon.com//AmazonCloudWatch/latest/monitoring/create-cloudwatch-agent-configuration-file-wizard.html) または構成ファイルスキーマを使用することをお勧めします。追加のワークロード固有の OS レベルのログとメトリクスを個別の CloudWatch 設定ファイルで定義し、標準設定に追加できます。これらの固有の設定ファイルは、EC2 インスタンスで取得できる S3 バケットに別々に保存する必要があります。この目的のための S3 バケットの設定の例については、本ガイドの「[CloudWatch 設定の管理](create-store-cloudwatch-configurations.md#store-cloudwatch-configuration-s3) 」セクションを参照してください。State Manager とディストリビューターを使用して、これらの構成を自動的に取得して適用できます。
## システムレベルのログの設定
システムレベルのログは、オンプレミスまたは AWS クラウドでの問題の診断とトラブルシューティングに不可欠です。ログキャプチャアプローチには、OS によって生成されたすべてのシステムログとセキュリティログを含める必要があります。OS が生成するログファイルは、OS のバージョンによって異なる場合があります。
CloudWatch エージェントは、イベントログ名を指定して Windows イベントログのモニタリングをサポートします。モニタリングする Windows イベントログ (例えば、`System`、`Application`、または`Security`) を選択できます。
Linux システムのシステム、アプリケーション、およびセキュリティログは、通常 `/var/log` ディレクトリに保存されます。次の表は、モニタリングする必要がある一般的なデフォルトログファイルを定義していますが、`/etc/rsyslog.conf` または `/etc/syslog.conf` ファイルを使用して、システムのログファイルの特定の設定を判別します。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/implementing-logging-monitoring-cloudwatch/system-level-cloudwatch-configuration.html)
組織には、モニタリングするログを生成する他のエージェントまたはシステムコンポーネントがある場合もあります。これらのエージェントまたはアプリケーションによって生成されるログファイルを評価して決定し、ファイルの場所を特定して構成に含める必要があります。例えば、Systems Manager と CloudWatch エージェントログを設定に含める必要があります。次の表に、Windows および Linux のこれらのエージェントログの場所を示します。
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/implementing-logging-monitoring-cloudwatch/system-level-cloudwatch-configuration.html)
CloudWatch は、ログファイルが CloudWatch エージェント設定で定義されていても見つからない場合、ログファイルを無視します。これは、ディストリビューションごとに個別の構成ではなく、Linux 用の単一のログ構成を維持する場合に便利です。また、エージェントまたはソフトウェアアプリケーションの実行が開始されるまでログファイルが存在しない場合にも役立ちます。
## システムレベルのメトリクスを設定する
メモリとディスク領域の使用率は、Amazon EC2 が提供する標準メトリクスには含まれません。これらのメトリクスを含めるには、EC2 インスタンスに CloudWatch エージェントをインストールして設定する必要があります。CloudWatch エージェント設定ウィザードは [事前定義されたメトリクス](https://docs.aws.amazon.com//AmazonCloudWatch/latest/monitoring/create-cloudwatch-agent-configuration-file-wizard.html#cloudwatch-agent-preset-metrics) で CloudWatch 設定を作成し、必要に応じて、メトリクスを追加または削除することができます。事前に定義されたメトリクスセットを確認して、必要な適切なレベルを決定してください。
エンドユーザーとワークロード所有者は、サーバーまたは EC2 インスタンスの特定の要件に基づいて、追加のシステムメトリクスを公開する必要があります。これらのメトリクス定義は、別の CloudWatch エージェント設定ファイルに保存、バージョン管理、維持され、再利用と自動化のために中央の場所 (Amazon S3 など) で共有される必要があります。
標準の Amazon EC2 メトリクスは、オンプレミスサーバーでは自動的にキャプチャされません。これらのメトリクスは、オンプレミスインスタンスで使用される CloudWatch エージェント設定ファイルに定義される必要があります。CPU 使用率などのメトリクスを使用して、オンプレミスインスタンス用に個別のメトリクス設定ファイルを作成し、これらのメトリクスを標準のメトリクス設定ファイルに追加できます。
# アプリケーションレベルの CloudWatch 設定
アプリケーションログとメトリクスは、実行中のアプリケーションによって生成され、アプリケーション固有です。組織で定期的に使用されるアプリケーションを適切にモニタリングするために必要なログとメトリクスを定義してください。例えば、組織が Web ベースのアプリケーション用の Microsoft インターネットインフォメーションサーバー (IIS) で標準化している場合があります。IIS の標準的なログとメトリクス CloudWatch 構成を作成して、組織全体で使用することもできます。アプリケーション固有の設定ファイルは、一元化された場所 (S3 バケットなど) に格納され、ワークロード所有者または自動取得によってアクセスされ、CloudWatch 設定ディレクトリにコピーされます。CloudWatch エージェントは、各 EC2 インスタンスまたはサーバーの設定ファイルディレクトリにある CloudWatch 設定ファイルをコンポジット CloudWatch 設定に自動的に結合します。その結果、組織の標準的なシステムレベルの設定と、関連するすべてのアプリケーションレベルの CloudWatch 設定を含む CloudWatch 設定が作成されます。
ワークロードの所有者は、すべての重要なアプリケーションおよびコンポーネントのログファイルとメトリクスを特定して構成する必要があります。
## アプリケーションレベルのログの設定
アプリケーションレベルのロギングは、アプリケーションが商用オフザシェルフ (COTS) またはカスタム開発アプリケーションのどちらであるかによって異なります。COTS アプリケーションとそのコンポーネントは、ログの詳細レベル、ログファイル形式、ログファイルの場所など、ログの構成と出力に関するいくつかのオプションを提供します。ただし、ほとんどの COTS またはサードパーティアプリケーションは、ロギング (例えば、アプリケーションのコードを更新して、構成できない追加のログステートメントまたは形式を含めるなど) を根本的に変更することを許可しません。少なくとも、警告およびエラーレベルの情報（できれば JSON 形式）をログに記録するには、COTS またはサードパーティアプリケーションのロギングオプションを設定する必要があります。
CloudWatch 設定にアプリケーションのログファイルを含めることで、カスタム開発したアプリケーションを CloudWatch Logs と統合できます。カスタムアプリケーションを使用すると、ログ出力形式をカスタマイズしたり、コンポーネント出力を個別のログファイルに分類したり、必要な詳細を追加したりできるため、ログの品質と制御が向上します。分析と処理が簡単になるように、ロギングライブラリと組織に必要なデータと書式を必ず確認して標準化してください。
CloudWatch Logs `[PutLogEvents](https://docs.aws.amazon.com//AmazonCloudWatchLogs/latest/APIReference/API_PutLogEvents.html)` API コールまたは AWS SDK を使用して CloudWatch ログストリームに書き込むこともできます。API または SDK は、分散した一連のコンポーネントおよびサーバーにわたる単一のログストリームへのロギングを調整するなど、カスタムロギング要件に使用できます。ただし、保守が最も簡単で広く適用可能なソリューションは、ログファイルに書き込むようにアプリケーションを設定し、CloudWatch エージェントを使用してログファイルを読み取り、CloudWatch にストリーミングすることです。
また、アプリケーションログファイルから測定するメトリクスの種類も考慮する必要があります。メトリクスフィルターを使用して、CloudWatch ロググループでこのデータを測定、グラフ化、アラームできます。例えば、メトリクスフィルターを使用して、ログで失敗したログイン試行を特定してカウントできます。
アプリケーションログファイルで [[CloudWatch の埋め込みメトリクス](https://docs.aws.amazon.com//AmazonCloudWatch/latest/monitoring/CloudWatch_Embedded_Metric_Format.html) 形式](https://docs.aws.amazon.com//AmazonCloudWatch/latest/monitoring/CloudWatch_Embedded_Metric_Format.html) を使用して、独自のアプリケーションメトリクスを作成することも可能です。
## アプリケーションレベルのメトリクスを設定する
カスタムメトリクスは、 AWS サービスによって CloudWatch に直接提供されず、CloudWatch メトリクスのカスタム名前空間で公開されるメトリクスです。すべてのアプリケーションメトリクスは、カスタム CloudWatch メトリクスと見なされます。アプリケーションメトリクスは、EC2 インスタンス、アプリケーションコンポーネント、API コール、またはビジネス関数に揃える場合があります。また、メトリクスで選択したディメンションの重要性とカーディナリティも考慮する必要があります。カーディナリティの高いディメンションは、多数のカスタムメトリクスを生成し、CloudWatch のコストを増加させる可能性があります。
CloudWatch は、以下を含む複数の方法でアプリケーションレベルのメトリクスをキャプチャするのに役立ちます。
+ [procstat プラグイン](https://docs.aws.amazon.com//AmazonCloudWatch/latest/monitoring/CloudWatch-Agent-procstat-process-metrics.html) からキャプチャする個々のプロセスを定義して、プロセスレベルのメトリクスを取得します。
+ アプリケーションは Windows パフォーマンスモニターにメトリクスを公開し、このメトリクスは CloudWatch の設定で定義されます。
+ メトリクスフィルターとパターンは CloudWatch 内のアプリケーションのログに適用されます。
+ アプリケーションは、CloudWatch 組み込みメトリクス形式を使用して CloudWatch ログに書き込みます。
+ アプリケーションは API または AWS SDK を介して CloudWatch にメトリクスを送信します。
+ アプリケーションは、CloudWatch エージェントが設定された [収集された](https://docs.aws.amazon.com//AmazonCloudWatch/latest/monitoring/CloudWatch-Agent-custom-metrics-collectd.html) または [statsD](https://docs.aws.amazon.com//AmazonCloudWatch/latest/monitoring/CloudWatch-Agent-custom-metrics-statsd.html) デーモンにメトリクスを送信します。
procstat を使用して、CloudWatch エージェントで重要なアプリケーションプロセスをモニタリングおよび測定できます。これにより、アプリケーションで重要なプロセスが実行されなくなった場合に、アラームを発生させ、アクション (通知や再起動プロセスなど) を実行するのに役立ちます。また、アプリケーションプロセスのパフォーマンス特性を測定し、特定のプロセスが異常動作している場合にアラームを発生させることもできます。
Procstat モニタリングは、追加のカスタムメトリクスを使用して COTS アプリケーションを更新できない場合にも役立ちます。例えば、`my_process` を測定しカスタム `cpu_time` ディメンションを含む `application_version` メトリクスを作成できます。メトリクスごとに異なるディメンションがある場合は、アプリケーションに対して複数の CloudWatch エージェント設定ファイルを使用することもできます。
アプリケーションが Windows で実行されている場合は、すでに Windows パフォーマンスモニターにメトリクスを公開しているかどうかを評価する必要があります。多くの COTS アプリケーションは Windows パフォーマンスモニタと統合されているため、アプリケーションのメトリクスを簡単にモニタリングできます。CloudWatch は Windows パフォーマンスモニターとも統合され、すでに利用可能なメトリクスをキャプチャできます。
アプリケーションによって提供されるロギング形式とログ情報を確認して、メトリクス・フィルタを使用して抽出できるメトリクスを判別してください。アプリケーションの履歴ログを確認して、エラーメッセージと異常シャットダウンがどのように表示されるかを判断できます。また、以前に報告された問題を確認して、問題が繰り返し発生しないようにメトリクスを取得できるかどうかを判断する必要があります。また、アプリケーションのドキュメントを確認し、アプリケーション開発者にエラーメッセージの識別方法を確認するよう依頼する必要があります。
カスタム開発アプリケーションの場合は、アプリケーションの開発者と協力して、CloudWatch 埋め込みメトリクス形式、 AWS SDK、または AWS API を使用して実装できる重要なメトリクスを定義します。推奨されるアプローチは、埋め込みメトリクスフォーマットを使用することです。必要な形式でステートメントを記述するのに役立つように、 AWS 提供されたオープンソースの組み込みメトリクス形式のライブラリを使用できます。また、[アプリケーション固有の CloudWatch 設定](https://docs.aws.amazon.com//AmazonCloudWatch/latest/monitoring/CloudWatch_Embedded_Metric_Format_Generation_CloudWatch_Agent.html) を更新して、埋め込みメトリクスフォーマットエージェントを含める必要があります。これにより、EC2 インスタンスで実行されているエージェントは、組み込みメトリクス形式のメトリクスを CloudWatch に送信するローカル埋め込みメトリクス形式のエンドポイントとして機能します。
アプリケーションが collectd または statsd へのメトリクスの公開をすでにサポートしている場合は、それらを活用して CloudWatch にメトリクスを取り込むことができます。