第4回ZABBIX-JP勉強会 発表資料（Session2） 「金融系システムでZabbix1.8をガチで使ってみた　～Zabbix2.0に期待することも語りたい」 発表者：吉田　仁（フューチャーアーキテクト株式会社） 2011年10月22日　公開

1. 金融系システムで
Zabbix1.8をガチで使ってみた
Zabbix1.8をガチで使ってみた
～Zabbix2.0に期待することも語りたい ～
2011年10月22日 第4回Zabbix勉強会
吉田 仁（Future Architect)
@yossyh

2. 本日の目的
•金融機関の重要基幹システムに、Zabbix1.8.5
（コミュニティ版）を導入し、無事運用開始し
ました。
•そのときのあれこれを語ります。
•ご経験済みの方は共感を、これからの人には成
功へのヒントをお伝えできれば幸いです。

3. Thank you
•ATNDにて。
＿＿＿_
／:::::::::: u＼
／:::::::::⌒ 三. ⌒＼ えぇぇぇ、寺島さん本人？
／:::::::::: （ ○）三（○）＼ @kodai74:@yossyh
|::::::::::::::::⌒（__人__）⌒ | ＿＿＿＿＿＿＿_
＼:::::::::: ｀ ⌒´ ,／ .| | ...| こんにちは。Zabbix-
ノ::::::::::u ＼ || |
／::::::::::::::::: u || | JPの勉強会ですが、ぜ
|::::::::::::: ｌ u || |
ヽ:::::::::::: -一ー_~､⌒)^),-､ | |_＿＿＿＿＿＿__.| ひ発表お願いしたいで
ヽ::::::::＿＿＿,ノγ⌒ヽ)ニニ-￣ || |
す。

4. 自己紹介
吉田 仁
フューチャーアーキテクト株式会社
Twitter @yossyh
太田 和哉
フューチャーアーキテクト株式会社
村田 直紀
フューチャーアーキテクト株式会社

5. 自己紹介
• フューチャーアーキテクト株式会社
– 旧フューチャーシステムコンサルティング株式会社
• 中立／オープン
– 様々な監視製品を駆使
• 最適化
– 要件/環境/コスト等の全要素において最善を尽くす
• 技術志向
– コンサルティング～設計～実装～運用まで一貫対応
– 最新の技術は適切なタイミングで活用

6. システム概要
•某金融会社の最重要システム
– 既存システムのHW更改＆DC移設
– 業務量拡大につきサーバ処理性能拡張
– 秒間 250取引
– 年間 4000万取引
– 24時間365日運用
•エラーは取引の滞りを意味する。フォローが必要
•障害発生→秒単位で損失/迷惑が発生する
ミッションクリティカルシステムそのもの

7. システムの特徴
リプレース
• 現行システムの運用はそのまま踏襲
スケールアウト＆コストダウン
• 性能拡張のため、台数が増える
• でもランニングコストは増やしたくない
特殊なログ運用
• 取引のエラーを確実に拾うため、大量のログ監視
• 長年の運用経験から得た、複雑かつ多数の監視条件がある

8. Zabbix採用までの経緯
目標設定
• 限りあるお金はメリハリをかけて使いたい
– 安全性や性能等、必要なところには十分お金を
– 工夫できるところは積極的にコスト削減したい
タイミング
• 弊社内部システムで導入・運用経験あり
• お客様の別システムでも導入・運用経験あり
• 日本語情報の増加 / クラウド等への意識
リスクヘッジ
• 何かあったときの備えはある
– Nagiosとか、自分で機能カバーするとか・・・俺らがんばれ。

9. Zabbix導入決定のまえに
• 現行監視システムでできることは、Zabbixではできないとね
パトランプ対応 金融系では相変わらず大好き
監視条件設定 排他関係/依存関係とか
Windows対応
vCenter orz。
vmware対応
大量ログ対応 Agent側でフィルタ必須
Zabbix障害対応 エラーの見過ごしが許されない

10. 参考にさせていただいた情報
BIBLE
!!
• Zabbix-JPフォーラム
• @IT：Linux Square Zabbixのインストール（青山さん）
• http://www.atmarkit.co.jp/flinux/rensai/zabbix01/zabbix01a.html

11. 設計/実装時の方針
• 最初に優先順序を設定
Zabbix必達！！ 他で対応
• Zabbixによるワンストップ監視 • トレンド分析・レポート作成
を実現する – 既存運用で定型フォーマッ
– イベントは確実に拾える トでの状況分析を行ってい
– イベントは確実に通知する る（EXCEL活用）
• 障害対策 – Zabbixのデータを使うが、
– リカバリ迅速化 グラフ描画はEXCELで
【番外】早期構築
– 構築・テスト時点でZabbix
を有効活用

