b.l0g.jp     About     Archive     Feed

MySQLの監視はCacti+Percona Monitoring Pluginsがおすすめ(監視対象設定編)

前回のエントリではMySQLのサーバを監視できるように、CactiをインストールしてPercona Monitoring Pluginsのテンプレートを読み込んだところまで書いた。今回は、監視対象となるMySQLサーバを設定して、リソース監視を行うまでを書いてみる。なお、プロンプトがtargetとなって いるものが監視対象への設定で、serverとなっているものが監視サーバへの設定を意味している。

SNMPの設定(Ubuntu serverの場合)

Ubuntuでは標準ではSNMPがインストールされていないので、まずはインストールする。

  
target$ sudo apt-get install snmp snmpd

/etc/snmp/snmpd.confにsnmpdのデフォルト設定ファイルが置かれるので、監視サーバから情報を取 得できるように編集する。

まず、監視サーバからの読み出し許可設定を追記。SNMPコミュニティ名は「public」がデフォルト設定としては一般的だが、適宜設定。

  
\# 監視対象で設定
  
rocommunity SNMPコミュニティ名 監視サーバのIP # 追記
  
view all all # 追記

全インタフェースからの接続を許可するよう設定。

  
\# 監視対象で設定
  
#agentAddress udp:127.0.0.1:161 # この行はコメントアウト
  
agentAddress udp:161 # 追記

snmpdを再起動した後、監視サーバから以下のコマンドを実行して応答があればSNMPの設定は完了。

  
target$ sudo /etc/init.d/snmpd restart
  

  
server$ snmpwalk -v1 -c public 監視対象IPアドレス .1.3.6.1.2.1.1.1.0
  
SNMPv2-MIB::sysDescr.0 = STRING: Linux ubuntu1110s-01 2.6.38-8-server #42-Ubuntu SMP Mon Apr 11 03:49:04 UTC 2011 x86_64
  
↑ 応答の例

SNMPの設定(CentOSの場合)

通常、SNMPはデフォルトでインストールされるので、設定ファイルを編集して監視サーバから接続できるようにする。基本的にはUbuntuと同じ設定にすればよい。

  
\# 監視対象で設定
  
rocommunity SNMPコミュニティ名 監視サーバのIP # 追記
  
view all all # 追記

snmpdが自動起動するように設定し(どうやら初期設定では自動起動しないようになっている模様)、snmpdを再起動して設定を反映させる。

  
target$ sudo chkconfig snmpd on
  
target$ sudo /etc/init.d/snmpd start
  

  
server$ snmpwalk -v1 -c public 監視対象IPアドレス .1.3.6.1.2.1.1.1.0
  
SNMPv2-MIB::sysDescr.0 = STRING: Linux centos62-64-01 2.6.32-220.el6.x86\_64 #1 SMP Tue Dec 6 19:48:22 GMT 2011 x86\_64
  
↑ 応答の例

Cacti監視のためのMySQL設定

Percona Monitoring Plugins for Cactiは、監視対象のMySQLにログインして、色々な種類のshowコ マンドを実行して得られた結果をグラフにするので、監視対象のMySQLにユーザを追加する必要があ る。ここで指定するユーザ名とパスワードは、前回のエントリでss_get_mysql_stats.phpファイルに書いた、 $mysql_user と $mysql_pass と一致させること。

  
target$ mysql -uroot
  
mysql-target> grant process, super on \*.\* to ユーザ名@監視サーバ identified by 'パスワ ード';
  
mysql-target> flush privileges;

Cactiからの監視設定

監視サーバのCacti管理画面で、画像のように Create → New Graphs → Create New Host とたどり、監視対象デバイス作成画面を開く。

以下のように入力し、「Create」ボタンを押す。

Description 監視対象ホスト名など、一意に監視対象がわかる記述
Hostname 監視対象IPアドレスあるいは名前解決できる場合ホスト名
Host Template Percona MySQL Server HT
SNMP Community, SNMP Port SNMPコミュニティ名にpublic以外を指定した場合は適宜設定

Createボタンを押した後、画面下側に関連づけられたグラフが一覧表示される。Percona Monitoring Pluginsで取得できる情報は、あくまでMySQLのものだけで、実際にはLinuxの情報も取得しておく必要があるので、Host Templateに「Linux Server Default Set」を選んでもう一度Createボタンを押 して、最低限のOS関連情報も取れるようにしておこう。

