金融系システムで金融系システムで金融系システムで金融系システムで

Zabbix1.8Zabbix1.8Zabbix1.8Zabbix1.8をガチで使ってみたをガチで使ってみたをガチで使ってみたをガチで使ってみた

～Zabbix2.0に期待することも語りたい ～

2011年10月22日 第4回Zabbix勉強会

吉田 仁（Future Architect)

@yossyh

本日の目的

•金融機関の重要基幹システムに、Zabbix1.8.5

（コミュニティ版）を導入し、無事運用開始し

ました。

•そのときのあれこれを語ります。

•ご経験済みの方は共感を、これからの人には成

功へのヒントをお伝えできれば幸いです。

Thank you

•ATNDにて。

@kodai74:@yossyh

こんにちは。Zabbix-

JPの勉強会ですが、ぜ

ひ発表お願いしたいで

す。

＿＿＿_

／:::::::::: u＼

／:::::::::⌒ 三. ⌒＼ えぇぇぇ、寺島さん本人？

／:::::::::: （ ○）三（○）＼

|::::::::::::::::⌒（__人__）⌒ | ＿＿＿＿＿＿＿_

＼:::::::::: ｀ ⌒´ ,／ .| | ...|

ノ::::::::::u ＼ | | |

／::::::::::::::::: u | | |

|::::::::::::: ｌ u | | |

ヽ:::::::::::: -一ー_~､⌒)^),-､ | |_＿＿＿＿＿＿__.|

ヽ::::::::＿＿＿,ノγ⌒ヽ)ニニ-￣ | | |

吉田 仁

フューチャーアーキテクト株式会社

Twitter @yossyh

太田 和哉

フューチャーアーキテクト株式会社

村田 直紀

フューチャーアーキテクト株式会社

自己紹介

自己紹介

• フューチャーアーキテクト株式会社

– 旧フューチャーシステムコンサルティング株式会社

• 中立／オープン

– 様々な監視製品を駆使

• 最適化

– 要件/環境/コスト等の全要素において最善を尽くす

• 技術志向

– コンサルティング～設計～実装～運用まで一貫対応

– 最新の技術は適切なタイミングで活用

•某金融会社の最重要システム

– 既存システムのHW更改＆DC移設

– 業務量拡大につきサーバ処理性能拡張

– 秒間 250取引

– 年間 4000万取引

– 24時間365日運用

•エラーは取引の滞りを意味する。フォローが必要

•障害発生→秒単位で損失/迷惑が発生する

システム概要

ミッションクリティカルシステムそのもの

システムの特徴

リプレース

•現行システムの運用はそのまま踏襲

スケールアウト＆コストダウン

•性能拡張のため、台数が増える

•でもランニングコストは増やしたくない

特殊なログ運用

•取引のエラーを確実に拾うため、大量のログ監視

•長年の運用経験から得た、複雑かつ多数の監視条件がある

•限りあるお金はメリハリをかけて使いたい

– 安全性や性能等、必要なところには十分お金を

– 工夫できるところは積極的にコスト削減したい

•弊社内部システムで導入・運用経験あり

•お客様の別システムでも導入・運用経験あり

• 日本語情報の増加 / クラウド等への意識

•何かあったときの備えはある

– Nagiosとか、自分で機能カバーするとか・・・俺らがんばれ。

Zabbix採用までの経緯

目標設定

タイミング

リスクヘッジ

Zabbix導入決定のまえに

• 現行監視システムでできることは、Zabbixではできないとね

パトランプ対応

監視条件設定

Windows対応

vmware対応

大量ログ対応

Zabbix障害対応

金融系では相変わらず大好き

排他関係/依存関係とか

vCenter orz。

Agent側でフィルタ必須

エラーの見過ごしが許されない

参考にさせていただいた情報

• Zabbix-JPフォーラム

• @IT：Linux Square Zabbixのインストール（青山さん）

• http://www.atmarkit.co.jp/flinux/rensai/zabbix01/zabbix01a.html

BIBLE

!!

設計/実装時の方針