12. 監視実績
サーバ 36 SAN関連 6
対象ホスト １１４台 NAS関連 1 NW機器 42
Tape装置 2 VIP 21
SNMPtraps 1 ZAP-CAT 5
性能監視 95 ログ監視 216
アイテム種別数 ３２４種 SNMP監視 8 PING監視 4
死活監視 1
アイテム数 ２,１３３個
トリガー数 １,６０７個
テンプレート数 ２９個 カテゴリ別にテンプレートを
作成。設定効率化に寄与
ユーザ数 １０ユーザ
監視項目/秒 ３０件/秒
アクション保存期間 ７日
イベント保存期間 ９０日

13. 物理構成
• シングルサーバ（コールドスタンバイ構成）
– Zabbixは設定情報もすべてMySQLに入っている
• ハードウェア故障時にも短時間で切り替え可能
DELL PowerEdge R610
ACTIVE Xeon 5500×1（4Core）
4GB Memory
RHEL5.4（X86-64）
Zabbix 1.8.5
FC共有ストレージ
２０GB
STANDBY
↓
ACTIVEダウン時に、
オペレータがリモートパワーON

14. 機能構成
• イベントはZabbixに集中監視
– 性能監視/死活監視/ログ監視/プロセス監視/ネットワーク監視/Webサービス監視
– メール・パトランプにより通知
• 相互監視の仕組み

15. パトランプ
• パトランプは現行と同じシリーズの「警子ちゃん」を採用
• 複数パトランプを有効時間・深刻度別に細かく設定する必
要があった。Zabbixは柔軟に対応可能
オペレータは
24時間
警告も含む
株式会社アイエスエイ様HPより抜粋
PatLampA
メディアを複数用意すること
で対応可能
業務担当者は
9時～17時
警告は含まない
PatLampB

16. 相互監視の仕組み
• ２重の相互監視
– 他のサーバからのCRON死活チェック
– パトランプにPing死活監視機能を活用
• Zabbixがエラーになったあと、復旧するまで最低限確認
するべきポイント（重要ログの目検チェック等）をまと
めておく

17. 障害時イベントのロストを防止
• Zabbixが動作不能になった場合の対策
– アクティブエージェントはその間のデータをバッファ保持する
• Agentのバッファサイズを拡張
– /etc/zabbix/zabbix_agentd.conf “BufferSize”
– デフォルト100→65535（最大値）
– 1時間以上のダウンでも問題ないことを確認した
### Option: BufferSize
# Maximum number of values in a memory buffer. The agent will send
# all collected data to Zabbix Server or Proxy if the buffer is full.
#
# Mandatory: no
# Range: 2-65535
# Default:
# BufferSize=100
BufferSize=65535 →バッファサイズを最大に変更

18. 実際に使ってみて
• 最初から動く！
– デフォルトテンプレートが充実
– 各監視対象に対しての動作確認/疎通確認にすぐに着手できる

19. 動いてからが大変
• 現行システムの複雜な検知条件を一つ一つクエリに書い
て移植
– クエリテキストエリアが小さくて、一個一個手で書くのが大変
– 一括設定機能があれば楽なのに！！
• 監視条件は非常に柔軟かつ複雑な記述が可能
– 実際に使う人（運用オペレータ）が使いこなさなければ役に立
たない
– 早期に運用オペレータを巻き込み、習熟してもらう

20. 画面項目の入れ替え
• イベント画面で取得したメッセージが長くなると、オペ
レータが瞬時に把握したいステータスと深刻度が見えに
くい
• 項目入れ替え。PHPの定義修正で対応。 /var/www/html/zabbix/
events.php

21. PHPの修正
• 日付に「日」が入ってない・・・ /var/www/html/zabbix/inclu
de/locales/ja_jp.inc.php
修正例
---------------------
・「監視データ - ダッシュボード - 最新20件の障害」の日付
→'S_BLOCKS_LATEST_ISSUES_DATE_FORMAT'=>'Y年 M d日 H:i:s'
・「監視データ - トリガー」の日付
→'S_DATE_FORMAT_ymdhms'=>'Y年 M d日 H:i:s'
・「監視データ - 最新データ - ヒストリ - 値/最新500個の値」の日付
→'S_HISTORY_ITEM_DATE_FORMAT'=>'Y年 M d日 H:i:s'
・「監視データ - イベント - 画面上部(イベント履歴 ON)」の日付
→'S_EVENT_DATE_FORMAT'=>'Y年 M d日 H:i:s'
・「監視データ - イベント」の日付
→'S_EVENT_ACTION_TIME_FORMAT'=>'Y年 M d日 H:i:s'

22. レポート出力
• レポートはMySQLからデータを直接取得し、既存の書式に手で加
工することで対応した
• MySQLのオブジェクトをMySQLWorkbenchを使ってERDに
• チーティング参考
http://www.coreit.fr/index.php?option=com_content&view=section&layo
ut=blog&id=6&Itemid=9&lang=en

