CloudWatchエージェント（以下、CWエージェント）を導入してみたら簡単にできた、という記事です。
AWSドキュメントに明記されていませんが、一応、AWSの技術サポートに聞いてもこの方式は否定されませんでした。
当初はLambda関数でSSMドキュメント「AWS-ConfigureCloudWatch」を定期実行すればいい、という考えでした。ただ、Lambda関数でWorkSpaces環境のカスタムメトリクス取得はできた一方で、不規則にデータをロストしたり、取得できないメトリクスがあったり、動作がいまいちな結果に。。
CWエージェント方式であれば、PULL型ではなくPUSH型でデータを自動収集できるため、スケールする際の考慮をマネージドサービス(CloudWatch)に任せられるの点もメリットです。
以下のような流れを踏むと、CloudWatchカスタムメトリクスとして、WorkSpaces環境のOSリソース情報を自動取得できるようになります。
＋SSMアクティベーション ＋CWエージェントインストール ＋CWエージェント設定 ＋CWエージェント起動
AWSサービス構成
AWSサービス観点では、次の点がtipsになります。 必要な内容は基本的に全てAWSドキュメントに記載されている通りです。 ドキュメントとしてまとまっていないだけで、必要な部分をピックアップして設定していくことになります。
・WorkSpaces環境をオンプレWindows Server環境とみなす →EC2以外でSSMやCWエージェントを使用する場合はこの方式を使えば何とかなりそう。 ・CWエージェント起動時のモードでは「ec2」を指定する必要がある →IAM認証情報を読み取れないエラーを回避するため。。 ・SSMアクティベーション時に関連付けるIAMロールはWorkSpaces環境でも認識されるが、IAMアクセスキーをOS環境変数に設定する必要がある →1時間でIAM認証情報が失効し、CWエージェントが1時間しか情報収集できないため。。。
SSMアクティベーション
ハイブリッド環境での AWS Systems Manager の設定
の通り、SSMアクティベーション（IDとコード）を作成します。
フォローアップとしては、SSMアクティベーションと関連付けるIAMロールがAWSコンソールから作成できない点です。（IAMロール作成時の信頼関係にSSMがでてこない）
そのため、本記事で検証した際は、SSMを信頼関係とするIAMロールをAWS CLIから作成してます。まあ、できない旨は書いてないのですが、そこはAWSドキュメントに同じです。
SSMアクティベーションの作成自体は、AWSコンソールからも可能です。
IDとコードがバナーのように表示されますが、それを非表示にすると二度と確認できない点も要注意です。
アクティベーション作成後、AWSドキュメント記載のPowerShellコマンドを実行すると、SSMエージェントをインストールできます。
##SSMアクティベーション情報 $code = "activation-code" $id = "activation-id" ##リージョン $region = "region" $dir = $env:TEMP + "\ssm" New-Item -ItemType directory -Path $dir -Force cd $dir ##SSMエージェントインストール (New-Object System.Net.WebClient).DownloadFile("https://amazon-ssm-$region.s3.amazonaws.com/latest/windows_amd64/AmazonSSMAgentSetup.exe", $dir + "\AmazonSSMAgentSetup.exe") ##SSMエージェント起動 Start-Process .\AmazonSSMAgentSetup.exe -ArgumentList @("/q", "/log", "install.log", "CODE=$code", "ID=$id", "REGION=$region") -Wait ##SSMマネージドインスタンス確認 Get-Content ($env:ProgramData + "\Amazon\SSM\InstanceData\registration") Get-Service -Name "AmazonSSMAgent"
SSMのマネージドインスタンスとしてWorkSpacesが登録できると、CWエージェント導入の準備完了です。
CWエージェントインストール
オンプレミスサーバーに CloudWatch エージェントをインストールする
の通り、SSMドキュメント「AWS-ConfigureAWSPackage」を実行するとCWエージェントがインストールできます。
インストールされると、サービス一覧にも表示されます。
CWエージェント設定
CloudWatch エージェント設定ファイルを作成するの通り、CWエージェントを設定します。
初めてCWエージェントを導入する際は、AWSが用意したセットアップウィザードを使えば設定ファイルを生成してくれます。
ウィザードの中身はやや長いため（ログでは約200行）ご紹介を割愛しますが、CUIベースで初めてでも分かりやすくなっています。
ウィザードの最後には、SSMパラメータストアに設定値(JSONファイル)を保存できます。使わない手はないので、事前にSSM権限のIAMアクセスキーをご用意ください。
########## ## 前略 ## Please check the above content of the config. The config file is also located at config.json. Edit it manually if needed. Do you want to store the config in the SSM parameter store? 1. yes 2. no default choice: [1]: What parameter store name do you want to use to store your config? (Use 'AmazonCloudWatch-' prefix if you use our managed AWS policy) default choice: [AmazonCloudWatch-windows] Which region do you want to store the config in the parameter store? default choice: [us-east-1] ap-northeast-1 Please provide credentials to upload the json config file to parameter store. AWS Access Key: -------------------- AWS Secret Key: --------------------------------------- Successfully put config to parameter store AmazonCloudWatch-windows. Please press Enter to exit... Program exits now. C:\Program Files\Amazon\AmazonCloudWatchAgent>
CWエージェント起動
CloudWatch エージェントを開始する の通り、とは実はいかないですが、SSMドキュメント「AmazonCloudWatch-ManageAgent」を実行してCWエージェントを開始します。
SSMアクティベーション時にWorkSpaces環境をオンプレ相当にみなしてうまく行ったため、ここでも[Mode]を[onPremis]に指定しましたが、IAM権限のエラーが出て起動できません。。
回避策としては次の2点。
・「AmazonCloudWatch-ManageAgent」実行時のmodeはec2を指定する
→IAM認証情報を読み込もうとする挙動（フォルダパス？）が違うらしいです。
・WorkSpacesにIAM認証のOS環境変数を設定する
→"AWS_REGION"、"AWS_SECRET_ACCESS_KEY"、"AWS_ACCESS_KEY_ID"の3つです。
→権限としては「CloudWatchAgentServerPolicy」と「AmazonEC2RoleforSSM」のAWS管理ポリシーでOKです。
CWエージェントの起動が成功すると、SSMドキュメントの実行結果は以下のようなログでした。
Region: ap-northeast-1 credsConfig: map[] Successfully fetched the config and saved in C:\ProgramData\Amazon\AmazonCloudWatchAgent\Configs\ssm_AmazonCloudWatch-windows-workspaces.tmp Start configuration validation... Valid Json input schema. No csm configuration found. Configuration validation first phase succeeded Configuration validation second phase succeeded Configuration validation succeeded
CWエージェント設定のポーリング間隔にもよりますが、デフォルト設定(60s)であれば、時間をおかずにCloudWatchにWorkSpacesのOSリソース情報が収集され始めます。
▼メモリ使用率
▼CPU使用率やディスク使用率、NWやストレージのI/Oなど
なお、CWエージェントが収集するメトリクス群は、仕様として定義されています。 下記ページご参照。 CloudWatch エージェントの事前定義されたメトリクスセット
最後に
CWエージェント起動後にリッスンポートを確認してみたら、通信プロトコルはUDPでした。
CWエージェントはStatsDで動いているらしいので、そのUDPモードでCloudWatchにメトリクスデータを送信しているようです。
StatsD
A network daemon that runs on the Node.js platform and listens for statistics, like counters and timers, sent over UDP or TCP and sends aggregates to one or more pluggable backend services (e.g., Graphite).
「VDI環境のOSリソース情報をみる必要あるのか」という元々のジレンマはありますが、やはり必要に迫られるケースは存在します。そのような際でも、ランニングコストを最低限に抑えて実現できるのは、AWSマネージドサービスです。 AWSのサービス仕様として理屈上は問題ないはずなので、そのうちドキュメントに正式取り込みされることを願ってます。
