設定: CloudWatch EC2 インスタンスとオンプレミスサーバー用のエージェント

多くの組織は、物理的なサーバーと仮想マシン (VM) の両方でワークロードを実行します。通常、これらのワークロードは、メトリクスのキャプチャと取り込みに関する固有のインストールおよび構成要件を持つ異なる OS 上で実行されます。

EC2 インスタンスを使用することを選択した場合、インスタンスと OS の設定を高いレベルで制御できます。ただし、この高いレベルの制御と責任では、より効率的な使用を実現するために、構成をモニタリングおよび調整する必要があります。ロギングとモニタリングの標準を確立し、ログとメトリクスのキャプチャと取り込みのための標準的なインストールと構成のアプローチを適用することで、運用効率を向上させることができます。

IT 投資を移行または拡張するOrganizationsAWSクラウドが活用できる CloudWatch 統合ロギングおよびモニタリングソリューションを実現します。 CloudWatch 料金は、取得するメトリクスとログに対して段階的に料金を支払うことを意味します。同様のを使用して、オンプレミスサーバーのログとメトリクスをキャプチャすることもできます。 CloudWatch Amazon EC2 のエージェントインストールプロセス。

CloudWatch のインストールとデプロイを開始する前に、システムとアプリケーションのロギングとメトリクス設定を必ず評価してください。使用する OS のキャプチャに必要な標準ログとメトリクスを定義していることを確認します。システムログとメトリクスは、OS によって生成され、Linux と Windows では異なるため、ロギングおよびモニタリングソリューションの基盤および標準です。Linux バージョンまたはディストリビューションに固有のメトリクスとログファイルに加えて、Linux ディストリビューション全体で利用できる重要なメトリクスとログファイルがあります。この差異は、異なる Windows バージョン間でも発生します。

設定: CloudWatch エージェント

CloudWatch は、各 OS に固有の CloudWatch エージェントとエージェント設定ファイル を使用して Amazon EC2 サーバーとオンプレミスサーバーのメトリクスとログをキャプチャします。インストールを開始する前に、組織の標準メトリクスとログキャプチャ設定を定義することをお勧めします。 CloudWatch アカウント内の大規模なエージェント。

複数を組み合わせることができます。 CloudWatch コンポジットを形成するためのエージェント構成 CloudWatch エージェント設定。推奨されるアプローチの 1 つは、システムレベルとアプリケーションレベルでログとメトリクスの構成を定義して分割することです。次の図は、異なる要件に対する複数の CloudWatch 設定ファイルタイプを組み合わせて、複合 CloudWatch 設定を形成する方法を示しています。

これらのログとメトリクスは、特定の環境や要件に合わせてさらに分類して構成することもできます。例えば、規制されていない開発環境では低い精度でログとメトリクスの小さなサブセットを定義し、規制された本番環境ではより精度の高い大規模で完全なセットを定義できます。

EC2 インスタンスのログキャプチャの設定

デフォルトでは、Amazon EC2 はログファイルをモニタリングまたはキャプチャしません。代わりに、ログファイルがキャプチャされ、に取り込まれます。 CloudWatch によるログ CloudWatch EC2 インスタンスにインストールされるエージェントソフトウェアAWSAPI、またはAWS Command Line Interface(AWS CLI). を使用することをお勧めします｡ CloudWatch ログファイルを取り込むエージェント CloudWatch Amazon EC2 およびオンプレミスサーバーのログ。

CloudWatch のログファイルからのパターンパッチ適用に基づいて、ログを検索してフィルタリングしたり、メトリクスを抽出したり、自動化を実行したりできます。 CloudWatch は、プレーンテキスト、スペース区切り、および JSON 形式のフィルタおよびパターン構文オプションをサポートし、JSON 形式のログが最も柔軟になります。フィルタリングと分析オプションを増やすには、プレーンテキストではなくフォーマットされたログ出力を使用する必要があります。

- CloudWatch エージェントは、CloudWatch に送信するログとメトリクスを定義する設定ファイルを使用します。 CloudWatch 次に、各ログファイルをログストリームこれらのログストリームをlog group。これにより、一致する文字列の検索など、EC2 インスタンスからのログ間でオペレーションを実行できます。

