Systems Managerを使ってLinuxのカスタムメトリクスを出力してみる

yujiota 2019年12月27日

どうも、クラウドエンジニアの大田です。
みなさんは年末年始、どのように過ごされる予定でしょうか。
私は毎年親族で集まっていたのですが、2019年に家族が2人増えたこともあり、
元日の集まりは自宅で開催することになりそうです。2020年はカニが食えるぞ。

さて、今回のテーマは「Systems Manager（通称: SSM）を使ってLinuxのカスタムメトリクスを出力してみる」です。
もちろんスクリプトを使っても、カスタムメトリクスの出力は実現出来るのですが、
複数のインスタンスに適用する際の運用・管理面を考慮したときに Systems Manager を使っておくと非常に楽です。

実は前回の記事でカスタムメトリクス出力を実施しておりますが、SSMエージェントのみを用いた少し古い方法でしたので、今回はCloudWatchエージェントも併用する最新の設定方法について、私の学習観点と検証を兼ねて実施していきます。

検証の概要
早速設定してみた
ハマったこと
注意事項
参考記事

1.検証の概要

今回はLinuxでカスタムメトリクスを設定してみました。
WindowsだとCloudWatchエージェントを使わずにSSMエージェントのみで実施できるのですが、
AWSとしてはCloudWatchエージェントの使用を推奨しているとのことなので、
これを機にノウハウを身に付けようと考えました。

現在のカスタムメトリクスの出力方法は主に3つです。

　a.スクリプトを書いて、cronで定期実行する
　b.SSMエージェント+CWエージェントの設定（Linux, Windows共通）
　c.SSMエージェントのみの設定（Windowsのみ）

今回は b の方法を検証していきます。
なお、前提条件は以下の通りです。

必要な権限ポリシーが割り当てられたIAMロールをEC2に割り当てていること
SSMエージェントがセットアップされていること
CloudWatchにデータが送信できること
- パブリックサブネットの場合：インターネットゲートウェイを使用する
- プライベートサブネットの場合：VPCエンドポイントまたはNATゲートウェイを使用する

※ 上記3点の詳細は前回の記事をご参照ください。
※ IAMロールのみ今回は追加のポリシーが必要ですので、ご注意ください。詳しくは後述しています。

CloudWatchエージェントがセットアップされていること
プロキシ使用の場合は別途エージェントのプロキシ使用設定が必要
（インスタンス単体のプロキシ設定のみでは、エージェントがエンドポイント通信できない）

※ なお、ログの送信は含まないカスタムメトリクスの設定（ディスク残のみ）を想定しています。今回は実際のお客様の要件で、プロキシ設定ありのパターンも検証する機会がありましたので、あわせて記載します。

2.早速設定してみた

それでは、設定していきましょう。
プロキシ設定なし/ありによって設定方法が異なる場合は、明記しています。
特に明記していない場合は、共通の設定方法とお考えください。

IAMロールを作成/EC2にアタッチ

下記のAWS管理ポリシーを適用する

AmazonEC2RoleforSSM
CloudWatchAgentAdminPolicy

※ 上記2つのポリシーはSSMエージェントおよびCloudWatchエージェントの利用に必要な権限です
※ EC2は起動済みとして割愛

EC2にIAMロールをアタッチ
アクション→インスタンスの設定→IAM ロールの割り当て/置換→作成したIAMロールを割り当て

EC2のSystems Managerマネージドインスタンス化

プロキシ設定なしの場合

特になし（次の手順に進む）
SSM エージェントがインストールされていれば、ロール割当後に起動中のまま即座にSSMエージェントを起動できる
または、ロールを割り当てた状態で OS再起動→SSMエージェントを自動起動させることによって、マネージドインスタンス化が可能

プロキシ設定ありの場合

※キャプチャ例はRHEL（Red Hat Enterprise Linux｜systemd）で設定を実施しています

SSH接続
SSMエージェントのプロキシ設定
https://docs.aws.amazon.com/ja_jp/systems-manager/latest/userguide/sysman-proxy-with-ssm-agent.html

SSMエージェントの再起動

AWS System Managerからマネージドインスタンスを確認

AWSマネジメントコンソール上に表示されていればマネージドインスタンス化成功

他の確認方法

セッションマネージャーからLinuxコマンド実行

Linuxコマンドがコンソール上からSSH接続なしで実行できる
（AWS SSMが強い権限をもっていることが分かる）

SSM Run Command の実行