• Zabbixによるワンストップ監視

を実現する

– イベントは確実に拾える

– イベントは確実に通知する

• 障害対策

– リカバリ迅速化

【番外】早期構築

– 構築・テスト時点でZabbix

を有効活用

Zabbix必達！！ 他で対応

• トレンド分析・レポート作成

– 既存運用で定型フォーマッ

トでの状況分析を行ってい

る（EXCEL活用）

– Zabbixのデータを使うが、

グラフ描画はEXCELで

• 最初に優先順序を設定

監視実績

対象ホスト １１４台

サーバ 36 SAN関連 6

NAS関連 1 NW機器 42

Tape装置 2 VIP 21

SNMPtraps 1 ZAP-CAT 5

アイテム種別数 ３２４種

性能監視 95 ログ監視 216

SNMP監視 8 PING監視 4

死活監視 1

アイテム数 ２,１３３個

トリガー数 １,６０７個

テンプレート数 ２９個 カテゴリ別にテンプレートを

作成。設定効率化に寄与

ユーザ数 １０ユーザ

監視項目/秒 ３０件/秒

アクション保存期間 ７日

イベント保存期間 ９０日

物理構成

•シングルサーバ（コールドスタンバイ構成）

– Zabbixは設定情報もすべてMySQLに入っている

•ハードウェア故障時にも短時間で切り替え可能

FC共有ストレージ

２０GB

DELL PowerEdge R610

Xeon 5500×1（4Core）

4GB Memory

RHEL5.4（X86-64）

Zabbix 1.8.5

ACTIVE

STANDBY

↓

ACTIVEダウン時に、

オペレータがリモートパワーON

機能構成

•イベントはZabbixに集中監視

– 性能監視/死活監視/ログ監視/プロセス監視/ネットワーク監視/Webサービス監視

– メール・パトランプにより通知

• 相互監視の仕組み

パトランプ

• パトランプは現行と同じシリーズの「警子ちゃん」を採用

• 複数パトランプを有効時間・深刻度別に細かく設定する必

要があった。Zabbixは柔軟に対応可能

オペレータは

24時間

警告も含む

業務担当者は

9時～17時

警告は含まない

メディアを複数用意すること

で対応可能

PatLampA

PatLampB

株式会社アイエスエイ様HPより抜粋

相互監視の仕組み

•２重の相互監視

– 他のサーバからのCRON死活チェック

– パトランプにPing死活監視機能を活用

•Zabbixがエラーになったあと、復旧するまで最低限確認

するべきポイント（重要ログの目検チェック等）をまと

めておく

障害時イベントのロストを防止

•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 →バッファサイズを最大に変更

実際に使ってみて

• 最初から動く！

– デフォルトテンプレートが充実

– 各監視対象に対しての動作確認/疎通確認にすぐに着手できる

動いてからが大変

• 現行システムの複雜な検知条件を一つ一つクエリに書い

て移植

– クエリテキストエリアが小さくて、一個一個手で書くのが大変

– 一括設定機能があれば楽なのに！！

• 監視条件は非常に柔軟かつ複雑な記述が可能

– 実際に使う人（運用オペレータ）が使いこなさなければ役に立

たない

– 早期に運用オペレータを巻き込み、習熟してもらう

画面項目の入れ替え

• イベント画面で取得したメッセージが長くなると、オペ

レータが瞬時に把握したいステータスと深刻度が見えに

くい

• 項目入れ替え。PHPの定義修正で対応。 /var/www/html/zabbix/

events.php

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'

レポート出力

• レポートはMySQLからデータを直接取得し、既存の書式に手で加

工することで対応した

• MySQLのオブジェクトをMySQLWorkbenchを使ってERDに

• チーティング参考

http://www.coreit.fr/index.php?option=com_content&view=section&layo

ut=blog&id=6&Itemid=9&lang=en

レポート出力

•他のツールと違い、性能情報はサマリ化せずに蓄積され

る

– あとからレポート加工する際に生データをそのまま加工できるので都

合が良い

