金融系シスで 金融系シスで 金融系シスで 金融系シスで Zabbix1.8 Zabbix1.8 Zabbix1.8 Zabbix1.8をガで使ってみた をガで使ってみた をガで使ってみた をガで使ってみた ~Zabbix2.0に期待することも語りたい ~ 2011年10月22日 第4回Zabbix勉強 吉田 (Future Architect) @yossyh
May 28, 2015
金融系システムで金融系システムで金融系システムで金融系システムで
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 | | |
|::::::::::::: l 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で
• 最初に優先順序を設定
監視実績
対象ホスト 114台
サーバ 36 SAN関連 6
NAS関連 1 NW機器 42
Tape装置 2 VIP 21
SNMPtraps 1 ZAP-CAT 5
アイテム種別数 324種
性能監視 95 ログ監視 216
SNMP監視 8 PING監視 4
死活監視 1
アイテム数 2,133個
トリガー数 1,607個
テンプレート数 29個 カテゴリ別にテンプレートを
作成。設定効率化に寄与
ユーザ数 10ユーザ
監視項目/秒 30件/秒
アクション保存期間 7日
イベント保存期間 90日
物理構成
•シングルサーバ(コールドスタンバイ構成)
– Zabbixは設定情報もすべてMySQLに入っている
•ハードウェア故障時にも短時間で切り替え可能
FC共有ストレージ
20GB
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より抜粋
相互監視の仕組み
•2重の相互監視
– 他のサーバからの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
– 4GB物理メモリに対して、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期待期待期待期待してますしてますしてますしてます