前置き
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 に送信する