マネージドインスタンス→アクション→コマンドの実行またはランコマンドを選択

コマンドドキュメント：
AWS-ConfigureAWSPackage を選択

コマンドのパラメータ：
Action：Install
Installation Type：Uninstall and reinstall
Name：AmazonCloudWatchAgent
Version：空欄でOK（デフォルトでlatest）

ターゲット：
タグや個別インスタンス、リソースグループ等からCloudWatchエージェントをインストールしたいインスタンスを選択

出力オプション：
S3バケット書き込み有効化のチェックを外しておく
※本来であれば、ランコマンドの詳細出力を確認するためにS3バケットにログを書き込むようにしておくと◎

ランコマンドの実行

ランコマンドからコマンドの成功を確認

無事コマンドの実行が成功しましたね！
もしここでエラーが出る場合は、SSMエージェントのバージョンやエラーログを確認すると原因特定がしやすくなります。
エラーログは下記ディレクトリに格納されていますので、ご参考まで。

%PROGRAMDATA%\Amazon\SSM\Logs\ 配下一式
%PROGRAMDATA%\Amazon\SSM\InstanceData\ 配下一式

次はCloudWatchエージェントの設定ファイルを作成していきます。
ここからが実際に出力させたいカスタムメトリクスに関する設定ですね。

CloudWatchエージェント設定ファイルの作成

プロキシ設定なしの場合

プロキシ設定ありの場合と同様に手動でCWエージェント設定ファイル ( /opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.json ) を作成するか、CWエージェント設定ウィザードを起動する

CWエージェント設定ウィザードの起動：

sudo /opt/aws/amazon-cloudwatch-agent/bin/amazon-cloudwatch-agent-config-wizard の実行
ウィザードに従って、各項目を設定する
項目の詳細については、以下のドキュメントにまとまっていますので、ご確認ください。
ウィザードを使用して CloudWatch エージェント設定ファイルを作成する
- 設定ファイルを汎用する場合は、SSMパラメータストアに設定ファイルを保存する
- 設定後に下記出力が確認できたらOK
  - Successfully put config to parameter store AmazonCloudWatch-linux.
    Program exits now.

エラーが出力されたら、エラー内容に応じてIAM権限周りやネットワーク設定、セキュリティグループなどを見直しましょう。こちらはプロキシの有無に関わらず、まず疑ってみる癖をつけておきましょう。

プロキシ設定ありの場合

上記と同様に、CWエージェント設定ウィザードでも実施可能ですが、
その場合はSSMパラメータストアに設定ファイルを保存しないようにする必要がある（理由は後述します）ため、
CWエージェント設定ウィザードを使用する場合は、下記キャプチャのようにウィザードを実行しておいてください。

上記の設定により「CWエージェント設定ファイルをローカルに作成する」ところまでを実行してくれます。
設定ファイルは /opt/aws/amazon-cloudwatch-agent/bin/config.json として確認できます。

今回はCWエージェント設定ウィザードを実行せず、ローカルに設定ファイルを作成する方法もご紹介します。

EC2インスタンスにSSH接続
CloudWatchエージェント（以下、CWエージェント）がプロキシを利用するように設定
- /opt/aws/amazon-cloudwatch-agent/etc/common-config.toml を編集
  # [proxy]
  # http_proxy = “{http_url}”
  # https_proxy = “{https_url}”
  # no_proxy = “{domain}”
  ※no_proxy = “169.254.169.254” の設定漏れに注意（インスタンスメタデータ取得用）

ローカル（EC2内部）にCWエージェント設定ファイルを作成・保存
便宜上 /opt/aws/amazon-cloudwatch-agent/etc/amazon-cloudwatch-agent.json とする

設定ファイルが作成できたら、次はCWエージェントを起動していきます。

CloudWatchエージェントの起動

プロキシ設定なしの場合

ランコマンドを選択
コマンドドキュメント：AmazonCloudWatch-ManageAgent

コマンドのパラメータ：
Action：Configure
Optional Configuration Source：ssm
Optional Configuration Location：パラメータストアに保存したエージェント設定ファイル名
Optional Restart：yes
他の項目はCWエージェントインストール時と同様

ランコマンド実行
ランコマンド成功

実行結果のキャプチャはCWエージェントインストール時と変わりませんので、割愛します。

CloudWatchからカスタムメトリクスを確認

JSONで指定したNameSpaceがメトリクス名になっていることを確認
メトリクス項目が正しく設定されていることを確認

