SRA OSS

Zabbix対談セミナー ~仮想化環境における監視~ レポート

SRA OSSとZabbixの開発元であるZabbix社とのアライアンスによる、公式サポートサービス
最新のZabbix公式安定バージョンを完全にサポート、使い方から障害対応まで、ソースコードレベルでの高品質な対応。
大規模な利用でも安定稼働する「Zabbix DBとしてPostgreSQLを利用」の場合はPostgreSQLまで含めてトータルサポート。

Zabbix 公式サポート

セミナーの様子は、イベントレポート、ThinkIT 様の記事にて公開されております。ぜひご覧ください。

ThinkIT 連載:イベントレポート

2014年5月15日、東京、紀尾井町フォーラムにて「Zabbix対談セミナー ~仮想化環境における監視~」が開催されました。

2013年11月に新バージョン2.2がリリースされてからというもの、日本国内でも急速に導入が進み注目を集める監視ツール、Zabbix。

仮想環境の監視ツールとしてデファクトスタンダードとの呼び声も高いこのツールについて、Zabbix Japan 代表 寺島 広大氏をお招きして、当社Zabbix技術責任者である盛との対談が実現しました。

参加者の皆さんからの質疑も含めると対談は2時間にも及び、Zabbixの現状と未来について熱いディスカッションが繰り広げられました。

登壇者プロフィール
Zabbix Japan 代表 寺島 広大

Zabbix SIA にてテクニカルサポートエンジニアとして働き、2012年10月からは Zabbix日本支社の CEO として日本国内の abbixパートナーの支援、トレーニング講師を行う。

2005年に設立した Zabbix の日本コミュニティーの創設者でもあり、2010年にはZabbix の日本語書籍を執筆。

SRA OSS, Inc. 日本支社 マーケティング部
OSS 技術グループ マネージャー 盛 宣陽

SRA OSS, Inc. 日本支社で、各種オープンソースミドルウェアのサポート、コンサルティング、改良業務等に従事。

現在は、Zabbix の技術責任者として、構築支援、サポートを中心に活動している。

2013年 Zabbix Conference 等で講演など。

(司会)株式会社オープンソース活用研究所
代表取締役所長 寺田 雄一

2006年に野村総合研究所(NRI)にてオープンソース・ワンストップサービス「OpenStandia(オープンスタンディア)」を創業し、2013年まで事業責任者を務める。

オープンソースビジネス推進協議会(OBCI)、OpenAMコンソーシアム発起人。

2013年12月、NRI を退社しオープンソース活用研究所を設立。

仮想化環境における監視機能が強化されたZabbix2.2

寺田:

本日、司会進行をつとめますオープンソース活用研究所の寺田と申します。

今日は宜しくお願い致します。

まず、Zabbix Japan 寺島さん、SRA OSS 盛さん、自己紹介からお願いします。

盛:

SRA OSSでは、各種オープンソースのサポートを10年ぐらいしております。

またZabbixの技術責任者としても業務を行っています。

今日は、仮想化環境におけるZabbixについて、寺島さんの胸をお借りして、忌憚のない意見をぶつけてみたいと思います。

寺島:

現在、Zabbix Japan で日本のユーザー様、パートナー企業の支援を行っています。

Zabbixには、もともとエンジニアとして携わってきました。

ラトビアにある本社で1年半ほど働きまして、その後、2012年に Zabbix初の海外法人として日本で支社を設立しました。

今は代表をしておりますが、現役のエンジニアでもあります。

ちなみに Zabbix 本社の社長も現役エンジニアです。

2013年11月にZabbixが2.2にリリースされました。

2.2の大きな特長は、仮想化環境における監視機能が強化されたところです。

具体的にはリソース監視を中心に実装したVMwareの監視機能が搭載されました。

バージョン2.2で新しく追加された機能の一部では、私も開発にも携わっています。

今日は、Zabbixの深いところも含めてお話できればと思っています。

仮想化環境における監視の課題は、リソースの監視と対象追随機能

寺田:

近年、仮想化環境によるシステム設計が標準になってきました。

物理サーバーの時代と比べ、仮想化環境における運用監視のポイントは、どこにあるのでしょうか?

盛:

実際の運用にあたっては、次の4点がポイントになると思います。

ひとつめは、従来と比べ、監視対象がひとつ増えたことですね。

仮想化環境では、ハイパーバイザー(仮想マシンモニタ)自体の監視が増えました。

次に、どこを監視するか、という点ですね。

ハイパーバイザー側からみたリソース状況と、実際のゲストOS内部からみたリソース状況、この両者を比較しながら監視を行っていくのが、ひとつのポイントとなります。

仮想化環境では、CPUやメモリなどの仮想リソースを、ハードウエアの物理リソースの総量を越えてゲスト環境のOSに割り当てることができます。

これを、オーバーコミットと呼びます。

オーバーコミット機能を使うとリソースを共有して稼働率を高めることができますが、想定以上にシステム全体の負荷が上がることになり、個々のゲストOSだけでなく、全体的な監視が必要になってきます。

3点目は、ハイパーバイザー上でゲストOSが常に動くので、どこの物理サーバーで実際に動いてるかについて、常に追従する必要があります。

最後に、仮想化環境基板では、オートスケールなどゲストOSを追加していく状況に応じて迅速に監視が行える機能が必要となります。

寺島:

盛さんからもお話がありましたが、仮想化環境にあたって重要なのは、リソースの監視と、動的に増えていく対象に追随する機能です。

Zabbix2.2のVMware機能をまとめますと、ハイパーバイザーとゲストVMのリソース監視、vCenter/vSphereのイベント監視、vSphere API、vCenter APIの双方のサポート、自動検知、自動登録、そしてVMware監視用のテンプレートの付属、といったところになります。つまり、仮想化環境での監視における課題に対応した機能を、ひととおり揃えています。

Zabbix2.2は、2013年11月のリリース以来、VMwareの監視機能を使いたいという声が寄せられて、国内外問わず、かなり多くのお客様にご利用いただいている状況です。

VMware監視機能が搭載されたZabbix2.2の威力

寺島:

Zabbixのリソース監視設定は、非常に簡単です。

Zabbixサーバー(監視マネージャー)で運用管理者が行なう操作は、適切なテンプレートを適用させて、APIから必要なURLを登録するだけです。

この登録だけで、監視対象のゲストVMやホストOSのリソースを検知して、自動的に監視が始まる仕組みを搭載しています。

ホストをまたいで動くといった場合も、Zabbixサーバーではグループ化して管理しているので、グループが切り替わることで追随してくれます。

さらに2.0バージョンから搭載されているのが、OSなどが異なるネットワークインターフェイス、ディスクの構成などを自動的に監視項目に追加できる機能です。

これらの機能を組み合わせていくと、さまざまなことが可能になります。

たとえばゲストVMを自動的に検知するだけではなく、ゲストVMがもつインターフェイスの数、ディスクの構成までも、自動的に監視することができるのです。

VMwareの監視として、非常に簡単に始められる仕組みとともに、深い部分でVMwareの監視機能を実装していますので、監視の規模が大きくなっても管理者の方が手間がなく、スムーズに監視できるというのが特長です。

寺田:

盛さんによると、仮想化環境における監視の課題としては主に2つありました。

ゲストOSだけを監視するのではなく、システム全体で見なければならないという点と、ゲストOSが物理的にサーバーを移るので、それにどう追随するかという点でした。

今の寺島さんのお話ではZabbix2.2は、上記の課題に対応している上に、テンプレートがあるので導入が簡単というところが特長なんですね。

ところで、Zabbix2.2はオーバーコミットについて検知できるのですか?

寺島:

Zabbix2.2は、メモリ、CPUなどのリソース監視が標準になります。

ですからオーバーコミットそのものの検知とは異なります。

ただ、Zabbix内部のデータを活用することでオーバーコミットを検知することはできるようになります。