23. 追記：Zabbixでもトレンド情報は
平均値でサンプル感覚を圧縮され
ます。この記述は、「Zabbixでは
生のデータを使って加工できるの
レポート出力 でイイね！という意味合いで捉え
てください。特定の製品をDisる内
容ではありません。
• 他のツールと違い、性能情報はサマリ化せずに蓄積され
る
– あとからレポート加工する際に生データをそのまま加工できるので都
合が良い
• データが圧縮されないので、保存期間の検討は重要
– 今回はSQL抽出する運用と相まって、比較的短期間（90日分）のデー
タ保存とした
mysql -urhogeoot -pwdhogehoge zabbix -e "select concat(substr(from_unixtime(history.clock),1,15),'0') as 時間, hosts.host as 'ホスト名',(100 - min(history.value)) as 'CPU
使用率' from history,items,hosts where history.itemid = items.itemid and hosts.hostid=items.hostid and items.key_ = 'system.cpu.util[,idle,avg1]' and
from_unixtime(history.clock) like 'yyyy-MM-dd%' group by hosts.host,substr(from_unixtime(history.clock),1,15) order by
substr(from_unixtime(history.clock),1,15),hosts.host;" > /home/ad@@@@@@/cpu_yyyy-MM-dd.txt
※@@@@@@・・・自分のユーザーID yyyy-MM-dd・・・前日日付へ置換

24. チューニング
• Zabbix自体がキュー情報を可視化してくれるのでGood
• ボトルネックはZabbixよりもMySQLでした
• 今回はMySQLのバッファサイズの拡張のみでOK
– ４GB物理メモリに対して、2GBをBuffer割り当て
参考にな
ります

25. 外部アクション契機のキュー滞留
• テストで大量のイベントを発生させると、Zabbixの
キュー滞留が発生
– パトランプのRSHコマンドがキューまちとなってずーっと、パ
トランプが鳴り続ける状態に
– Zabbixのイベント処理は、紐付くアクションの完了を契機に処
理完了となると思われる
• RSHコマンド実行シェルスクリプトに、コマンドキュー
をチェックする処理を追加して回避
• 外部へのアクションは、大量イベント発生時の動きを気
にする必要がある

26. イベント重なる問題
• Zabbix1.8系では有名な問題・・らしい
– 負荷テストで認識。1秒以内に同じアイテムで複数イベント発生すると、
Zabbixで正確なメッセージが出力されない
• ログのトリガー条件を精緻化して大量追加。少なくとも重要なエ
ラーは検知を確実にできるようにして回避
– アイテム/トリガーを細かく設定するのに手間がかかったのは事実
cat /var/log/Batch/MSG/BTMSG_LOG_20110805 | grep "2011-08-05 11:04"
2011-08-05 11:04:16 ERROR hogehoge error
2011-08-05 11:04:16 INFO hogehoge.BatchExecuter.main(BatchExecuter.java:61) main - バッチ処理起動メソッド正常終了
ぼかしを入れる。

27. まとめ
• Zabbixはミッションクリティカルシステムに十分使えた
– 性能・機能・安定性は十分
– ソースコード/設定ファイル等可読性が高く、対応しやすい
– コストメリットは大きい【特に大規模・クラウド等】
• リスクを常に意識することは必要
– 情報収集
– 代替手段を考える
– ソースやデータ構造等自分で調べて手を動かすことも必要か
• Zabbixに限ったことではないですが・・
– Zabbixは高機能＆柔軟であるが、あくまでツール
• 何をどこまでZabbixにまかせるか、メリハリをつけた設計/実装は重要
– 運用者が持続的に運用できることがゴール
• 運用者と一緒に、設計/実装の段階から取り組む

28. Zabbix2.0！
•Zabbix1.8で、「残念」と思った所が確実に強
化されているという印象
•質実剛健な対応がステキです
• SNMPトラップ監視機能の追加
SNMPトラップ監視機能の追加
– 大規模/複雑なシステムの構築スピードが向上するか？
• パフォーマンスの改善
– パフォーマンス改善ネタはウェルカムですね
• 不明なイベントとトリガーの再設計
– 監視における可視性が高まりそう
• イベントのCSVエクスポート
イベントのCSVエクスポート
CSV
– 本番ログインとかSQLつかわずにレポート作成業務ができるかな～

29. Zabbix2.0！
•ミッションクリティカルシステム・大規模シス
テム向けにますます使えるになると思う
• データベースの完全性
– データベースのスキーマを大幅に改善し、一貫性、設定とヒス
トリデータのセキュリティを向上しました
• ヒストリデータにナノ秒を使用
– ヒストリデータにナノ秒単位で時間を保存することができます
1.8.xからマイグレーションを行った場合、このオプションはデ
フォルトで無効になります。新規でセットアップを行った場合
に有効になります。
orz 追記：Zabbix2.0に提供されるスクリプトを
使用すると、1.8.xからのアップデートが可
能となります。

30. ご清聴ありがとうございました
乗るしかない、
このビッグウェーブに・・・
Zabbix2.0期待してます
Zabbix2.0期待してます
期待