AWS

RDSやElastiCache(Redis)の死活監視をCloudWatchで管理

AWS の監視系サービスである CloudWatch には、残念ながら RDS(MySQL)や ElastiCache(Redis)の死活監視に直結する項目(メトリクス)が用意されていません。

これがあれば、CloudWatch からアラート通知の設定ができて便利だったのですが、この時点で死活監視自体は自作する方向で考えなければいけません。

今回は独自のスクリプトで死活管理をして、その結果を CloudWatch に通知したいと思います。

死活監視について

死活監視については、これまでもシェルスクリプトで定期的に確認し、問題があればメールでアラート通知を行ってきました。

具体的には、EC2 から MySQL クライアントや Redis のクライアントで、それぞれ MySQL サーバや Redis サーバへの接続や認証を試みるものです。

これ自体は特に問題がないのですが、チェックプログラム自体が機能しているのかの確認を兼ねるとなると、正常時にもメール通知をするか、チェックスクリプトのログを確認するくらいしかパッと思いつきません。

もちろん、メールじゃなくて Slack などのチャットサービスに連携してもいいのですが、まずは関係者全員が可視化できるという部分を考えると、CloudWatch のダッシュボードで見れるのが良さそうです。

そこで、早速、CloudWatch のカスタムメトリクスを使って、チェックの結果を通知するようにしてみました。

AWS のサービスに依存しすぎるのもあまり好きではないのですが、餅は餅屋ということで監視系はなるべく一か所にまとめておきたいものです。

CloudWatchの標準のメトリクスでは監視項目が足りない

CloudWatch では、EC2 の CPU 使用率や RDS の各リソースなど、チェックしておきたい項目がいくつか標準で用意されています。

しかし、EC2 でいうと「メモリ使用率」や「ディスク使用率」は用意されていないので、別途、自分で作成して EC2 から CloudWatch へ通知しなければいけません。

一応、それを可能にする perl スクリプトは提供してくれているのですが、それをインストールして cron に定期実行される処理を定義しないと監視ができません。

それと同様に、EC2 のインスタンスの死活監視は標準で対応できるのですが、冒頭で説明した通り、RDS や ElastiCache(Redis)の死活監視は用意されていません。

それぞれ、CPU 使用率などのリソース項目はあるのですが、サービスが生きているかどうか、それを判断するメトリクスは用意されていないのです。

CloudWatchのカスタムメトリクスの作成

そこで、カスタムメトリクスを作成して、そこに RDS や ElastiCache(Redis) が生きているか死んでいるかの結果を送ってあげることにします。

CloudWatch のカスタムメトリクスに対して、値を送信する方法はいくつかありますが、CloudWatch への通知権限を持った IAM ユーザが既にあるのならそれを利用するのが早いです。

もちろん、厳密に権限を管理するのであれば、CloudWatch の通知用に別途 IAM ユーザを作成してもいいと思います。

ここでは、aws コマンド実行時に credentials に定義されているプロファイルを指定するようにします。

以前、「AWSのEC2にgoofysを入れてS3をマウントする」の設定をまとめた時に、S3 向けの権限を持ったユーザを aws configure でプロファイル指定せずに作成していました。

AWSのEC2にgoofysを入れてS3をマウントする過去に携わったプロジェクトで、S3FS の通信状態が悪い時があるので、アプリ側のプログラムを AWS SDK を使ったものに置き換えてい...

今回は、プロファイル指定して CloudWatch 用のユーザを作成します。

プロファイルを作成しておけば、aws コマンドを呼び出すときに使用するプロファイルを指定することができます。

以下に簡易的な通知のシェルスクリプトを書いてみます。実際には、mysql の接続にパスワードは直接書かず、auth ファイルを作成し、–defaults-extra-file で指定して呼び出すなどしてください。

Redis の場合は以下のコマンドで判定ができます。