簡単設定、監視自動化、そして圧倒的なパフォーマンス

寺田:

Zabbixをユーザー企業に実際に導入する立場として、盛さんは今回のバージョンアップをどのように評価しますか?

盛:

そうですね。評価の話をするまえに、寺島さんに伺いたいことがあったのですが。 Zabbix2.2でVMwareの監視を行なうには、事前準備としてlibcurl 、libxml2をコンパイルする必要があります。

従来は、JAVAのコマンドを使って取得した部分です。

なぜ今回は、libcurl 、libxml2というHTTPとXMLでデータを取得する実装にされたんですか?

寺島:

2.2の開発時の課題のひとつが、パフォーマンスでした。

ご存知のようにvCenterの負荷が上がると監視が継続できないので、パフォーマンスを上げるためにlibcurl 、libxml2を採用しました。

ZabbixサーバーはC言語で作っていますので、Cからリクエストを出して、キャッシュ情報を活用することで、パフォーマンスを向上させることができたと思います。

盛:

なるほど。

私たちも2.2の評価は、そこにあるのではないかと思っていました。

検証を行ったときに驚いたのは、非常に負荷が軽いということでした。

従来は、VMwareの監視をしながらコマンドを叩いていると、ハイパーバイザー側に迷惑をかけたりすることがあったのですが、今回のバージョンではそれが皆無でした。

バージョンアップで こういう状況が解決されたことが、とてもうれしかったです。

パフォーマンスの改善は、多くの副産物を生んでいます。

監視自体もそうなんですが、負荷が改善されたことで、CPU使用率がかなり低くなっています。

また、負荷が改善されたことで、より多くの監視対象が増え、より多くの情報が取得できるようになりました。

あと、さきほど寺島さんからもお話がありましたが、設定も、非常に簡単になりました。

ホスト名を指定して、ユーザー名とパスワードを登録し、テンプレートをアップするだけで監視が始まります。

この手軽さには、本当に驚きました。

PostgreSQLは、突発的な負荷に強い

寺田:

盛さんは、ZabbixのデータベースとしてMySQLとPostgreSQLを比較されたそうですね。

盛:

はい。