デフォルトのログストリーム名は EC2 インスタンス ID と同じで、デフォルトのロググループ名はログファイルのパスと同じです。ログストリームの名前は、 CloudWatch ロググループ。次を使用できます。instance_id,hostname,local_hostname, またはip_addressログストリームとロググループ名の動的置換の場合。つまり、同じものを使用できます。 CloudWatch 複数の EC2 インスタンスにわたるエージェント設定ファイル。

次の図は、 CloudWatch ログをキャプチャするためのエージェント設定。ロググループは、キャプチャされたログファイルによって定義され、EC2 インスタンスごとに個別のログストリームが含まれます。{instance_id} 変数はログストリーム名に使用され、EC2 インスタンス ID は一意です。

ロググループは、それらに含まれるログストリームの保存期間、タグ、セキュリティ、メトリクスフィルタ、および検索範囲を定義します。ログファイル名に基づくデフォルトのグループ化動作は、アカウントとリージョン内の EC2 インスタンス間でログファイルに固有のデータの検索、メトリクスの作成、およびアラームに役立ちます。ロググループの細分化が必要かどうかを評価する必要があります。例えば、アカウントが複数のビジネスユニットによって共有され、異なる技術所有者またはオペレーションの所有者がいる場合があります。つまり、分離と所有権を反映するように、ロググループ名をさらに絞り込む必要があります。このアプローチにより、関連する EC2 インスタンスに分析とトラブルシューティングを集中させることができます。

複数の環境で 1 つのアカウントを使用する場合は、各環境で実行されるワークロードのログ記録を分けることができます。次の表に、ビジネスユニット、プロジェクトまたはアプリケーション、および環境を含むロググループの命名規則を示します。

ロググループ名	/<Business unit>/<Project or application name>/<Environment>/<Log file name>
ログストリーム名	<EC2 instance ID>

EC2 インスタンスのすべてのログファイルを同じロググループにグループ化することもできます。これにより、単一の EC2 インスタンスについて一連のログファイルを検索および分析することが容易になります。これは、ほとんどの EC2 インスタンスが 1 つのアプリケーションまたはワークロードを処理し、各 EC2 インスタンスが特定の目的を果たす場合に便利です。次の表に、この方法をサポートするようにロググループとログストリームの名前をフォーマットする方法を示します。

ロググループ名	/<Business unit>/<Project or application name>/<Environment>/<EC2 instance ID>
ログストリーム名	<Log file name>

EC2 インスタンスのメトリクスキャプチャの設定

デフォルトでは、EC2 インスタンスで基本モニタリングが有効になり、標準メトリックセット(CPU、ネットワーク、ストレージ関連のメトリクスなど) は、自動的にに送信されます。 CloudWatch 5分ごとに。 CloudWatch メトリクスは、インスタンスファミリーによって異なる場合があります。バーストパフォーマンスインスタンスCPU クレジットのメトリックがあります。Amazon EC2 標準メトリクスは、インスタンス料金に含まれます。EC2 インスタンスで 詳細モニタリング を有効にすると、1 分間隔でデータを受信できます。期間の頻度が CloudWatch のコストに影響するため、EC2 インスタンスのすべてまたは一部のみに詳細モニタリングが必要かどうかを評価してください。例えば、実稼働ワークロードの詳細モニタリングを有効にし、非運用ワークロードには基本モニタリングを使用できます。

オンプレミスサーバーには、のデフォルトのメトリクスは含まれません。 CloudWatch を使用する必要があります｡ CloudWatch エージェント,AWS CLI, またはAWSメトリクスをキャプチャする SDK。つまり、キャプチャするメトリクス (CPU 使用率など) を CloudWatch 設定ファイル。一意を作成できます。 CloudWatch オンプレミスサーバーの標準 EC2 インスタンスメトリクスを含む設定ファイル。標準に加えて適用します。 CloudWatch の設定

