New Relic MySQL PluginでAmazon RDS for MySQLの性能を監視

ひとつ前の記事で、CactiプラグインによるAmazon RDSの性能監視について書きましたが、ここではNew Relicプラグインによる性能監視についてまとめます。

New Relicについて
New Relic MySQL Pluginについて
New Relic MySQL Pluginのインストール
New Relic MySQL Pluginのグラフ表示項目
まとめ

New Relicについて

New Relicは、SaaS型の性能監視サービスです。

少し古いですが、このブログでもNew Relicを紹介しました。

・性能監視サービスNew Relicについて
https://inaba-serverdesign.jp/blog/20130912/newrelic.html

New Relicは、サーバーにエージェントをインストールすることで自動的に監視データをNew Relicのサーバーに収集するので、簡単な設定で性能監視情報を可視化することができます。
Datadogや、はてなのMackerelと同様のサービスです。

New Relic MySQL Pluginについて

New Relic MySQL Pluginは、DBサーバーに接続してSHOW STATUS, SHOW INNODB STATUS等のコマンドを発行してMySQLシステム情報を収集してNew Relic上にグラフ表示します。
Percona MySQL Monitoring Template for Cactiと同様のツールで、グラフ化する監視項目はこちらのほうが少ないですが、グラフはきれいで見やすいです。
監視データの保存期間（＝参照期間）は、フリープランでは24時間、AWSパートナー向けフリープランでは72時間です。

なお、New Relic MySQL Pluginは、閾値を設定してそれを超えるとアラート通知するような機能はありません。

New Relic MySQL Pluginのインストール

監視対象のRDS for MySQLにアクセス可能なEC2インスタンスに、New Relic MySQL Pluginをインストールします。
New Relic MySQL Pluginのインストール手順は、以下の記事がとても詳しく参考になります。

・New RelicでMySQLを詳細に監視する
https://qiita.com/kou/items/0370dde20b74f23709c1

この手順どおりでインストールできるはずですが、いくつか補足します。

New Relicのアカウント作成

AWSを利用している場合のNew Relicアカウント作成は、New Relicのトップページ
https://newrelic.com/

ではなく、以下のAWSパートナー向けページからSign Upすると、フリープランでも監視データの保存期間が72時間となるのでお得です。
https://newrelic.com/partner/aws

ただし、（たぶん）Sing Up時に登録したアドレスに届くメールから「Verify」しないと、監視データの保存期間が通常の24時間となってしまいます。

※「AWS利用」の判断をどのように行っているかは、僕の知る限り非公表なので、よくわかりません。

New Relic Platform Installer(npi)のインストール先指定

参考サイトの手順で、npiのインストール先については、
「デフォルトでは$HOMEにインストールされますが、PREFIXを指定することで任意のディレクトリにインストールすることができます。」
とありますが、具体的には、環境変数としてPREFIXをセットすればよいです。

例えば、/usr/local/newrelic-npi にインストールするのであれば、次のようにします。

　$ export PREFIX=/usr/local/newrelic-npi
　$ LICENSE_KEY=<YOUR_KEY_HERE> bash -c "$(curl -sSL https://download.newrelic.com/npi/release/install-npi-linux-redhat-x64.sh)"

設定ファイルplugin.json

New Relic MySQL Pluginの対話型インストール中に設定するplugin.jsonでは、hostとして、監視対象DBの接続先（＝Amazon RDSであれば、RDS Endpoint）を指定します。

また、metricsはデフォルトで、statusとnewrelicが登録されていますが、innodb_statusを追加すると、History List LengthとInnoDB Checkpoint Ageのグラフが表示されるようになるのでおすすめです。

「innodb_mutexを追記するとプラグインのメモリ使用量が増える」とのことで、僕は追記したことはありません。
mutexの情報が必要なときのみ追記するとよいと思います。

（参考）
・newrelic_mysql_java_plugin/CATEGORIES.TXT
https://github.com/newrelic-platform/newrelic_mysql_java_plugin/blob/master/CATEGORIES.TX

{
  "agents": [
    {
      "name"    : "<監視画面上の表示名>",  // 監視画面上の表示名
      "host"    : "<RDS Endpoint>",   // 監視対象のサーバ名
      "metrics" : "status,newrelic,innodb_status",  // 監視対象メトリクス
      "user"    : "USER_NAME_HERE",   // 監視用のデータベース接続ユーザ名
      "passwd"  : "USER_PASSWD_HERE"  // 監視用ユーザのパスワード
    }
  ]
}

デーモン化

New Relic MySQL Pluginの対話型インストールの最後で、

Do you want to set this plugin as a background process? (y/n):

で、「y（プラグインをバックグラウンドプロセスとして設定する）」とすると、起動スクリプトが /etc/init.d/newrelic_plugin_com.newrelic.plugins.mysql.instance として設置されます。

　$ ls -l /etc/init.d/newrelic_plugin_com.newrelic.plugins
.mysql.instance
-rwxr-xr-x 1 root root 1942 Apr 15  2016 /etc/init.d/newrelic_plugin_com.newrelic.plugins.mysql.instance

また、自動起動設定も行われます。