ここまで時点では、画面下側に表示されたグラフテンプレートがホストにひもづけられただけで、実際にグラフの作成は開始されていない。右上の「Create New Graphs」をクリックし、画像のように 作成したいグラフを選択して、「Create」を押すと、対応するグラフの情報取得が始まる。

ツリーへのホスト追加

この状態では左上の「graphs」タブに移動しても左側のツリーには追加したサーバは表示されていないだろう。もう一度「console」タブに戻り、 Management → Devices から、監視対象デバイスの一覧を開き、今追加したサーバにチェックを付ける。右下の「Choose an action」から、「Add graph to tree」を選択してGoボタンを押し、ツリーに追加すると、めでたく graph タブのツリーにホストが現れ、グラフが表示される。

画像がリンク切れの場合、まだグラフを描画できる情報が集まっていないので、少し(5分おきの情報収集がデフォルトなので、2回分10分以上)待ってもう一度確認しよう。画像は表示されたのに、いくら待ってもグラフが表示されない場合は、監視対象から情報が取得できていない可能性があるので、SNMPの設定やMySQLの設定(特にユーザ関連)を見直すべし。

グラフをどう読み取っていくかについては、以下の記事が参考になる。記事中には「better-cacti-template」とあるが、これはPercona Monitoring Plugin for Cactiの前身となるものなので、ほぼ同じと考えてよい。

これだけ見 れば大丈夫！ーMySQLパフォーマンス監視のツボ（クエリ編）

今回はPercona Monitoring Plugin for CactiのMySQLに関する部分だけを紹介したが、ApacheやMemcached、nginx、redisなどの情報グラフ化もできるので、お試しあれ。

MySQLの監視はCacti+Percona Monitoring Pluginsがおすすめ(監視サーバ構築編)

MySQLをリソース監視する仕組みにはいくつかあるが、対象のMySQLサーバが5台以上ある場合はCactiがおすすめ。導入のしやすさだけでMuninを選ぶ人が多い気がするが、その選択基準は間違っている！

 

Cactiのいいとこわるいとこ

  • 多数のグラフを見やすく並べられる
  • muninと比べて多数のサーバから軽快に情報を収集・表示できる
  • 監視対象には、MySQLのユーザを追加するだけでかなりの項目数を監視できる
  • データの保存にデータベースが必須だったりしてセットアップがやや面倒
  • 慣れるまで監視プラグインを書くのに手間取る

Muninのいいとこわるいとこ

  • 監視プラグインを書くのが簡単
  • 監視サーバにデータベースなどが必要なく、セットアップが簡単
  • グラフの並び方などが固定で、比較などがしにくい
  • 監視対象にプラグインを入れなければならず、台数が多いとそれだけ手間が増える
  • 監視対象が増えると監視サーバの負荷が急激にあがるので、あまり多数のサーバは監視できない

そんなわけで、CentOS 6.2上にCactiの監視サーバをセットアップし、Percona Monitoring Plugins for Cactiを使ってMySQLサーバ(CentOSまたはUbuntu)のリソース監視を始めるまでの手順。その1は監視サーバのセットアップ編。

RPMforgeのリポジトリ追加

RPMforgeリポジトリには最新のCactiが含まれているため、これを導入する。

  
$ wget http://pkgs.repoforge.org/rpmforge-release/rpmforge-release-0.5.2-2.el6.rf.x86_64.rpm
  
$ sudo rpm -ihv rpmforge-release-0.5.2-2.el6.rf.x86_64.rpm
  
$ sudo yum -y update rpmforge-release

/etc/yum.repos.d/rpmforge.repo ファイルをエディタで開き、 enabled = 0 にする。これで、オプションを付けないとRPMforgeはリポジトリとして有効にならないようになる。

Cactiのインストール

Cactiと、あわせて必要なnet-snmpやhttpd、MySQLなどをインストール。

  
$ sudo yum install -enablerepo=rpmforge cacti net-snmp-utils mysql-server

指定したもの以外に、依存関係上httpd, mysql, perl, php, rrdtoolなどもインストールされる。

MySQLの設定