600ホストをシュミレーションしたZabbixの立場からの検証で、5秒という短い間隔でアイテムを取得してデータベースの負荷を比較したベンチマークです。 (http://www.zabbix.com/jp/img/zabconf2013/presentations/11-sraoss.pdf)

デフォルトのメモリを同量にして、データベースを比較したところ、MySQLとPostgreSQLは、ほぼ同じ性能という結果が出ました。

また、Zabbixを運用する上で怖いのが、ハウスキーパーという負荷です。

この負荷が始まると、PostgreSQLのほうが耐性が強いことが見てとれ、突発的な負荷でもPostgreSQLは遅延が起こりづらいという結果がでました。

大規模環境であればあるほどデータベースに負荷をかけてしまうことが多く、監視に影響が出るケースが少なくありません。

この検証からは、ZabbixとPostgreSQLの組み合わせが、大企業でも安定した運用が可能であるという結果が導き出されると思います。

寺田:

PostgreSQL用のバックアップツールも開発したと聞いていますが。

寺島:

Zabbixは、監視設定も監視データもデータベースに貯めていくのですが、たとえば管理者の方が誤って設定を消してしまったような場合、監視設定だけをリストアできるツールですね。

MySQL用のバックアップツールはすでに用意されていますが、PostgreSQL用ツールは開発中です。

近々、公開できると思います。

数万規模の監視にも使われるZabbix

寺田:

仮想化環境でのZabbixの導入事例はありますか?

寺島:

従来Zabbixを導入しているのはIT企業、スタートアップ企業といった限られた業界での利用というイメージがありましたが、現在は、大手企業様の社内システムでの導入も増えています。

国内でも、金融、通信(キャリア)、公共団体などでご利用いただいています。

大規模環境での事例としては、ニフティさんがあります。

ニフティさんでは、VMwareの仮想環境で2.2をご利用いただいています。

詳細は、当社ホームページでご覧いただけます。 (http://www.zabbix.com/jp/img/zabconf2013/presentations/08-nifty.pdf)

グローバルでみると、銀行のATMでの監視をはじめとしたファイナンス系、政府機関、航空機関など多岐に渡り、監視対象が数万規模の企業も少なくありません。

グローバルで認められたZabbixの機能

寺田:

大手企業がZabbixを採用する決め手はなんですか?

寺島:

導入の動機は「これまで構築したものは残しつつ商用製品のライセンスコストを下げたい」、「パフォーマンスを良くしたい」など、企業様によってさまざまです。

コストが決め手になる局面も、当然あると思います。

ただ海外のユーザー様のお話を聞いていると、オープンソースであることが決め手になっているケースが少なくありません。

「ソースが開示されているから、自分たちが今何をしているか把握できる」というオープンソースの特性を気に入っていただいているんですね。

つまり「Zabbixの機能が好きだから使う」というシンプルな選択だと思います。

寺田:

エンタープライズ分野の運用監視は、既に標準のツールが決まっていて、新規参入は難しい印象があるのですが。

寺島:

大手企業様でも、企業内の監視ツールが標準化されていないところは少なくないようです。

プロジェクト単位で担当者が決めているという実情があり、複数のソフトがバラバラに入っているのでそれらをZabbixで統合監視したい、という話を聞くこともあります。

Zabbixは、デファクトスタンダードになるか?

寺田:

最近では監視ツールを導入する場合、いちばんはじめに候補に上がるのがZabbixだと思います。

言い換えると、Zabbix以外に他社製品の名前を聞きませんよね。

ずばり、Zabbixは、デファクトスタンダードになると思いますか?

寺島:

デファクトスタンダードになるかどうかは、私たちが決めることではないので、コメントが難しいところですが(笑)。

現状、国内で出回っているツールといえば、ライセンスが必要な商用製品と、コア部分はオープンソースで機能を追加するときはライセンスが必要、というツールがほとんどではないでしょうか?

そういったラインナップのなかでのZabbixの特長は、フルオープンソースで使えるところだと思っています。

ただしZabbixのようなフルオープンソースのツールでは、運用後に不安を抱くお客様がいらっしゃるのも事実です。

運用時、誰がサポートするのかという問題と、安定して新しいバージョンが出てくるのか、という開発の継続性の問題ですね。

Zabbixはもともと個人で開発されたソフトでしたが、企業様が導入するようになってからは法人化されました。

ですから現在のZabbixは、企業が開発しているんです。

お客様の立場からすると、ツールそのものは無料だから導入に障壁が少なく、何かあったときサポートも受けられることになります。

運用後も安定したサポートが受けられるフルオープンソース、という意味では、国内ではZabbixだけかなとは思います。

運用後も安心できる、フルオープンソース

寺田:

Zabbixのサポートサービスについて、詳しく教えてください。

寺島:

ツールが無償というと、会社としてどうやって成り立っているのか聞かれることもありますが(笑)、Zabbix Japan は、有償のサポートを提供しています。

Zabbix Japan が企業として開発やサポートを支援し、SRA さんをはじめとしたZabbixのパートナー企業さんに構築支援をしていただいています。

具体的には、何か問題が起こったときの対応、バグ報告、フィードバックができるコミュニティの運営、さらにポータルサイトでのナレッジの提供を行っています。

このポータルサイトは、今後も充実させていく予定です。

当社がもっているツールやプラグイン、テンプレートなどを共有していく場にもしようとしています。

現在、国内で30社ぐらいのパートナー企業と共に Zabbix を広めており、ユーザー企業様に安心して使っていただく土台を整えているところです。

寺田:

Zabbixパートナー企業であるSRA さんでは、どのようなサポートを受けられるのでしょうか?

盛:

もちろん Zabbix 個別のサポートも行っているのですが、当社が得意としているのは、Zabbixと他のツールを組み合わせたサポートや構築です。

特にPostgreSQLとの組み合わせや、Zabbix、PostgreSQLの冗長構成の構築などを得意としています。

Zabbixの進化の源、開発サービス

寺田:

機能改善のリクエストに基づいた開発サービスについて聞かせてください。

寺島:

実際にZabbixを導入した企業様からいただいた「こんな機能を入れてほしい」という要望をZabbixに取り込み、次のバージョンでリリースするという取り組みが、開発サービスです。

企業様の立場から見ると、商用ライセンス費用よりも廉価で、具体的な機能追加を依頼できるというのが、メリットになると思います。

機能が追加された暁にはZabbixそのものの発展にもなるだけでなく、多くのフィードバックを受けたZabbixが、一企業だけでなく、より多くのユーザー様にとって使いやすいツールに発展するところも大きなポイントです。

さきほどお話したVMwareの監視機能も、実は、特定の企業様からいただいた機能追加要望に基づいて開発が始まったんです。

現在、Zabbixに取り込まれている機能には、世界のどこかで、このスポンサーシップに近い輪から生まれものが多いんです。

Zabbixは、この開発サービスによって、日々、進化していると言えると思います。

寺田:

新しいバージョンのリリースポリシーについて教えてください。

寺島:

Zabbix2.2以降、メジャーバージョンのリリースサイクルが早まります。

開発サービスを利用する企業様が増えてきていて、機能追加をした新バージョンをなるべく早くリリースしたいというのが、その理由です。およそ半年スパンで安定的に最新版のリリースを行いながら、長期的サポートの提供も行なう予定です。

ちなみに2.4は、2014年6月にリリース予定です。

新しい機能を使いこなして、ご自身でバージョンアップされる方は2.4、同じバージョンを安定して使っていきたい方は2.2がおすすめです。

また、これまでご利用いただいていた Zabbix 1.8 は 2014 年 11 月で開発が終了します。

開発終了後はセキュリティ・ホールなどの対応が難しくなるので、バージョンアップの検討をお願いしています。

「バージョンアップ推進セミナー」という無料セミナーも随時行なっています。

参加者からの質問
【Q】Zabbixプロキシを使った、マルチテナントな大規模監視時のホストグループその他のベスト・プラクティスはありますか?

寺島:

マルチテナントというのは、複数のユーザーがいて権限をわけて、監視サービスを異なるお客様に提供しているというイメージでしょうか?

Zabbixには、権限振り分け機能はあります。

たとえば、プロキシをリモートのお客様において監視をして、集まった情報は特定のユーザーにしか見えないという設定ですね。

ただしプロキシの管理をユーザーにまかせたい場合は、ZabbixのAPIを使って調整していただいているのが現状です。

この課題について、多くのお客様からご要望をいただいていますので、次回の機能追加要望として承っています。

【Q】データセンターサービスでの監視サービスの事例はありますか?

寺島:

あります。

Zabbixの特長のひとつがAPIの存在ですね。

API経由で問い合わせをすることで、収集したデータの一部を抜き出してお客様に見せることができます。

たとえばデータセンター内の環境すべてをZabbixで監視をしておいて、お客様に監視状況を見せる場合は、APIを使って特定の情報を取得したり、ユーザー様向けのダッシュボードを作ったりすることが可能です。

【Q】階層を、もう少し深く分けることはできませんか?
2.2ではハイパーバイザーの上にVMが大量に乗っているので、システム側から見ても見づらいし、ユーザーから見ても運用がしづらいと思います。

寺島:

バージョン2.2を開発する時点で、ホストグループの階層化は課題としては上がっていたんです。

このご要望は非常に多くの方からいただいていますので、近い未来のバージョンアップで公開できるよう検討している最中です。

【Q】1.8から2.2へのバージョンアップを検討しています。
VMwareのハイパーバイザー監視をしたいのですが、エージェントのバージョンアップは必要でしょうか?

盛:

エージェントのバージョンアップは、必要ありません。

VMwareの監視ではZabbixサーバーの機能のみを使うからです。

1.8の機能で充分であればそのままで結構ですし、エージェントのほうで2.2が必要であればバージョンアップしていただければと思います。

【Q】監視対象のハイパーバイザーにもバージョンがあると思うのですが、ターゲットのバージョンに合わせたプロファイルはどのように制御しているのですか?

寺島:

いまのところZabbixが取得できるリソースデータは、ある程度決め打ちになっています。

APIに生でアクセスして、そこから帰ってくるXMLのデータで各バージョンの動作を確認していただくという流れになっています。

【Q】競合製品と比較した場合、Zabbixの優位点、不利な点を教えてください。

盛:

私は、やはり金額に尽きると思います。

寺島:

たしかにゼロ円に勝てるものはないですよね。

また、2.0以降、Zabbixは機能強化されました。

商用製品とZabbixの機能的差異は、日々刻々埋まってきていていると実感しています。

監視機能だけを取り上げれば、商用製品とZabbixはほぼ同じだと思っています。

商用製品にないZabbixの特長としては、自動化の部分でしょうか。

VMwareの監視機能ですね。

設定をテンプレート化すれば、自動的に監視項目を見つけてきて監視を始めてくれるところは、運用管理者の負担を下げると思います。

監視部分の機能だけを商用製品と比較していただくと、この機能の優位性について理解していただけるのではないかと思います。

【Q】商用製品と比べると、Zabbixはとっつきにくいという声を聞きます。
実際に現場で監視しているのは、商用製品のUIに慣れているオペレーターさんですから。こういった問題を改善するための計画はありませんか?

寺島:

そういうお客様の場合は、お客様が実際に目にする管理画面に商用製品を導入して、お客様から見えない内部のシステムにZabbixを使うという構築をするといった、フロントとバックの棲み分けを提案しています。

運用管理として総合的に考えたときには、UI、資産管理、ジョグの部分は使い慣れた商用製品でまかない、監視部分だけZabbixに置き換えるという方法は、理にかなっているかもしれません。

必要に応じて、お客様にとって最適なものを選んでいただければと思います。

【Q】AWSなどのパブリッククラウド環境でのZabbixの活用事例があれば教えてください。

盛:

AWSのクラウド監視は、クラウドウォッチというコマンドが提供されています。

Zabbixは柔軟な監視が可能なので、クラウドウォッチというコマンドを叩くことで、AWS上のデータをとることができます。

Zabbixのパートナー企業TIS社では、Zabbixのオンプレミス環境とAWS環境両方を同時に監視ができる「HyClops(ハイクロップス) for Zabbix」を開発しています。

寺島:

クラウドは、AWSのような定形サービスだけに対応するのであれば問題はないのですが、多くの場合、個別の対応が必要になります。

すべてのサービスに対応するという全方位型ツールは、反面、使いづらくなるものです。Zabbixでは、常に「どうすれば使いやすいのか?」という視点を常に考えています。

そういう意味で、Zabbix本体に機能として取り込むというよりは、クラウドとZabbixをつなぐ部分の環境づくりを考えていきたいです。

イメージとしては、Zabbix向きサードパーテイツールのようなものですね。

これも、今後の課題ですね。

【Q】Zabbixは、オープンフローでサポートを予定しているものはありますか?
オープンフローと他のソフトの連携はありますか?

寺島:

仮想ネットワークも含めて、フローについて質問をいただく機会が増えてきました。

これまでは物理的なものを監視するだけでしたから、監視対象もわかりやすかったのですが、オープンフローでは、何を監視するのかという点を再定義しなければなりません。

そのあたりを課題として、今後対応していきたいテーマのひとつです。

【Q】ビューの多様化についてはどのように考えていますか?
顧客情報、システム情報、物理環境と連携をして負荷状態を見る場合のビューですね。Zabbixはシステム監視機能は素晴らしいのですが、もう少しユーザー目線のサービスを追加して欲しいです。

盛:

Viewの多様化については、ZabbixのAPIを使って加工しています。

以前、寺島さんにJクエリにUIをつけて展開できないかと相談したことはあります。

もっと柔軟にビューを作れるのではないかというリクエストですね。

寺島:

その通りだと思います。

現状では監視項目単位がベースになったビューが多いので、違う切り口のピューは必要ですね。

運用管理者の目線も含めて、これから、深く議論をしていきたいところです。

【Q】他のシステムからの移行時の注意点を教えてください。

寺島:

残念ながら、コンバートツールの用意はありません。

監視は運用要件をどう設定に落としこんでいくかがポイントです。

ZabbixはZabbixに適した設定の作り方があるので、いったんZabbixを理解していただき、どういう監視が必要なのかを洗い出しをしていくところから、作業を始めていただきたいと思っています。

乗り換え時点で多少手間はかかりますが、現状の監視ツールを精査していただき必要な要件を見極めていただくことで、これまでより的確な通知ができるようになるし、現状の再定義、課題の洗い出しができるようになると思います。

【Q】障害が起きたときに、どのリソースを使ってたときにこの事象が起きたのか、どのログが出ていたのか、周りのリソースはどうだったのか、負荷はかかっていなかったのか、そういった情報を参照できる仕組みはないですか? 運用時にそういう機能があると助かるし、Zabbixとしての特長が出ると思うのですが。

寺島:

たしかに、そういう情報のヒモ付ができるようになるとより使いやすくなりますね。

今後の課題として、検討させていただきます。

【Q】Zabbixのデータを2次加工できるような機能はありませんか? たとえば生データを期間別、アイテム別で出力するといったような機能です。実装するのは、そんなに難しい機能ではないと思うのですが。

寺島:

仰るように、機能を実装すること自体は難しくはないんですが、要は、パフォーマンスとの兼ね合いなんですね。

たとえば2年分の情報を抽出しようとして、負荷がかかると監視が止まってしまうと、監視ツールとしてはNGなわけです。

プラグインのような外部ツールとして入れることはできると思うのですが。

【Q】監視間隔はどのぐらいが妥当ですか?

寺島:

Zabbixでは1秒~1時間間隔で監視間隔を設定できます。

リソース監視であれば5分間隔ですが、詳細は用途によって異なります。

寺田:活発なご意見をありがとうございました。今後のイベント告知などがあれば、お知らせください。

寺島:

6月に開催されるInterop Tokyo 2014(http://www.zabbix.com/jp/interop2014.php)に出展予定です。

SRAさんにもご協力いただいて、監視を担当することになりました。

このイベントでは、会場内のネットワークを出展する企業で構築しようという面白い試みに挑戦します。

盛:

Zabbix Japanさんと共同出展します。

何ができるか話し合っている最中ですが、データベースにPostgreSQLを使ってみようというアイデアもあります。

そのほかZabbixの冗長構成を実現することを考えています。

pgpoolを使って負荷分散して、Zabbixのメリットを伝えたいと思っています。

寺田:

最後に、今後の抱負をお願いします。

盛:

お客様からの要求を集めるのが私たちの仕事です。

それを寺島さんにフィードバックし、適切なソリューションを一緒に考えていきたいです。

また、Zabbixのパートナー企業間でも連携して、よりZabbixに貢献したいと思っています。

寺島:

今の私の役割は、国内ユーザー様へのサービス提供のほかに、日本の利用者が抱いているZabbixへの要望や期待を本社に伝えて、本社のエンジニアを説得することだと認識しています。

そういった意見をZabbixに反映させることでZabbixもよくなりますし、最終的にはすべてのユーザー様へのメリットにもつながると信じています。

今後も、多くのパートナー、ユーザー様と接して意見を言っていただける場を増やしたいと思います。

また、一エンジニアとしても、いろいろなところで楽しいことができればいいなと思います。

イベントも頻繁にやっていますので、ぜひ、お気軽にご参加ください。

寺田:

本日は、ありがとうございました。

facebook ブログ Youtube SRA Group
製品・サービスに関するお問い合わせ

メールフォーム

 

03-5979-2701