Windows Server のパフォーマンスモニターの情報を CloudWatch に投げる [cloudpack OSAKA blog]
ナスです。
CloudWatch 便利ですね。勝手に CPU とかの情報を取ってきて閾値超えたらアラート上げてくれるので、ちょっとした監視ならこれで十分です。ただ、そんな便利な CloudWatch も万能ではありません。メモリの情報もデフォルトでは取れないので、ちょっと設定してあげる必要があります。
今回は CloudWatch にメモリ情報を投げる手順をご紹介します。メモリに限らず、パフォーマンスモニターで見れる情報ならなんでも CloudWatch に投げられるので、それなりに参考になると思います。
ただ、そのまんまやったらつまづくことがあるので、ハマったポイントを重点的に書いていきます。
ドキュメントはこれ
全体的な設定の流れはこのドキュメントの通りです。 docs.aws.amazon.com
選んだ方法
Systems Manager Run Command を使いました。選んだ理由は↓です。
- OS にログインしなくてもいい(設定は全部 AWS コンソールからできる)
- 複数のインスタンスに対して同時にできる
- 「CloudWatch のインスタンスを設定する」ページの一番上に書いてあったから(推奨なのかな?と勝手に思った)
ハマったポイント 1
IAM ロールを対象の EC2 インスタンスにつけるのですが、どんなポリシーにすればいいのかわかりづらかったです。結局 AmazonEC2RoleforSSM だけアタッチした IAM ロールを EC2 インスタンスにつけただけでよかったです。
ハマったポイント 2
AWS.EC2.Windows.CloudWatch.json をダウンロードして編集します。が、このドキュメントの通りにやっただけではうまくいきません。なぜかというと、対象の Windows Server インスタンスで取れない情報を取ろうとするからです。カスタムログとか。
なので、今回は CloudWatch に投げない項目の設定は全部削除しました。必要最低限の設定だけにした JSON が↓です。使用可能メモリ量とページング使用率だけ取る例です。今回は最小限にしましたが、このファイルにはデフォルトでイベントログや任意のログファイルのメッセージを CloudWatch Logs に投げる定義も書かれているので、対象のファイルのパス等を正しく定義してやればメッセージも投げられますよ。
{ "IsEnabled": true, "EngineConfiguration": { "PollInterval": "00:00:15", "Components": [ { "Id": "PerformanceCounterMemory", "FullName": "AWS.EC2.Windows.CloudWatch.PerformanceCounterComponent.PerformanceCounterInputComponent,AWS.EC2.Windows.CloudWatch", "Parameters": { "CategoryName": "Memory", "CounterName": "Available MBytes", "InstanceName": "", "MetricName": "Memory", "Unit": "Megabytes", "DimensionName": "InstanceId", "DimensionValue": "{instance_id}" } }, { "Id": "PerformanceCounterPaging", "FullName": "AWS.EC2.Windows.CloudWatch.PerformanceCounterComponent.PerformanceCounterInputComponent,AWS.EC2.Windows.CloudWatch", "Parameters": { "CategoryName": "Paging File", "CounterName": "% Usage", "InstanceName": "_Total", "MetricName": "Paging", "Unit": "Megabytes", "DimensionName": "InstanceId", "DimensionValue": "{instance_id}" } }, { "Id": "CloudWatchLogs", "FullName": "AWS.EC2.Windows.CloudWatch.CloudWatchLogsOutput,AWS.EC2.Windows.CloudWatch", "Parameters": { "AccessKey": "", "SecretKey": "", "Region": "us-east-1", "LogGroup": "Default-Log-Group", "LogStream": "{instance_id}" } }, { "Id": "CloudWatch", "FullName": "AWS.EC2.Windows.CloudWatch.CloudWatch.CloudWatchOutputComponent,AWS.EC2.Windows.CloudWatch", "Parameters": { "AccessKey": "", "SecretKey": "", "Region": "ap-northeast-1", "NameSpace": "nasu/test" } } ], "Flows": { "Flows": [ "(PerformanceCounterMemory,PerformanceCounterPaging),CloudWatch" ] } } }
結果
NameSpace で指定した名前空間が、CloudWatch メトリクスに出てきます。
中身を見てみると、ちゃんと JSON で定義した項目だけが出てきています。メモリ情報なので、グラフ自体は全く面白くないですね。
いろんな監視システムやサービスがありますが、自前でわざわざ準備&管理するのが面倒なら、こんな感じで CloudWatch を使ってみてはいかがでしょうか。
サブネットグループはグループです! [cloudpack OSAKA blog]
ナスです。
タイトルの通りなんですが、なぜ今まで気がつかなかったのか謎です…
RDS と DMS の初期設定で気がつきました
ドキュメントもよく読まずに、Single-AZ で RDS を構築して DMS で DB データ移行しようとしてました。サブネットグループを作ろうとして、AWS コンソールから 1 つのサブネットだけを選んで作成しようとするとこんなエラーがでました。
さらに DMS インスタンスを立てようとしてサブネットグループを作ろうとしてこうなりました。
やっぱりガイドには書いてありました
Single-AZ で RDS や DMS を使う場合でも、サブネットは 2 つ以上作る必要があるので、気をつけてください!
最初のヒアリングの時に聞けなかったらまたサブネットの調整が必要になるので、自分も相手も二度手間になりますよ!