AWS Organizationで実現するCloudWatchメトリクスの一元管理①
はじめに
Septeni Japan株式会社でインフラエンジニアを担当している金と申します。
過去の記事で紹介したように、当社ではAWS Control TowerとOrganizationなどを組み合わせて40以上のアカウントを管理しています。
本記事はこの構成を前提としているので、詳細は過去の記事をご参照ください。
記事の構成
AWS CloudWatch のクロスアカウントオブザーバビリティを利用して、AWS Organization内の複数アカウントからメトリクスを集約し、中央で一元管理する方法を紹介します。
この記事では、第1部として、AWS Systems Managerを利用して、アカウント内のEC2インスタンスに対し、収集したいメトリクスの設定を一括で適用する方法について説明します。
メトリクス一元管理のメリット
メトリクスを一元管理することで、複数のAWSアカウントのリソースを一箇所で統合的にモニタリングし、組織全体のパフォーマンスやセキュリティリスクをリアルタイムで把握できるようになります。これにより、異常やセキュリティインシデントへの迅速な対応が可能になり、また、リソースの管理や監視業務の効率が向上します。
導入手順
STEP 1. EC2インスタンスをマネージドノードにします
AWS Systems ManagerでEC2インスタンスを制御するためには、以下の手順に従ってEC2インスタンスをマネージドノードにする必要があります。
- SSM Agentの設置
- EC2インスタンスにSSM Agentをインストールします。
- Amazon Linuxを含む多くの最新AMIにはすでにSSM Agentが設置されています。
- 過去のAMIを使用中の方は公式ドキュメントを参考に設置
- EC2インスタンスにロールをアタッチ
- 以下のポリシーを含むロールを作成し、EC2インスタンスに適用してください。
- AmazonSSMManagedInstanceCore: このポリシーを適用することで、EC2インスタンスがマネージドノードとなり、Systems Managerからのリモート接続やパッチ管理が可能になります。
- CloudWatchAgentServerPolicy: このポリシーにより、CloudWatch Agentが収集したメトリクスをCloudWatchに転送する権限が付与されます。
- 以下のポリシーを含むロールを作成し、EC2インスタンスに適用してください。
- Outbound経路の確保
- 以下のいずれかの方法で、SSM APIと通信するためのOutbound通信経路を確保する。
- Internet経由
- NATゲートウェイまたはインターネットゲートウェイを介して、パブリックサブネットからインターネットへのアウトバウンド通信を確保
- SSMエンドポイント経由
- VPCエンドポイントを使用して、SSM APIとプライベートネットワーク内で直接通信する方法を確保。
- インターネットを経由せずに、AWS内部ネットワークを通じて安全な通信を実現
- VPCの「エンドポイント」メニューから、EC2が配置されているサブネットに対して以下の3つのエンドポイントを作成する
- com.amazonaws.ap-northeast-1.ssm
- com.amazonaws.ap-northeast-1.ec2messages
- com.amazonaws.ap-northeast-1.ssmmessages
- Systems Managerのコンソールからマネージドノードを確認
STEP 2. System Manager Run CommandでCloudWatch Agentをインストールします
- AWS Systems Manager > Run Commandを実行します。
- コマンドドキュメントを検索し、「AWS-ConfigureAWSPackage」を選択します。
- コマンドのパラメータ設定
- Action: Install
- Name: AmazonCloudWatchAgent(大文字小文字を正確に記載してください)
- Version: latest
- ターゲットの選択
- CloudWatch Agentをインストールするマネージドインスタンスを選択します。
- タグやリソースグループを指定して対象を絞り込むことも可能です。
- その他のオプション設定
- レート制御: 複数のインスタンスに同時に実行する際のレートを設定します。
- 出力オプション: コマンドの実行結果をS3に保存する設定を行います。
- SNS通知: コマンドの実行結果をSNSで通知する設定を行います。
- AWS CLIコマンド: CLIでも同様の操作を実行できるように、コンソールの操作に対応するCLIコマンドが提供されます
- 実行と結果の確認
- 「実行」をクリックし、実行結果を確認します。
STEP 3. System Manager Parameter Storeを利用して、収集するメトリクスの設定情報を保存します。
- AWS Systems Manager > パラメータ作成を選択します。
- パラメータの詳細
- 名前を設定: パラメータに適切な名前を設定します。
- 値を設定: EC2インスタンスに適用されるメトリクス収集の設定値を入力します。
- 値の例:この例は、CloudWatch Agentが提供するアドバンス設定を示しています。
{
"agent": {
"metrics_collection_interval": 60, // メトリクス収集間隔を60秒に設定
"run_as_user": "root" // エージェントをrootユーザーとして実行
},
"metrics": {
"aggregation_dimensions": [
[
"InstanceId" // メトリクスをインスタンスIDで集計
]
],
"append_dimensions": {
"AutoScalingGroupName": "${aws:AutoScalingGroupName}", // オートスケーリンググループ名を追加
"ImageId": "${aws:ImageId}", // イメージIDを追加
"InstanceId": "${aws:InstanceId}", // インスタンスIDを追加
"InstanceType": "${aws:InstanceType}" // インスタンスタイプを追加
},
"metrics_collected": {
"collectd": {
"metrics_aggregation_interval": 60 // collectdのメトリクス収集間隔を60秒に設定
},
"cpu": {
"measurement": [
"cpu_usage_idle", // CPUのアイドル時間
"cpu_usage_iowait", // CPUのI/O待ち時間
"cpu_usage_user", // ユーザーのCPU使用率
"cpu_usage_system" // システムのCPU使用率
],
"metrics_collection_interval": 60, // CPUメトリクスの収集間隔を60秒に設定
"resources": [
"*" // すべてのリソースに適用
],
"totalcpu": false // 全体のCPU使用率は収集しない
},
"disk": {
"measurement": [
"used_percent", // ディスク使用率
"inodes_free" // 空きインデックスノード数
],
"metrics_collection_interval": 60, // ディスクメトリクスの収集間隔を60秒に設定
"resources": [
"*" // すべてのリソースに適用
]
},
"diskio": {
"measurement": [
"io_time", // I/O時間
"write_bytes", // 書き込みバイト数
"read_bytes", // 読み込みバイト数
"writes", // 書き込み操作数
"reads" // 読み込み操作数
],
"metrics_collection_interval": 60, // ディスクI/Oメトリクスの収集間隔を60秒に設定
"resources": [
"*" // すべてのリソースに適用
]
},
"mem": {
"measurement": [
"mem_used_percent" // メモリ使用率
],
"metrics_collection_interval": 60 // メモリメトリクスの収集間隔を60秒に設定
},
"netstat": {
"measurement": [
"tcp_established", // 確立されたTCP接続数
"tcp_time_wait" // TIME_WAIT状態のTCP接続数
],
"metrics_collection_interval": 60 // ネットワーク統計メトリクスの収集間隔を60秒に設定
},
"statsd": {
"metrics_aggregation_interval": 60, // statsdメトリクスの集計間隔を60秒に設定
"metrics_collection_interval": 60, // statsdメトリクスの収集間隔を60秒に設定
"service_address": ":8125" // statsdのサービスアドレスを設定
},
"swap": {
"measurement": [
"swap_used_percent" // スワップ使用率
],
"metrics_collection_interval": 60 // スワップメトリクスの収集間隔を60秒に設定
}
}
}
}
- 入力を完了した後、「パラメータを作成」を選択します。
STEP 4. System Manager Run CommandでCloudWatch Agentの設定ファイルを一括適用します
STEP 3で設定したパラメータストアを使用して、対象のEC2インスタンスにCloudWatch Agentのメトリクス収集設定を一括適用します。
- AWS Systems Manager > Run Commandを実行します。
- コマンドドキュメントから「AWS-RunShellScript」を検索し、選択します。
- 実行するコマンドを入力します。
- 実行コマンド
#!/bin/bash
# CloudWatch Agentを停止
sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -a stop
# Parameter Storeの保存されている設定ファイルを参照
# 注意: 3のステップで設定したパラメータ名と一致していることを確認
config=$(aws ssm get-parameter --name "AmazonCloudWatch-Parameter" --query "Parameter.Value" --output text)
if [ -z "$config" ]; then
echo "Failed to fetch the configuration from Parameter Store"
exit 1
fi
# 設定ファイルをEC2インスタンスの保存
echo "$config" > /opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.d/amazon-cloudwatch-agent.json
if [ ! -f /opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.d/amazon-cloudwatch-agent.json ]; then
echo "Failed to create the configuration file"
exit 1
fi
# Collectdをインストールして、CloudWatch Agentで必要なファイルが利用可能になるようにする
sudo yum install -y collectd
# CloudWatch Agent設定適用
sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -a fetch-config -m ec2 -c file:/opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.d/amazon-cloudwatch-agent.json
# CloudWatch Agent開始
sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-ctl -a start
- ターゲットの選択
- CloudWatch Agent設定ファイルを適用するEC2インスタンスを選択してください。
- タグやリソースグループを指定することも可能です。
- その他のオプション
- レート制御: 複数のインスタンスに対して同時に実行する際のレートを設定します。
- 出力オプション: コマンドの実行結果をS3に保存する設定を行います。
- SNS通知: コマンドの実行結果を通知するためのSNS設定を行います。
- AWS CLIコマンド: CLIでも同様の操作を実行できるように、コンソールの操作に対応するCLIコマンドが提供されます
- 実行と結果の確認
- 「実行」をクリックすると、実行結果を確認できます。
STEP 5. メトリクスの確認
- しばらくすると、EC2コンソール上で、デフォルトのメトリクスに加えて、CloudWatch Agentが収集したメトリクスも確認できるようになります。
- また、CloudWatchコンソールのメトリクスセクションからも、CloudWatch Agentが収集したメトリクスを確認できます。
さいごに
これにより、メトリクスの設定を一元的に管理できるようになり、組織全体で一貫したモニタリングと効果的な運用を実現するための準備が整いました。
次回は、クロスアカウントオブザーバビリティを活用して、複数アカウントのメトリクスを中央で集約・管理する方法について解説します。
Discussion