•データが圧縮されないので、保存期間の検討は重要

– 今回は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・・・前日日付へ置換

追記：Zabbixでもトレンド情報は

平均値でサンプル感覚を圧縮され

ます。この記述は、「Zabbixでは

生のデータを使って加工できるの

でイイね！という意味合いで捉え

てください。特定の製品をDisる内

容ではありません。

チューニング

•Zabbix自体がキュー情報を可視化してくれるのでGood

•ボトルネックはZabbixよりもMySQLでした

•今回はMySQLのバッファサイズの拡張のみでOK

– ４GB物理メモリに対して、2GBをBuffer割り当て

参考にな

ります

外部アクション契機のキュー滞留

•テストで大量のイベントを発生させると、Zabbixの

キュー滞留が発生

– パトランプのRSHコマンドがキューまちとなってずーっと、パ

トランプが鳴り続ける状態に

– Zabbixのイベント処理は、紐付くアクションの完了を契機に処

理完了となると思われる

•RSHコマンド実行シェルスクリプトに、コマンドキュー

をチェックする処理を追加して回避

•外部へのアクションは、大量イベント発生時の動きを気

にする必要がある

イベント重なる問題

• 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 - バッチ処理起動メソッド正常終了

まとめ

•Zabbixはミッションクリティカルシステムに十分使えた

– 性能・機能・安定性は十分

– ソースコード/設定ファイル等可読性が高く、対応しやすい

– コストメリットは大きい【特に大規模・クラウド等】

•リスクを常に意識することは必要

– 情報収集

– 代替手段を考える

– ソースやデータ構造等自分で調べて手を動かすことも必要か

•Zabbixに限ったことではないですが・・

– Zabbixは高機能＆柔軟であるが、あくまでツール

•何をどこまでZabbixにまかせるか、メリハリをつけた設計/実装は重要

– 運用者が持続的に運用できることがゴール

•運用者と一緒に、設計/実装の段階から取り組む

Zabbix2.0！

•Zabbix1.8で、「残念」と思った所が確実に強

化されているという印象

•質実剛健な対応がステキです

• SNMPSNMPSNMPSNMPトラップ監視機能の追加トラップ監視機能の追加トラップ監視機能の追加トラップ監視機能の追加

– 大規模/複雑なシステムの構築スピードが向上するか？

• パフォーマンスの改善パフォーマンスの改善パフォーマンスの改善パフォーマンスの改善

– パフォーマンス改善ネタはウェルカムですね

• 不明なイベントとトリガーの再設計不明なイベントとトリガーの再設計不明なイベントとトリガーの再設計不明なイベントとトリガーの再設計

– 監視における可視性が高まりそう

• イベントのイベントのイベントのイベントのCSVCSVCSVCSVエクスポートエクスポートエクスポートエクスポート

– 本番ログインとかSQLつかわずにレポート作成業務ができるかな～

Zabbix2.0！

•ミッションクリティカルシステム・大規模シス

テム向けにますます使えるになると思う

•データベースの完全性データベースの完全性データベースの完全性データベースの完全性

– データベースのスキーマを大幅に改善し、一貫性、設定とヒス

トリデータのセキュリティを向上しました

•ヒストリデータにナノ秒を使用ヒストリデータにナノ秒を使用ヒストリデータにナノ秒を使用ヒストリデータにナノ秒を使用

– ヒストリデータにナノ秒単位で時間を保存することができます

1.8.xからマイグレーションを行った場合、このオプションはデ

フォルトで無効になります。新規でセットアップを行った場合

に有効になります。

orz

追記：Zabbix2.0に提供されるスクリプトを

使用すると、1.8.xからのアップデートが可

能となります。

ご清聴ありがとうございました

乗るしかない、乗るしかない、乗るしかない、乗るしかない、

このビッグウェーブに・・・このビッグウェーブに・・・このビッグウェーブに・・・このビッグウェーブに・・・

Zabbix2.0Zabbix2.0Zabbix2.0Zabbix2.0期待期待期待期待してますしてますしてますしてます