2013年11月15日金曜日

Zabbix 2.2をリリースしました!

11月12日、Zabbixの新メジャーバージョンとなるZabbix 2.2をリリースしました。このバージョンではVMware仮想環境の監視機能と、Windows WMIサポートなどの新機能が追加されています。

Zabbix 2.2の新機能の一覧はZabbixドキュメントのWhat's New 2.2.0のページに記載されています。

OSC Kyotoで私が講演した「Zabbix 2.2の新機能とオフィシャルサービスの紹介」の資料はSlideShareで公開していますので、こちらもどうぞ。

あとはZabbix認定パートナーのSRA OSSさんがZabbix 2.2の評価レポートを公開されています。新機能を使ううえでポイントとなるところがまとまっています。

Zabbix 2.2では100以上の新機能と機能改善を行っています。新たな監視機能はもちろん、パフォーマンスも一層向上し、1台の監視サーバーから数万オーダーの監視対象を監視できるようになりました。これまで世界中の大規模システムのカスタマーから寄せられた具体的な報告をベースに改善を行ってきているため、そのパフォーマンス改善はすでに実証済みのものがほとんどです。

1つ前のメジャーバージョンとなるZabbix 2.0リリース以降、世界中のカスタマーやパートナー、コミュニティからおよそ3,000にのぼる機能修正、機能追加要望がありました。Zabbix 2.2リリースまでの1年半の間にそのうちおよそ2,000件の修正、コミット数にして12,000コミットを達成することができました。

外からわからない部分でも内部的には大きく作り替えられているところもあり、大小さまざまな点で改善が行われています。Zabbix 2.2のRPMパッケージ、Debパッケージもすでに公開していますので、ぜひ使ってみてください。yum/aptを使って簡単にインストールできます。インストールなどはドキュメントをご参考ください。

Zabbix 2.2のリリースまでの道のり

本来はZabbix 2.0のリリースから1年後の今年5月に2.2をリリース予定だったのですが、いくつか大きな機能の追加があり、今回は1年リリースは達成できませんでした。長い間待っていただいたユーザーの方々、大変お待たせしました。

今回はZabbix Japan設立後初、かつオフィシャルRPM/Debパッケージを公開してからも初のメジャーバージョンのリリースということもあり、いろいろと準備に奔走しました。リリースは予定より半年遅れたものの、私個人やZabbix Japanとしては多少時間的に余裕があって逆に良かったのかもしれません。

9月にはZabbixパートナー会でZabbix 2.2の共同検証を行い、細かな問題点を洗い出すことができましたし、この時点でZabbix認定パートナーとは2.2の細かな改善点や修正点も共有でき、Zabbix 2.2の活用に向けてもパートナー含め準備を整えることができました。

Zabbix 2.2のリリース前にはBug Squashing Eventを開催し、コミュニティユーザーと共同でRC前の1日の間に159コミット、37件のバグ修正を行いました。クオリティもこれまでのリリースに比べて向上しています。イベント前後でWebインターフェースの翻訳も完了させることができ、日本語のインターフェースは翻訳率100%に1番乗りでした。

今回はこのイベント自体も初開催だったためアナウンスが十分ではなかったこともあり、私も参加していた夕方以降(日本時間)で知っている限り、残念ながら日本からの参加や報告はなかったように思います。次回2.4のときも同じようにリリース前のクオリティ向上のためのイベントが開催されると思いますので、ぜひ参加してみてください。英語で海外のエンジニアとコミュニケーションできる絶好のチャンスですし、不安なところがあればサポートしたいと思います。

Bug Squashing Event中、隣の席で参加いただいた@qryuuさん、あとインターフェースの日本語訳などを細かく改善していただいた@atanakaさん、どうもありがとうございました!

次の2.4でも再度、1年後のリリースを目指します。以前よりも社内でのワークフローの流れも良くなり、開発スピードは上がってきているので、次回は達成できるのではないかと思っています。期待して待っていてください!

旧バージョンからのアップグレード

日本ではまだZabbix 1.8を利用されているユーザーも多いのではないかと思います。Zabbix 2.0ではローレベルディスカバリによるアイテム/トリガー/グラフ設定の自動作成や、SNMPトラップの設定方法/パフォーマンスの改善、トリガーのメモリキャッシュによるZabbixサーバーのパフォーマンス改善など、Zabbix 2.2では加えてVMware監視機能、Web監視の改善、WMIサポート、さらなるパフォーマンス改善などさまざまな機能追加と改善が行われています。

Zabbix 2.0/2.2にアップグレードすると監視のパフォーマンスが改善されることによってより多くの監視設定ができるようになり、設定管理の手間も大幅に改善されます。ぜひこれを機会にアップグレードを検討してみてください。

