LoginSignup
0

More than 3 years have passed since last update.

posted at

updated at

RadioSondeによるCloudWatchアラーム管理

(編集中)

本記事はOPENLOGI AdventCalendar 9日目の記事です。

もう1年経ってしまったのか・・・
去年に引き続きAWS関連の記事です。久しぶりに「こいつはCoolだぜ!」と感じたRadioSondeというツールを紹介しようと思います。

CloudWatchのアラーム設定は大変

RadioSondeを使い始めたきっかけはCloudWatch Agentというエージェントソフトを導入したことにより監視できる項目数が一気に増えたことです。
CloudWatchの様々なメトリクスはアラームが設定でき、監視している数値が閾値を下回るなどの条件でAWS SNSを使った通知などができます。
しかし監視項目が多くなってきてサーバー台数も増えてくると、この通知設定作業というのが思いの外、苦痛になっていました。
現在でも100近いアラームが必要になっており、それらを一件一件AWS Management Consoleで手動で追加する気にはとてもなりませんでした。

こうなると適当なスクリプトからawscliで機械的に生成しようかなと思うわけですが、世間的にはどうやるものなのか気になって調べてみました。
するとクラスメソッドさん、サーバーワークスさんあたりの記事でRadioZondeというツールが良いらしいという情報を得たので評価してみることにしました。
https://dev.classmethod.jp/cloud/aws/use-radiosonde-configure-cloudwatch-alarm/
http://blog.serverworks.co.jp/tech/2016/10/25/cloudwatch-radiosonde-benri/

DSLによるアラーム設定管理

RadioSondeは簡単に言えばDSLで設定を管理し、現在の設定のexport/importができるツールです。DSLについては今更だとは思いますが要は定義ファイルのことで、それを書いてそれを食わせれば大量の設定を一気に反映させれるというものです。
RadioSondeとは気温や気圧などの観測気球のことですが、何故この名前を採用したのかは分かりませんでした。
RadioSondeはCodenize.toolsというAWS管理ツール群の一つとして作られており、命名にはあまり規則性は感じないのでフィーリングかなと思います。

設定を定義ファイルで管理できるということは、設定変更の履歴をGitなどで管理でき差分もコミット前にレビューしやすくなるといったメリットが生まれます。
まずはRadioSondeに現在のCloudWatch AlarmをエクスポートさせてDLSとして出力させてみます。

bundleでインストールしているとエクスポートはこんな感じ。 -e がエクスポートで -o が出力ファイル名です。

$ bundle exec radiosonde -e -o ./oplenlogi.dls

するとなんか怒られました。

[ERROR] Invalid region ap-northeast-1 specified. Only us-east-1 is supported.

~/.aws/credentials などは設定してありますが ~/.aws/config のリージョン設定は読んでくれていないような・・・

$ export AWS_REGION="ap-northeast-1"
$ bundle exec radiosonde -e -o ./oplenlogi.dls

とするとエラーは出なくなりました。

出力されるDLSは実際のものは載せられないので公式のサンプルを貼りますが、こういう感じです。

alarm "alarm1" do
  namespace "AWS/EC2"
  metric_name "CPUUtilization"
  dimensions "InstanceId"=>"i-XXXXXXXX"
  period 300
  statistic :average
  threshold ">=", 50.0
  evaluation_periods 1
  actions_enabled true
  alarm_actions []
  ok_actions []
  insufficient_data_actions ["arn:aws:sns:us-east-1:123456789012:my_topic"]
end

そんなに解説するところも無いんですが、閾値を超えるなどの条件で通知するなSNS ARNは insufficient_data_actions ではなく alarm_actions に書かないといけませんね。 insufficient_data_actions はデータ不足を通知するものですね。

DLSを編集すると、適用する前にdry-runをすることができます。
例えばアラームのタイトルを日本語から英語表記に変更する場合はこのような結果になります。
-f が入力するDLSファイルで -a はapplyですね。

$ bundle exec radiosonde -f ./openlogi.dls -a --dry-run
Apply `./openlogi.dls` to CloudWatch (dry-run)
+ Create Alarm: DB1-ReplicaLag (dry-run)
+ Create Alarm: DB2-ReplicaLag (dry-run)
- Delete Alarm: DB1レプリケーション遅延 (dry-run)
- Delete Alarm: DB2レプリケーション遅延 (dry-run)
No change

差分をdiffっぽく色分け表示してくれるのが分かりやすいです。この出力は作業ログとしても有用でコピペして記録しておくだけでも後で見る人にとって何を変えたか理解しやすくなります。

RadioSondeで編集する場合は、変更についても一旦削除されてから作り直されます。
この例ではタイトルしか変わってないですが、パラメーターの変更についても詳しい差分を表示してくれます。

課題

RadioSondeのおかげでサーバー1台分のアラームを設定してエクスポートしてコピペでサーバー台数分のアラームを量産できるようにはなりましたが、これだけではオートスケールによるスケールアウトなどには追随できませんし手動でスケールアウトさせてもアラームの追加を忘れることは有りえます。
EC2はまだ何とでもできる気はしますが、RDSやらElastiCacheやらはどうするのがベストかまだイメージはついていません。
メンテナンスウィンドウだけアラームを無効化するとかもLambdaとRadioSondeでいい感じにできるかもしれませんね。

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
What you can do with signing up
0