Mackerel で Amazon RDS for MySQL を監視する

監視サービス

#Mackerel

#監視サービス

#Amazon RDS

#MySQL

#AWS

ttaka

2019.10.01

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちわオペレーション部 ttaka です。今回は Mackerel の Amazon RDS for MySQL の監視の設定について書いてみます。

想定する読者

Mackerel のアカウントを取得している人
Mackerel で Amazon RDS for MySQL を監視したい人

実際の設定

構成図

動作環境

OS: Amazon Linux release 2 (Karoo)
Apache: 2.4.39-1
MySQL: 5.7.23
PHP: 7.2.21-1
WordPress: 5.2.3

やること

AWS インテグレーションを用いて Amazon RDS for MySQL をホストとして管理する
公式プラグインを用いて MySQL カスタムメトリックを収集する
公式チェックプラグインを用いて MySQL 監視を行う

1. AWS インテグレーションを用いて Amazon RDS for MySQL をホストとして管理する

まずはヘルプページ AWSインテグレーションを参考に公式で推薦されている IAM ロールで設定を進めます。なお、今回は RDS のみなのでロールに付与するポリシーは AmazonRDSReadOnlyAccess だけで OK です。

設定があっていれば Hosts 画面に対象の RDS ホストが登録されており、AWSインテグレーション - RDS に記載のメトリックが収集できているはずです。

2. 公式プラグインを用いて MySQL カスタムメトリックを収集する

上記 1. の設定を行うことで DB インスタンスが実行されている OS のメトリックが収集できます。

さらにミドルウェアのメトリック（今回でいうと MySQL）を収集したい場合は公式プラグインを使うことで収集ができるようになります。ただし、その場合は監視の踏み台サーバが必要になります。今回は Web サーバを監視踏み台サーバとして使用します。

実際の環境であればサービスに組み込まれていない監視踏み台サーバを個別に作成するのをおすすめします。サービスに組み込まれたサーバを監視踏み台とすると、監視踏み台が高負荷になってしまった場合に監視が継続できないのが１つと、監視台数が多くなってくると監視の負荷があがってくるためです。

2-1. 監視用の MySQL ユーザおよび DB スキーマ作成

RDS 作成時のユーザでもメトリック収集は可能ですが MySQL 内での権限が強すぎるため、メトリック収集用に空の DB スキーマとユーザを作成します。

MySQL 接続

$ mysql -u -p -h mackrel-test-rds-master.xxxxxxxxxxxx.rds.amazonaws.com

空の DB スキーマ作成

MySQL [(none)]> CREATE DATABASE mackerel_check_db;

ユーザ作成

MySQL [(none)]> CREATE USER 'check_user'@'%' IDENTIFIED BY ;

必要な権限付与

MySQL [(none)]> GRANT PROCESS,REPLICATION CLIENT ON *.* TO 'check_user'@'%';

権限確認

MySQL [(none)]> SHOW GRANTS FOR 'check_user'@'%';
+--------------------------------------------------------------+
| Grants for check_user@% |
+--------------------------------------------------------------+
| GRANT PROCESS, REPLICATION CLIENT ON *.* TO 'check_user'@'%' |
+--------------------------------------------------------------+
1 row in set (0.00 sec)

2-2. MySQL のメトリック収集設定追加

公式プラグイン集をインストールする

$ yum install mackerel-agent-plugins

mackerel-agent の設定ファイル編集
custom_identifier を設定することでカスタムメトリックが RDS の物として集約されます

### バックアップ作成
$ cp -aiv /etc/mackerel-agent/mackerel-agent.conf{,.$(date "+%Y%m%d")}

### 編集
$ vim /etc/mackerel-agent/mackerel-agent.conf
・・・
[plugin.metrics.mysql]
command = "mackerel-plugin-mysql -host='mackrel-test-rds-master.***********.ap-northeast-1.rds.amazonaws.com' -username='check_user' -password="
custom_identifier = "mackrel-test-rds-master.***********.ap-northeast-1.rds.amazonaws.com"

mackerel-agent の再起動実施

$ systemctl restart mackerel-agent.service

2-3. MySQL カスタムメトリック確認

対象の RDS に AWSインテグレーション - RDS 記載のメトリックが収集できているはずです。

3. 公式チェックプラグインを用いて MySQL 監視を行う

上記 2. の設定を行うことで MySQL のメトリックが収集できました。ただし、この段階で RDS に障害が発生し停止した場合でもアラート通知は発報されませんでした。

なぜかというと AWS インテグレーションで登録したホストには当然 Mackerel エージェントはインストールされていないため、 connectivity （ホスト死活）監視は設定できません。そのため、チェック監視を個別に入れてあげる必要があります。

3-1. MySQL のチェック監視設定追加

公式プラグイン集をインストールする

$ yum install mackerel-check-plugins

mackerel-agent の設定ファイル編集
custom_identifier を設定することでカスタムメトリックが RDS の物として集約されます

### バックアップ作成
$ cp -aiv /etc/mackerel-agent/mackerel-agent.conf{,.$(date "+%Y%m%d")}

### 編集
$ vim /etc/mackerel-agent/mackerel-agent.conf
・・・
[plugin.checks.mysql_connection]
command = ['check-mysql', 'connection', '--host', 'mackrel-test-rds-master.***********.ap-northeast-1.rds.amazonaws.com', '--user', 'check_user', '--password', '<>your_password', , '--warning', '5', '--critical', '10']
custom_identifier = "mackrel-test-rds-master.***********.ap-northeast-1.rds.amazonaws.com"
max_check_attempts = 3

mackerel-agent の再起動実施

$ systemctl restart mackerel-agent.service

3-2. MySQL チェック監視確認

対象の RDS のホスト詳細画面の末尾に監視項目が追加されているはずです。なお、今回は公式 MySQL チェック監視の connection サブコマンドを使用して監視を行いました。

念の為、RDS を停止して無事アラート通知が行われることを確認しました。 ※本番環境ではダメゼッタイ

なお max_check_attempts を 3 回、 WARNING 5 秒、 CRITICAL 10 秒の条件で RDS 再起動を行いましたが、この場合はアラート通知は行われませんでした。サーバ上で監視コマンドを断続的に実行すると一時的に MySQL Connection UNKNOWN が返ってきていましたが即時復旧をしていました。もし、RDS 再起動も検知したい場合は connection ではなく uptime サブコマンドで実現できるのではと思います。

最後に

最初 RDS を停止した際にアラート通知が行われず設定に間違いがあるのか悩んでしまいました。 Mackerel エージェントをインストールした場合は connectivity 監視が自動的に設定されていましたが、AWS インテグレーションで登録した場合は当然 Mackerel エージェントがインストールされていないため、自分でケアしてあげる必要があったのが学びでした。

最後にこの記事がだれかのお役に立てば幸いです。