Cactiが取得した情報を格納するためのMySQLを設定する。ここでは最低限必要な設定だけを記述するが、CentOS 6.2のMySQLの/etc/my.cnfは非常にシンプルなので、必要に応じてパラメータを指定すること。

[mysqld]セクションに以下を追加

  
skip-character-set-client-handshake
  
character-set-server = utf8
  
collation-server = utf8\_general\_ci
  
init-connect = SET NAMES utf8

(2012.05.29) default-character-setは不要とnippondanjiさんからはてブコメントで指摘をいただいたので削除。直々にご指摘とは恐縮です。

ここでMySQLを再起動する。

  
$ sudo /etc/init.d/mysqld restart

statusコマンドで、charactersetがutf8であることを確認。

  
mysql> status;
  
(略)
  
Server characterset: utf8
  
Db characterset: utf8
  
Client characterset: utf8
  
Conn. characterset: utf8
  
(略)

Cactiのドキュメントにしたがって、Cactiで使用するMySQLの設定を行う。

  
$ mysqladmin -user=root create cacti
  
$ mysql cacti < cacti.sql
  
$ mysql -user=root mysql
  
mysql> grant all on cacti.* to ユーザ名@localhost identified by 'パスワード';
  
mysql> flush privileges;

Apache/PHPの設定

/var/www/cacti/include/config.php を上の項で作成したユーザに合わせて編集する。

  
$database_type = "mysql";
  
$database_default = "cacti";
  
$database_hostname = "localhost"; # DBサーバのホスト名
  
$database_username = "cactiuser"; # 上の項で作成したユーザ
  
$database_password = "cactipassword"; # 上の項で設定したパスワード

/etc/httpd/conf.d/cacti.php が存在することを確認する。他のホストからCactiにアクセスする際は、以下の行を追加してhttpdを再起動する。

  
allow from 127.0.0.1
  
allow from IPアドレス # 追記

