第4回Zabbix-JP勉強会に参加してきました

今回、初めてZabbix-JPの勉強会に参加してきました。

Zabbix2.0での新機能の話や、ミッションクリティカルな金融系システムで実際にZabbixが導入された事例など、
非常に興味深い話がたくさんでした。
Zabbixはユーザからの声によってますます良くなっていっているのを感じました。

あとは、このブログの記事をご紹介いただいた発表もありちょっとびっくりしたりしました。
Zabbix-JP伊藤さんありがとうございます。
これからもコミュニティに貢献できるよう頑張ります。

ちょっとしたことを気まぐれで書き留めているこんなブログでも参考にしてもらえているというのを聞くとやっぱり嬉しいものですね。

それでは、長文になりますが以下に興味深かった点などを残しておきます。
http://togetter.com/li/203780
ここに勉強会中のtwitterでの発信内容がまとまっていたりするのでご参考に。
※@kimukou_26さんまとめありがとうございます。

ラトビアの生活とZabbix 2.0＆カンファレンスの話

ZabbixSIA　寺島広大氏

寺島さんのお話では、Zabbix2.0の新機能の話が非常に興味深かったです。
個人的に特に注目だったのは、ローレベルディスカバリ機能、Javaプロキシ機能、nanosecondサポート、インベントリの自動入力機能などです。

ローレベルディスカバリ

NWインタフェース、ファイルシステムを自動探索
- 複数のインタフェースを持った機器の情報を自動的に探索して登録できる
- ネットワーク機器のOIDも自動的に探索、監視

これが実現すると、今まで同じホストでもNICが複数あると別々のホストとしてZabbixに登録したりと設定方法でカバーしていたことが改善されると思います。

Java プロキシ機能

JMX監視のネイティブサポート
Zabbix Javaプロキシサーバを監視対象ホストとZabbixServerの間に配置することでJMX監視が可能に
今までZabbixサーバ内でスクリプトを実行したりして取得していたJava関連の項目をネイティブでサポート
監視サーバ側でリモートからの監視を許可する設定だけでOK
Zabbixプロキシを経由しても監視結果は取得可能

今までHadoopの各ノード（DataNode,NameNode,TaskTracker,JobTrackerなど）のJavaプロセスのCPU使用率やメモリ使用率などを独自の設定で行っていたのですが、こういった複雑な設定をしなくても対応で
きそうです。

nanosecondサポート

1秒以内に複数のアラートを検知した場合に今までだとログとかトラップ監視のマクロの内容にずれが発生してしまっていたのを改善
既存の1.8系からアップデートする際もアップデート用のスクリプトが提供予定なのでそれを使えば2.0系からnanosecond対応できる

リモートコマンド

ZabbixServer側でも実行可能に。
AgentがなくてもSSH/Telnet経由でリモート側で実行させることが可能になった

Agentなしでもリモートコマンドを実行できるなどこれで更に自由度が高くなると思います。
SSHとかTelnet経由でいろいろアクション実行できてしまうということは、設定などより慎重に、また、ますますセキュリティ的な面で要注意ですね。

インベントリの自動入力

ホストのハードウェアやOS情報の自動収集

この機能はHinemosとかだと提供されていたような機能みたいな感じだろうか。HinemosだとIPアドレスとSNMPの情報を設定すると、自動的にNICやHDD、OSの情報を引っ張ってくれるのですが、そういった機>能をZabbixでもカバーしてくれると設定の負荷がかなり減りそうですね。

金融系システムでZabbix1.8をガチで使ってみた

フューチャーアーキテクト　吉田仁氏

事例概要

某金融機関の基幹システムにZabbix1.8を導入。
秒間250取引
年間4000万取引
ミッションクリティカルなシステム

特にログの監視を複雑に行った。
パトランプにも対応。

物理構成

監視対象ホスト：114台
アイテム種別:324種そのうちログ監視関連216種
アイテム数:2133個
監視項目/秒:30

ZabbixServerの冗長性

アクティブースタンバイ構成。
スタンバイ機はコールドスタンバイ。
データは共有のFCストレージに格納。
ZabbixServerの障害発生時にはコールドスタンバイ側を起動させて対応。

この発表に対する感想

個人的には、Zabbixは結構ログ監視が苦手なところなのかなと思っていたりしたのですが、この事例では相当厳しい条件でログ監視を実行されているとのことでした。
ZabbixServerの障害発生時のログについては、ZabbixAgent側のバッファサイズをデフォルトの100からMAXの65535まで拡張し、障害が発生してログをZabbixServerに送信できなくてもAgent側で保存しておけ
るようにしいたとのことです。
30分から1時間切り替えに時間がかかっても大丈夫だったらしいです。
設定や運用次第でこういったクリティカルなシステムにでも十分使えるということがわかりました。
オペレータとも早くから連携し、実際に運用を担当するオペレータの方が使いやすいように画面表示をカスタマイズされたりしていたという工夫ポイントもいい試みだと感じました。

その他

AgentやSNMPを使わずにZabbixを監視されているという話(池田朋大氏)では、
TwitterやAWSなど他のサービスのAPIを叩いた結果を監視する方法の紹介があったり、伊藤氏のお話ではZabbix自身のAPIを使って、監視結果グラフを表示するウィジェットを作成したお話などがありました>。

参加しての感想

Zabbixは自由度が高い分使い方次第でいろいろなことができると改めて感じました。

寺島さんのお話でもありましたが、CassandraとZabbixの組み合わせなど、
今後はただの監視だけでなく、NoSQLを用いた並列分散処理などの技術との組み合わせで大量監視データの分析→分析結果を生かしたActionなどできることが広がっていきそうで楽しみです。