なお、プロキシ設定なしの場合は、下記の方法でも同様にCWエージェントの起動が可能です。

プロキシ設定ありの場合

ローカルに作成したCWエージェント設定ファイル名に基づいて下記コマンドを実行。

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.json -s を実行

作成したカスタムメトリクスをCloudWatchで確認する

JSONで指定したNameSpaceがメトリクス名になっていることを確認
メトリクス項目が正しく設定されていることを確認

これで無事にカスタムメトリクスが出力されました！これにて検証完了です。

3.ハマったこと

実際のお客様で、EC2内でプロキシ設定をされているケースがありました。
この場合は冒頭でもお伝えした通り、SSMエージェントやCWエージェントにもプロキシを使用するように設定する必要があります。
プロキシ設定自体はそこまで手間取ることはなかったのですが、CWエージェント設定ウィザードからSSMパラメータストアに設定ファイルを保存しようとすると、SSMエンドポイントに対するリクエストエラーが出力される現象に悩まされました。

IAMの権限周りやネットワーク設定、セキュリティグループ等見直しても特に異常は見当たらない…
そこで問題切り分けのため、AWSサポートに問い合わせたところ、 2019/12/16 現在のCWエージェント設定ウィザードの通信はエージェントのプロキシ使用設定の有無に関わらず、エンドポイントに直接通信しようとする仕様になっているとの回答がありました。

つまり、EC2がプロキシを使用している場合は、CWエージェント設定ウィザードでSSMパラメータストアに設定ファイルを保存しないようにするか、手動でローカル（OS内部）にjsonファイルを保存して、OS内部からCWエージェント起動を実行する必要があったのです。そのため、今回の記事ではそちらの手順をご紹介しました。

これにはなかなか気付けませんでした・・・・・。
とはいえ、根本の前提を疑う大切さを学びました（ポジティブ）。

また、このような場合は、よほど要件の制約がない限りは VPCエンドポイントや NATゲートウェイを利用した方が良さそうです。

4.注意事項

まとめです。
既存環境に対して、カスタムメトリクスを出力させたい場合は以下を考慮する必要があります。

SSMエージェントおよびCloudWatchエージェントのセットアップの有無
IAMロールの権限の有無（SSMエージェントの利用、CWエージェントの利用）
インターネットアウトの有無（エージェントからエンドポイントへの通信）
プロキシ使用の有無（エージェントのプロキシ使用設定）
- プロキシ設定有りの場合はエージェントのプロキシ使用設定の漏れに注意
- また、2019/12/16現在のCWエージェント設定ウィザードの通信は、エージェントのプロキシ使用設定の有無に関わらず、エンドポイントに直接通信しようとする仕様になっているため、プロキシ使用の場合は、CWエージェント設定ウィザードでSSMパラメータストアに設定ファイルを保存しないようにするか、ローカル（OS内部）にjsonファイルを保存して、OS内部からCWエージェント起動を実行する必要がある（AWSサポートからの公式回答）

エラーにぶち当たっては対処しての繰り返しでしたが、基本的なカスタムメトリクスの設定に関しては理解できてきたように思います。
引き続き Systems Manager を使いこなして、運用・管理面のコストを削減していきたいですね。
以上、ご拝読ありがとうございました！

5.参考記事

全体
- AWS Systems Manager のセットアップ
- Systems Manager の前提条件
SSMエージェントのセットアップ
- Amazon EC2 Linux インスタンスに SSM エージェントを手動でインストールする
  ※プリインストールAMIの場合は不要（下記ドキュメントに記載）
- SSMエージェントの使用
- プロキシありの場合
  - プロキシを使用するように SSM エージェントを設定する
IAMロール設定
- Amazon EC2 の IAM ロール
CloudWatchエージェントのセットアップ
- エージェント設定を使用して EC2 インスタンスに CloudWatch エージェントをインストールする
- CloudWatch エージェント設定ファイルを手動で作成または編集する
- プロキシありの場合
  - (オプション) CloudWatch エージェントの一般的な設定と名前付きプロファイルを変更する
- パラメータストアに設定ファイルを保存してCWエージェントを起動する場合
  - コマンドラインを使用して Amazon EC2 インスタンスで CloudWatch エージェントを開始する
- パラメータストアに設定ファイルを保存せずにCWエージェントを起動する場合
  - サーバーで CloudWatch エージェントをインストールして実行する

株式会社ターン・アンド・フロンティア