ただ、残念ながら1.8以前のバージョンから2.0以降にアップグレードするためには、Zabbixデータベースの過去の監視データが保存されている領域の変換処理が必要となり、多くのデータが保存されている場合は変換処理に数時間を要します。その間、Zabbixサーバーは停止する必要が出てきてしまいます。(この機能改善はZabbix 1.8の時代にNTTコムテクノロジーさんからの協力で行われたものですので、ZABICOM 1.8を使われている場合はアップグレードの時間はかかりません。)

Zabbix社では世界中の大規模ユーザーのサポートを行う中で、1.8以前から2.0以降へ、監視の停止時間を最大で数分までに抑えてアップグレードするノウハウがあり、Zabbixパートナー会で日本国内のZabbix認定パートナーにはその技術をお伝えしてあります。

Zabbix 2.2リリースにあわせて、Zabbix 2.0/2.2ファストアップグレードサービスも開始しますので、アップグレードしたいけれども不安がある場合はご活用ください。

Zabbix 2.4に向けて

社内でひたすらバグ修正と機能追加を行っている開発チーム、世界中のカスタマーやパートナーからのサポートに答えつつ、コミュニティの対応も行っているサポートチームにひとまずお疲れさまと言いたいところですが、これからZabbix社では次の2.4リリースに向けて議論を行っていきます。

日本国内から要望として多く上がっている機能については、次の2.4リリースに追加すべく私から社内でpushしていきますので、何か要望がある方はイベントなどで私を捕まえていただくとか、twitterで@kodai74もしくは@zabbix_jp宛にメッセージを送るか、公式サポートを利用いただいているユーザー様はパートナー経由でぜひ意見を上げてください。Zabbixはこれまで、ユーザーからの意見を着実に反映して機能強化/改善を行ってきています。

Zabbix 2.4に必ず追加して欲しいという機能があれば、開発サービスも提供しています。2.2で追加されたVMware監視機能、Web監視機能の改善などは、世界中のユーザーから開発サービスを利用して頂いて実現した機能です。Zabbixを個別カスタマイズするくらいなら、開発サービスを利用した方がコミュニティへの還元と、以降のメンテナンスコストの大幅削減を実現できると思います。

最後に

とにもかくにも、Zabbixは世界中の協力的なコミュニティ、ユーザー、カスタマー、パートナーに支えられて日々、順調に開発が進んでいます。引き続き、ご期待&ご協力をよろしくお願いします!

2013年11月3日日曜日

Zabbixで10,000台のサーバーを監視する

Zabbixは重い!というツイートや情報があったりするのですが、海外ユーザーのサポート経験からZabbixのパフォーマンスは驚くほど良くなっていると思っていて、どこに違いがあるのか不思議に思っていたりします。

Zabbix社で大規模システムというと、監視対象が数千台規模以上、1秒あたりの監視項目数(Zabbixのダッシュボードやレポートメニューから見れる値、以降nvpsと書きます)が1000を超えるくらいからです。本社ではこのnvpsの値が1万に到達しようとしているユーザーをサポートしています。

海外のZabbixサポートユーザーはボトルネックになっている点についてZabbix本体に修正要望を出し、Zabbix本体のパフォーマンスを上げつつ監視規模を拡大していっています。(自分たちである程度修正できるだけの技術力は持ちながらも)そうやって自社での個別ソース修正などを避けることで不要な運用コストを削減しているようです。本社に行ってサポートの仕事をし始めたころ、海外のユーザーはOSSをよく理解し、サポートをうまく活用してるんだなぁと関心したものでした。(バグについても同様です)

そうやってマイナーバージョン、メジャーバージョンごとにパフォーマンスが改善されて今があります。実際にユーザーが大規模環境で使っている以上、パフォーマンスが悪いはずはないと思ってます。

ちなみに、海外のユーザーはZabbixサーバーを複数台に分けることはあまり好まないようです。そもそも複数台に分けると監視設定の管理などの運用コストが高くなるため、それを嫌っているのだろうと思っているのですが実際に聞いたことはないので真相は不明です。

ということで、Zabbixのパフォーマンスはそんなに悪くないよ!ということを自分でも確認するためにも、今回はそこそこのハードウェアで10,000台の監視ができるかどうか?というパフォーマンステストを行ってみました。