Cactiのドキュメントを参考に、/etc/php.ini および /etc/php.d/*.ini の記述を確認。設定を変更したら、Apacheを再起動する。

  
$ sudo /etc/init.d/httpd restart

iptablesの設定

CentOS 6.2ではデフォルトでpingやSSHしか応答できないようにされているようなので、/etc/sysconfig/iptables に以下を追加してhttpのアクセスが可能なようにする。

  
-A INPUT -m state -state NEW -m tcp -p tcp -dport 80 -j ACCEPT

iptablesを再起動

  
$ sudo /etc/init.d/iptables restart

設定完了

Cactiをインストールした際に /etc/cron.d/cacti が既に作成されているので、この時点で5分おきに情報収集が始まっている。

http://CactiサーバのIPアドレス/cacti を開くと、まずインストールの確認ウィザードが開始される。

ここまでの設定を改めて確認されるだけなので、基本的にはNextを押していけばいい。各種ツールのパスを確認される画面が最後にあるが、ここでパスが見つからない場合は手動でパスを入力するか、不足しているツールをインストールして再度試すべし。

この後ログイン画面が表示され、ユーザ名 admin 、 パスワード admin でログイン可能で、すぐにパスワードの変更を促されるので画面の指示に従って変更する。

Percona Monitoring Plugin for Cactiの導入

PerconaからPercona monitoring pluginsをダウンロードし、ファイルを展開する。

  
$ tar zxvf percona-monitoring-plugins-1.0.0.tar.gz
  
$ cd percona-monitoring-plugins-1.0.0/cacti/scripts
  
$ sudo cp ss\_get\_by\_ssh.php ss\_get\_mysql\_stats.php /var/www/cacti/scripts/

監視対象のMySQLにログインする際のアカウント情報を ss_get_mysql_stats.php に書き込む。

  
$mysql_user = 'cactiuser'; # 監視対象にログインする際のMySQLユーザ
  
$mysql_pass = 'cactiuser'; # 監視対象にログインする際のパスワード

Cacti管理画面からImport/Export → Import templatesを選択し、Import Template from Local Fileで以下を指定してImportボタンを押し、テンプレートファイルを読み込ませる。

  
percona-monitoring-plugins-1.0.0/cacti/templates/cacti\_host\_template\_percona\_mysql\_server\_ht_0.8.6i-sver1.0.0.xml

成功すると、それぞれの監視項目に対応したテンプレートごとに[success]と表示される。

これでMySQLサーバを監視するための監視サーバの準備は完了。

(2012.05.28追記) 監視対象側の設定についても書いたので、続けてどうぞ。

MySQLの監視はCacti+Percona Monitoring Pluginsがおすすめ(監視対象設定編)

MyISAMを使っている時key_buffer_sizeは大きくし過ぎてもいけない

MyISAMのみを使っているMySQLサーバで、key_buffer_sizeのサイズは大きくても小さくてもダメですよ、という例。

その前にちょっと復習。MySQLの主なストレージエンジンといえばMyISAMとInnoDBだが、データやインデックスのキャッシュの仕組みには、

  • InnoDB : インデックス、データともMySQLがキャッシュ管理する(innodb_buffer_pool_sizeで設定)
  • MyISAM : インデックスはMySQLがキャッシュ管理する(key_buffer_sizeで大きさを設定)。データはOSのキャッシュ機構におまかせ

という違いがある。

ものすごく簡単に言えば、InnoDBの場合はなるべく大きな innodb_buffer_pool_size を設定してやれば、インデックスかデータかに関わらずメモリ上にキャッシュされて高速化が図れる可能性がある。一方MyISAMの場合、key_buffer_size を大きくしてもインデックスしかキャッシュされないので、OSがデータ部分をキャッシュするメモリ(つまりMySQLに割り当ててないメモリ)もある程度確保しておく必要がある。この辺りのことはMySQLのドキュメントには以下のように書かれている。

innodb_buffer_pool_size

専用サーバの場合物理メモリの80%。

MySQL 5.1 リファレンスマニュアル 13.5.4. InnoDB 起動オプションとシステム変数

key_buffer_size

「一般的には、マシンのメモリ使用率 25 % の値であることが好ましい」一方で

「Key_reads/Key_read_requests の比率は、0.01 より小さいことが望ましい」つまり

99.9%がキャッシュされていることが望ましいということ。

MySQL 5.1 リファレンスマニュアル 4.2.3. システム変数

とある参照用のスレーブ(MyISAMのみ使用)で、アクセス数とともにデータ量も増加して、インデックスがメモリに乗りきらず、Key_reads/Key_read_requests (以下key bufferヒット率という)が80%台まで落ちてしまっていた。

メモリを増設してkey_buffer_sizeを調子に乗ってでっかく取ってみたが、key bufferヒット率は99.9%になったものの、相変わらずディスクからの読み出しは多い。ここで、上に書いた仕組みに思い当たり、データ部分をキャッシュするOS用のメモリが不足しているのでは、と思って一旦key_buffer_sizeを少し減らしてみた。

  • インデックスのサイズ : 22GB
  • 従来 key_buffer_size : 4GB (OS物理メモリ12GB)
  • 増強後 key_buffer_size : 12GB (OS物理メモリ24GB)
  • その後 key_buffer_size : 8GB (OS物理メモリ24GB)

すると一目瞭然、以下のグラフの青枠部のようにディスクからの読み出しは半分以下に減った(赤線が設定を変更した時点)。

key_buffer_sizeを大きくしたからといってパフォーマンスが上がるというわけではないのである。上の例から分かるように、全インデックスがメモリに乗らなくても、よく使うインデックスがほぼメモリに乗っていれば問題ない。常にkey bufferヒット率が最大になり、ディスク読み出しが最小になる key_buffer_size を探ることが必要ということだ。サイズはオンラインでも変更できる。ただし、コマンドを実行するとkey bufferの中身は一旦空になり、改めてキャッシュが構築されるため一時的にディスクIOが大量に発生するので注意(停止できるサーバならキャッシュウォームアップをした方がよい)。

  
mysql> set global key\_buffer\_size = バイトでのサイズ(1GBなら1073741824);

確認は show variables で。以下は4GBの例。

  
mysql> show variables like 'key\_buffer\_size';
  
+------+----+
  
| Variable_name | Value |
  
+------+----+
  
| key\_buffer\_size | 4294967296 |
  
+------+----+
  
1 row in set (0.00 sec)

そもそもインデックスがでか過ぎるのでシェイプアップすべきとか、テーブル分割を考えるべきといった別の解決方法も考えられるのだが、わかりやすいグラフが取れたのでひとつの例として。