Lambda と EventBridge を使って WEB サイトの状態を CloudWatch に送信
前置き
AWS で運用するサイトで Zabbix を使って Web 監視をしているシステムがあった。(Zabbix サーバは専用のインスタンスを起動していた) しかし、AWS にも CloudWatch という監視サービスがあり、ほぼ Zabbix を見ることがなかった。
CloudWatch を使えば、AWS コンソールから状況を確認できるので、できるなら、監視は CloudWatch に一本化するほうが楽なように私には思えた。後々、自分以外の人に渡す時、Zabbix の運用まで引き継ぐのは大変なように思える。(Zabbix サーバを外部に持っていて、エージェントをインストールするだけなら簡単かもしれないが。)
CloudWatch で監視したかったのだが、WEB サイトの死活監視 は CloudWatch 単体でできなさそうに思えた。 結局、WEB サイトを監視するサーバを一台置き、cron を使って python スクリプトで定期的に URL にアクセスして、結果を CloudWatch に送信した。CloudWatch への送信は、CloudWatch Agent を起動する時、StatsD を有効にしておいて、StatsD のポートに適当に作ったメトリックを投げる形だ。
しかし、この方法だと、EC2 インスタンスを常時起動しておかなければならず、微々たるものではあるが、その分の料金が発生するし、そのサーバ自身のメンテナンスも必要だ。OS にも EOL があったりして、そんなに長くないので、2〜3年するとバージョンアップが必要になる。とにかく、メンテナンスを最小にしたい。
仕事の合間に試行錯誤しつつ、数年が過ぎてしまった（笑）
直近のプロジェクトで EventBridge から AWS Batch を起動させる、という構成で作ってみたこともあり、EventBridge から、コンテナか Lambda 関数を実行させれば、上記の悩みが解消されるのでは？と思い、試作してみた。
ソース
何故 golang で書いたのかというと、次のような理由だ。
- お客さんの案件に golang を使うことがあるので慣れておこうと思った
- golang だとコンパイルすると一つのバイナリになるので、インストールが簡単そう
- python のように実行時にエラーが出るのはつらい
要は Lambda 関数として登録して、EventBridge から定期的に呼び出す、というものだ。
ECS を使ってコンテナを実行するも試してみたが、実行完了まで一分ほどかかる。実行環境を用意する必要があるからだろうか？
それに対して、Lambda だと100ms 程度で実行完了していたように思う。
このあたりが、Lambda の長所だろうか。 いつからか Lambda 関数にコンテナを使うこともできるようになったが、今回は試していない。
まとめ
- EventBridge からcron / rate 式などで Lambda 関数を呼び出す
- Lambda 関数で WEB サイトをチェックして、結果を CloudWatch に送信する