　$ chkconfig --list newrelic_plugin_com.newrelic.plugins.mysql.instance
newrelic_plugin_com.newrelic.plugins.mysql.instance     0:off   1:off   2:off  3:off    4:off   5:off   6:off

ですので、少なくともRedHat系のサーバーでは、インストーラーの最後で「y」とすれば、起動スクリプトの設置や自動起動設定は不要です。

※古いバージョンでは、これらの自動設定が行われなかったのかもしれません。

なお、New Relic MySQL PluginはJava VMとして常駐し、メモリを80MB～100MB程度使用します。

New Relic MySQL Pluginのグラフ表示項目

とあるWebサービスのグラフを示します。

Overview

SQL Volume: SQLクエリ数
Key Utilization
- InnoDB Buffer Pool Hit Ratio: InnoDBバッファプールのヒット率
- Connection Utilization: コネクション数と内訳
- Tmp Tables Written To Disk: テンポラリテーブルのディスクへの書き込み発生率
- Query Cache Memory in Use: クエリキャッシュメモリの使用量
- Query Cache Hit Utilization: クエリキャッシュのヒット率

※クエリキャッシュを無効としています。

SQL Volumeでは、クエリ数と、全クエリのうち更新系が占める割合がわかります。
Tmp Tables Written To Diskが大きければ、クエリの改善を検討するほか、tmp_table_sizeとmax_heap_table_sizeパラメータを増やすと性能が改善されるかもしれません。
Query Cache Memory in UseとQuery Cache Hit Utilizationは、クエリキャッシュの有効/無効やクエリキャッシュサイズ(query_cache_size)の判断材料となるでしょう。

Database Connections: コネクション数
Network Traffic: ネットワークトラフィック

Query Analysis

SQL Commands: SQLコマンド数と内訳
Internal Temporary Tables: テンポラリテーブルの作成数と内訳
Slow Queries: スロークエリの発生数
Query Cache Usage: クエリキャッシュの利用数と内訳

Slow Queriesは、スロークエリログを有効(slow_query_log=ON)にする必要があります。

Select Query Types: Selectのクエリタイプ内訳
Table Locks: テーブルロック数
Sort Query Types: ソートクエリタイプ

Select Query TypesやSort Query Typesで、Scan（フルスキャン）に比べてRangeの割合が低いようであれば、インデックスの利用効率がよくないといえるでしょう。

InnoDB Metrics

Buffer Pool Page Operations: バッファプールの処理数と内訳
InnoDB Row Operations: 処理行数
Buffer Pool Pages Breakdown: バッファプールのページ割り当て量と内訳
InnoDB Log Writes: Redoログの書き込み量

クエリ数にもよりますが、InnoDB Row Operationsが多いと、検索の範囲を絞れていない＝インデックスの利用効率がよくない可能性があります。
Buffer Pool Pages Breakdownで空きが少ないようであれば、innodb_buffer_pool_sizeパラメータを増やす必要があるでしょう。

File Syncs: fsyncの発生数
InnoDB Checkpoint Age: ディスクにフラッシュされていないデータサイズ
History List Length: ロールバックセグメントでまだパージされていないヒストリ数
InnoDB Internal Thread Queries: InnoDB内部クエリのステータス？

InnoDB Mutexes: Mutex（相互排他ロック）の情報

※プラグインの設定で、innodb_mutexを設定していないため、グラフはありません。

Replication

Replication Lag
Master Binary Log writes
Slave Relay Log Volume
Slave I/O Thread Lag
Slave Errors

※リードレプリカは使用していないため、レプリケーションのグラフはありません。

各項目の意味やグラフの見方、この結果を利用したチューニングについては、Infinite Loop技術ブログの以下の記事もとても参考になります。
Percona MySQL Monitoring Template for Cactiを利用した記事ですが、グラフ項目はわりと似ています。

・これだけ見れば大丈夫！ーMySQLパフォーマンス監視のツボ（クエリ編）
http://www.infiniteloop.co.jp/blog/2012/03/mysql-tuning-cacti-query/

・これだけ見れば大丈夫！ーMySQLパフォーマンス監視のツボ（システム編）
https://www.infiniteloop.co.jp/blog/2013/08/mysql-tuning-cacti-system/

まとめ

Amazon RDS for MySQLを監視するための、New Relic MySQL Pluginのインストールとグラフの表示項目についてまとめました。
システムの性能を改善するには、まずは監視ツール等を利用して、どの項目に特徴があるのか、1日のうちどの時間帯やどのタイミングで値が増減するのかなど、現状の把握・分析が必要となります。

サーバーにZabbixやCactiといった監視ツールをインストールするのは少し手間がかかりますが、New RelicやMackerel等のクラウド監視サービスやプラグインを使うとエージェントのインストールだけで手っ取り早くさまざまな情報を可視化できます。

より長いスパンで監視データを確認したい場合は、やはりZabbixやCactiといった監視ツールとMySQL監視プラグインを利用するとよいでしょう。

なお、RDS for AuroraでもNew Relic MySQL Pluginを試してみましたが、InnoDB Log Writesなど一部の項目は表示されませんが、ほとんどの項目は問題なく表示されました。