のメトリクスに CloudWatch は、メトリクス名とゼロ以上のディメンションで一意に定義され、メトリクス名前空間に一意にグループ化されます。AWS サービスによって提供されるメトリクスには、AWS (例えば、AWS/EC2) で始まる名前空間があり、非 AWS メトリクスは、カスタムメトリクスと見なされます。で設定してキャプチャするメトリクス CloudWatch エージェントはすべてカスタムメトリクスと見なされます。作成された指標の数は、 CloudWatch コスト、各メトリクスがすべての EC2 インスタンスまたは一部にのみ必要かどうかを評価する必要があります。例えば、実稼働ワークロードのメトリクスの完全なセットを定義し、非運用ワークロードにはこれらのメトリクスの小さなサブセットを使用できます。

CWAgentは、が公開するメトリクスのデフォルトの名前空間空間です。 CloudWatch エージェント。ロググループと同様に、メトリクス名前空間は一連のメトリクスを整理して、それらを 1 か所でまとめて見つけることができます。ビジネスユニット、プロジェクト、アプリケーション、および環境 (例えば、/<Business unit>/<Project or application name>/<Environment>) を反映するように名前空間を変更する必要があります。このアプローチは、複数の無関係なワークロードが同じアカウントを使用する場合に便利です。また、名前空間の命名規則を CloudWatch ロググループの命名規則。

指標はディメンションによって識別され、一連の条件に対して分析するのに役立ち、観測値が記録されるプロパティです。Amazon EC2 には EC2 インスタンス用の 個別のメトリクス が InstanceId およびAutoScalingGroupName ディメンションで含まれます。また、詳細モニタリングを有効にする場合、ImageId および InstanceType ディメンションでメトリクスを受け取ります。例えば、Amazon EC2 は、InstanceId ディメンション用の別の CPU 使用率メトリクスに加えて、InstanceType ディメンション CPU 使用率に関する別個の EC2 インスタンスメトリクスを提供します。これにより、固有のインスタンスタイプ のすべての EC2 インスタンスに加えて、一意の EC2 インスタンスの CPU 使用率を分析できます。

ディメンションを追加すると、分析能力は向上しますが、全体的なコストも増加します。これは、各メトリクスと固有のディメンション値の組み合わせによって新しいメトリクスが作成されるためです。例えば、InstanceId ディメンションに対してメモリ使用率のメトリクスを作成した場合、これは各 EC2 インスタンスの新しいメトリクスです。組織が数千の EC2 インスタンスを実行している場合、これにより数千のメトリクスが発生し、コストが高くなります。コストを制御および予測するには、メトリクスのカーディナリティと、最も価値の高いディメンションを決定する必要があります。例えば、実稼働ワークロードメトリクスのディメンションの完全なセットを定義し、非本番ワークロードではこれらのディメンションの小さなサブセットを定義できます。

♪append_dimensionsプロパティを使用して、で定義された 1 つまたはすべてのメトリクスにディメンションを追加する CloudWatch の設定 また、動的に追加することもできます。ImageId,InstanceId,InstanceType, およびAutoScalingGroupName内のすべてのメトリクス CloudWatch の設定 または、特定のメトリクスに任意のディメンション名と値を追加することもできます。append_dimensionsそのメトリックのプロパティ。 CloudWatch は、で定義したメトリクスディメンションに関する統計を集計することもできます。aggregation_dimensionsプロパティ。

例えば、InstanceType ディメンションに使用されたメモリを集計できるので、インスタンスタイプごとにすべての EC2 インスタンスが使用している平均メモリを確認します。t2.micro リージョンで実行されているインスタンスを使用すると、t2.micro クラスを使用しているワークロードが提供されたメモリを過度に利用している、または過小利用しているかを判断できます。使用率の低下は、不要なメモリ容量を持つ EC2 クラスを使用するワークロードの兆候である可能性があります。対照的に、過剰使用率は、メモリ不足の Amazon EC2 クラスを使用するワークロードの兆候である可能性があります。

次の図表は、サンプルを示しています。 CloudWatch カスタム名前空間、追加されたディメンション、および集計を使用するメトリクス設定InstanceType。