利用したサーバーのスペックはこちら。1Uタイプのサーバーを購入したことを想定して、それほど高価にならないスペックで構成してみました。

  • CPU: Intel Xeon E3-1240 v2 (4C/8T 3.4GHz)
  • メモリ: DDR3-1600 16GB
  • RAIDカード: LSI MegaRAID SAS 8708EM2 (3GBps/BBWC付き 128MBキャッシュ)
  • ディスク: Seagate 3.5inch SATA HDD 64Mキャッシュ x2 RAID 1構成

RAIDカードだけ古いのですが、手元に余っていたのがこれだけだったのでご勘弁を。SATAを利用しているのでそれほどパフォーマンスに影響はないかなと思っています。

パフォーマンスの測定方法

日本ではRHELやCentOSが使われることが多いと思うので、上記サーバーにCentOS 6.4 x86_64をインストルし、MySQL 5.1、Zabbix 2.0.9をインストールしてテストを行います。

さすがに監視対象を数千台も用意できないので、VMware上で3台ほどLinuxサーバーを起動してZabbixエージェントをインストール、Zabbixに同じIPで異なるホストを登録していきます。Zabbixのエージェントは動作が軽量なので、これでも十分耐えられます。

監視にはZabbix 2.0.9に標準で付属するTemplate OS Linuxを利用します。デフォルトでは監視間隔が短めなので、すべての監視項目を5分間隔の監視に変え、過去データの削除処理の負荷を見るためにヒストリの保存期間を7日に変更しています。ローレベルディスカバリも動作するとだいたい1ホストあたり45監視項目になります。

MySQLの初期設定

MySQLには以下の基本的な設定を入れてから起動してます。他にもパフォーマンス改善のためのチューニング設定はありますが、とりあえずはベーシックなチューニングを行っています。

innodb_file_per_table
innodb_buffer_pool_size=12G
innodb_log_file_size=256M
innodb_log_files_in_group=2
innodb_flush_method=O_DIRECT

また、RHEL/CentOSに付属のMySQLはRHEL/CentOS 6.3以降でInnoDB Pluginが利用できるようになっています。InnoDB Pluginを利用することで、内部の書き込みスレッドを複数起動し書き込みパフォーマンスが向上します。

/etc/my.cnfに以下の行を追加するだけでInnoDB Pluginを有効にすることができるので、これを設定しない手はありません。今回は最初からInnoDB Pluginを有効にした状態でテストを行っています。

ignore-builtin-innodb
plugin-load=innodb=ha_innodb_plugin.so;innodb_trx=ha_innodb_plugin.so;innodb_locks=ha_innodb_plugin.so;innodb_lock_waits=ha_innodb_plugin.so;innodb_cmp=ha_innodb_plugin.so;innodb_cmp_reset=ha_innodb_plugin.so;innodb_cmpmem=ha_innodb_plugin.so;innodb_cmpmem_reset=ha_innodb_plugin.so

RAIDカードの設定

ライトキャッシュの効果を見たかったので、最初はRAIDカードをWrite Throughモードで動かしています。負荷が高くなったときにライトキャッシュをONに設定してみます。

パフォーマンスの見方

パフォーマンステストはCPUロードアベレージ、CPU使用率、Zabbixのプロセスのビジー率、監視アイテムのキューを見ながら、

  • CPUロードアベレージ、CPU使用率が高くなっていないか
  • Zabbixプロセスのビジー率が高くなっていないか(70%以下が目安)
  • アイテムのキューが溜まっていないか

という点を見ていきます。基本的にはアイテムのキューの数が増えなければ遅延なく監視できていると判断できます。

では、パフォーマンステストを行っていきます。

MySQL 5.1、5000監視対象

とりあえず5000ホストを登録。アイテム数が22万、720nvpsほどになってます。

mysql51-5000-status

このときのパフォーマンスグラフです。まだロードアベレージやCPU使用率は余裕があります(上の2つのグラフ)。キューも溜まっていません(右下のグラフの赤い線)が、housekeeperプロセスのビジー率が1時間に1回高くなっていることが分かります(右真ん中のグラフの黄色線)。

housekeeperというのは過去のデータを削除するためのプロセスなのですが、大規模になるとデータ数も多くなり、削除するデータを探す->削除するという処理に負荷がかかっていることが分かります。

Mysql51 5000 screen

housekeeperが重くなることは想定済みなので、あとでDBのパーティショニングを行いたいと思います。この時点では他の点ではほとんど負荷がない状況なので、とりあえずこのまま1万台までホストを追加してみます。

MySQL 5.1、10000監視対象

ホストを10000台まで追加してみました。アイテム数45万、1400nvpsほどになっています。

Mysql51 10000 status

さすがにこのくらいになるとキューが溜まっていて、スムーズに処理ができないようになってきました。ただ、ロードアベレージとCPU使用率はそれほど高くないですが、history syncerのビジー率が100%になっている(右真ん中グラフの赤線)ことと、history write cacheの空き率(左下グラフの青線)がときどき0%になっています。

history syncerは収集したデータをメモリキャッシュからDBに書き込むためのプロセスで、DBへの書き込みがボトルネックになっていることが分かります。

Mysql51 10000 screen

実はこのあとhousekeeperを止めてDBのパーティショニングを行ったのですが、パフォーマンスの改善は見られませんでした。上記のグラフの通り、housekeeperプロセスが1時間に1回動いたとき、housekeeperのビジー率は高いものの、そのときにCPUやI/O負荷に与える影響はそれほど大きくなっていないため、止めてもそれほどシステムへの負荷は変わらなかったようです。(ちなみにこの時点でZabbixのDBはトータル100GBほどありました。)

MySQL 5.1、10000監視対象、ライトキャッシュ有効

ここでRAIDカードのライトキャッシュを有効にしてみたところ、負荷が大幅に下がりました。グラフ真ん中の少し途切れているところがライトキャッシュを有効にするためにサーバーを再起動したところです。

ライトキャッシュを有効にする前のCPUのI/O waitの値はそれほど高くないものの(およそ25%程度)、RAIDカードを搭載してライトキャッシュを有効にすることでパフォーマンスは大幅に改善されることが分かりました。

Mysql51 writecache

MySQL 5.1、10000監視対象、ライトキャッシュ有効、より細かなチューニング

上記でもかなりパフォーマンスは改善されたのですが、まだ1時間に1度history syncerのビジー率が高くなっていることが分かります。これはトレンド(グラフ用に収集データをサマリしたもの)の計算を行う処理が1時間に1度動作するためです。

デフォルトのTempate OS Linuxに含まれている監視設定には数値データのものが多いため、トレンドデータの計算にも負荷がかかりやすい状況になっているようです。

キューに溜まっているアイテムは0になっているため監視の処理自体はスムーズに行われているものの、このトレンド計算のための負荷が気になります。もうちょっと負荷を抑えられないかということでOS、MySQL含めいろいろとパラメータ調整を行ってみたところ、ある程度まで負荷を落ち着かせることができました。

Mysql51 10000 tuned

ところどころキューが出ていますが(右下グラフの赤線)、多くても2個程度ですし、すぐに0に戻っているためあまり問題にはならなさそうです。

グラフの後ろの方でhistory syncerの負荷が上がっているタイミングがありますが、これは直前にWebインターフェースから長い期間のスクリーンを表示したことによる影響が出ているのだと思われます。I/O負荷などはまだ低いのでもっと監視対象を増やせそうな気もしますが、Webインターフェースからの負荷の影響があることを考えると、このくらいに止めておいた方が良さそうです。

MySQL 5.5、10000監視対象

さて、いろいろなところでMySQL 5.5のパフォーマンスが良いという情報がありますし、海外の大規模Zabbixユーザーの多くはMySQL 5.5(そろそろMySQL 5.6に移行中)です。MySQLを5.5にアップグレードするとパフォーマンスがより改善され、Webインターフェースからのアクセスがあっても安定するのでは、という期待をこめてテストをしてみました。MySQLの設定は上記と同条件で、InnoDB Pluginは5.5でデフォルトとして採用されたためパラメータをコメントアウトしています。

Mysql55 10000 screen

個人的にかなり期待してアップグレードしたのですが...。あまりパフォーマンスが改善された様子はなく、なんだか逆に少し悪くなっているような気もします。5.5で追加されたパラメータなども調整してみたのですがあまり変わらずでした。

history syncerが発行するクエリは単純なinsertですし、InnoDB PluginとMySQL 5.5ではZabbixサーバーが使う部分ではそれほど大きな違いはないのかもしれません。

結論

Zabbix 2.0.9とMySQL 5.1で10,000台、45万アイテム/5分間隔という規模でも監視できることを確認できました。正直、このハードウェアでこれだけ監視できれば十分なのではと思ってます。

また、今回テストした環境ではMySQL 5.1ユーザーは少なくともInnoDB Pluginを利用していれば十分パフォーマンスは得られそうです。苦労してMySQL 5.5にアップグレードしてもあまり効果はないかもしれません。それよりも、適切なハードウェアを選択し、適切なチューニング設定を行う方が大切に見えます。

今回のテストでは主に数値データを収集していますので、ログ、トラップデータ監視が大量にある場合はまた違った結果になるかもしれません。余力があれば、ログやトラップデータを中心に監視した場合のテストと、MySQL 5.6を利用したテストも行ってみたいと思います。