Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Zabbix-jp study #4 20111020 session2

6,294 views

Published on

第4回ZABBIX-JP勉強会 発表資料(Session2)
「金融系システムでZabbix1.8をガチで使ってみた ~Zabbix2.0に期待することも語りたい」
発表者:吉田 仁(フューチャーアーキテクト株式会社)

2011年10月22日 公開

Published in: Technology

Zabbix-jp study #4 20111020 session2

  1. 1. 金融系システムでZabbix1.8をガチで使ってみたZabbix1.8をガチで使ってみた~Zabbix2.0に期待することも語りたい ~ 2011年10月22日 第4回Zabbix勉強会 吉田 仁(Future Architect) @yossyh
  2. 2. 本日の目的•金融機関の重要基幹システムに、Zabbix1.8.5 (コミュニティ版)を導入し、無事運用開始し ました。•そのときのあれこれを語ります。•ご経験済みの方は共感を、これからの人には成 功へのヒントをお伝えできれば幸いです。
  3. 3. Thank you•ATNDにて。 ____ /:::::::::: u\ /:::::::::⌒ 三. ⌒\ えぇぇぇ、寺島さん本人? /:::::::::: ( ○)三(○)\ @kodai74:@yossyh |::::::::::::::::⌒(__人__)⌒ | ________ \:::::::::: ` ⌒´ ,/ .| | ...| こんにちは。Zabbix- ノ::::::::::u \ || | /::::::::::::::::: u || | JPの勉強会ですが、ぜ|::::::::::::: l u || |ヽ:::::::::::: -一ー_~、⌒)^),-、 | |_________.| ひ発表お願いしたいで ヽ::::::::___,ノγ⌒ヽ)ニニ- ̄ || | す。
  4. 4. 自己紹介吉田 仁 フューチャーアーキテクト株式会社 Twitter @yossyh太田 和哉 フューチャーアーキテクト株式会社村田 直紀 フューチャーアーキテクト株式会社
  5. 5. 自己紹介• フューチャーアーキテクト株式会社 – 旧フューチャーシステムコンサルティング株式会社• 中立/オープン – 様々な監視製品を駆使• 最適化 – 要件/環境/コスト等の全要素において最善を尽くす• 技術志向 – コンサルティング~設計~実装~運用まで一貫対応 – 最新の技術は適切なタイミングで活用
  6. 6. システム概要•某金融会社の最重要システム – 既存システムのHW更改&DC移設 – 業務量拡大につきサーバ処理性能拡張 – 秒間 250取引 – 年間 4000万取引 – 24時間365日運用 •エラーは取引の滞りを意味する。フォローが必要 •障害発生→秒単位で損失/迷惑が発生する ミッションクリティカルシステムそのもの
  7. 7. システムの特徴リプレース• 現行システムの運用はそのまま踏襲スケールアウト&コストダウン• 性能拡張のため、台数が増える• でもランニングコストは増やしたくない特殊なログ運用• 取引のエラーを確実に拾うため、大量のログ監視• 長年の運用経験から得た、複雑かつ多数の監視条件がある
  8. 8. Zabbix採用までの経緯 目標設定• 限りあるお金はメリハリをかけて使いたい – 安全性や性能等、必要なところには十分お金を – 工夫できるところは積極的にコスト削減したいタイミング• 弊社内部システムで導入・運用経験あり• お客様の別システムでも導入・運用経験あり• 日本語情報の増加 / クラウド等への意識 リスクヘッジ• 何かあったときの備えはある – Nagiosとか、自分で機能カバーするとか・・・俺らがんばれ。
  9. 9. Zabbix導入決定のまえに• 現行監視システムでできることは、Zabbixではできないとね パトランプ対応 金融系では相変わらず大好き 監視条件設定 排他関係/依存関係とか Windows対応 vCenter orz。 vmware対応 大量ログ対応 Agent側でフィルタ必須 Zabbix障害対応 エラーの見過ごしが許されない
  10. 10. 参考にさせていただいた情報 BIBLE !!• Zabbix-JPフォーラム• @IT:Linux Square Zabbixのインストール(青山さん)• http://www.atmarkit.co.jp/flinux/rensai/zabbix01/zabbix01a.html
  11. 11. 設計/実装時の方針• 最初に優先順序を設定 Zabbix必達!! 他で対応• Zabbixによるワンストップ監視 • トレンド分析・レポート作成 を実現する – 既存運用で定型フォーマッ – イベントは確実に拾える トでの状況分析を行ってい – イベントは確実に通知する る(EXCEL活用)• 障害対策 – Zabbixのデータを使うが、 – リカバリ迅速化 グラフ描画はEXCELで【番外】早期構築 – 構築・テスト時点でZabbix を有効活用
  12. 12. 監視実績 サーバ 36 SAN関連 6対象ホスト 114台 NAS関連 1 NW機器 42 Tape装置 2 VIP 21 SNMPtraps 1 ZAP-CAT 5 性能監視 95 ログ監視 216アイテム種別数 324種 SNMP監視 8 PING監視 4 死活監視 1アイテム数 2,133個トリガー数 1,607個テンプレート数 29個 カテゴリ別にテンプレートを 作成。設定効率化に寄与ユーザ数 10ユーザ監視項目/秒 30件/秒アクション保存期間 7日イベント保存期間 90日
  13. 13. 物理構成• シングルサーバ(コールドスタンバイ構成) – Zabbixは設定情報もすべてMySQLに入っている• ハードウェア故障時にも短時間で切り替え可能 DELL PowerEdge R610 ACTIVE Xeon 5500×1(4Core) 4GB Memory RHEL5.4(X86-64) Zabbix 1.8.5 FC共有ストレージ 20GB STANDBY ↓ ACTIVEダウン時に、 オペレータがリモートパワーON
  14. 14. 機能構成• イベントはZabbixに集中監視 – 性能監視/死活監視/ログ監視/プロセス監視/ネットワーク監視/Webサービス監視 – メール・パトランプにより通知• 相互監視の仕組み
  15. 15. パトランプ• パトランプは現行と同じシリーズの「警子ちゃん」を採用• 複数パトランプを有効時間・深刻度別に細かく設定する必 要があった。Zabbixは柔軟に対応可能 オペレータは 24時間 警告も含む 株式会社アイエスエイ様HPより抜粋 PatLampAメディアを複数用意することで対応可能 業務担当者は 9時~17時 警告は含まない PatLampB
  16. 16. 相互監視の仕組み• 2重の相互監視 – 他のサーバからのCRON死活チェック – パトランプにPing死活監視機能を活用• Zabbixがエラーになったあと、復旧するまで最低限確認 するべきポイント(重要ログの目検チェック等)をまと めておく
  17. 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. 18. 実際に使ってみて• 最初から動く! – デフォルトテンプレートが充実 – 各監視対象に対しての動作確認/疎通確認にすぐに着手できる
  19. 19. 動いてからが大変• 現行システムの複雜な検知条件を一つ一つクエリに書い て移植 – クエリテキストエリアが小さくて、一個一個手で書くのが大変 – 一括設定機能があれば楽なのに!!• 監視条件は非常に柔軟かつ複雑な記述が可能 – 実際に使う人(運用オペレータ)が使いこなさなければ役に立 たない – 早期に運用オペレータを巻き込み、習熟してもらう
  20. 20. 画面項目の入れ替え• イベント画面で取得したメッセージが長くなると、オペ レータが瞬時に把握したいステータスと深刻度が見えに くい• 項目入れ替え。PHPの定義修正で対応。 /var/www/html/zabbix/ events.php
  21. 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. 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. 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] andfrom_unixtime(history.clock) like yyyy-MM-dd% group by hosts.host,substr(from_unixtime(history.clock),1,15) order bysubstr(from_unixtime(history.clock),1,15),hosts.host;" > /home/ad@@@@@@/cpu_yyyy-MM-dd.txt※@@@@@@・・・自分のユーザーID yyyy-MM-dd・・・前日日付へ置換
  24. 24. チューニング• Zabbix自体がキュー情報を可視化してくれるのでGood• ボトルネックはZabbixよりもMySQLでした• 今回はMySQLのバッファサイズの拡張のみでOK – 4GB物理メモリに対して、2GBをBuffer割り当て 参考にな ります
  25. 25. 外部アクション契機のキュー滞留• テストで大量のイベントを発生させると、Zabbixの キュー滞留が発生 – パトランプのRSHコマンドがキューまちとなってずーっと、パ トランプが鳴り続ける状態に – Zabbixのイベント処理は、紐付くアクションの完了を契機に処 理完了となると思われる• RSHコマンド実行シェルスクリプトに、コマンドキュー をチェックする処理を追加して回避• 外部へのアクションは、大量イベント発生時の動きを気 にする必要がある
  26. 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 error2011-08-05 11:04:16 INFO hogehoge.BatchExecuter.main(BatchExecuter.java:61) main - バッチ処理起動メソッド正常終了 ぼかしを入れる。
  27. 27. まとめ• Zabbixはミッションクリティカルシステムに十分使えた – 性能・機能・安定性は十分 – ソースコード/設定ファイル等可読性が高く、対応しやすい – コストメリットは大きい【特に大規模・クラウド等】• リスクを常に意識することは必要 – 情報収集 – 代替手段を考える – ソースやデータ構造等自分で調べて手を動かすことも必要か• Zabbixに限ったことではないですが・・ – Zabbixは高機能&柔軟であるが、あくまでツール • 何をどこまでZabbixにまかせるか、メリハリをつけた設計/実装は重要 – 運用者が持続的に運用できることがゴール • 運用者と一緒に、設計/実装の段階から取り組む
  28. 28. Zabbix2.0!•Zabbix1.8で、「残念」と思った所が確実に強 化されているという印象•質実剛健な対応がステキです• SNMPトラップ監視機能の追加 SNMPトラップ監視機能の追加 – 大規模/複雑なシステムの構築スピードが向上するか?• パフォーマンスの改善 – パフォーマンス改善ネタはウェルカムですね• 不明なイベントとトリガーの再設計 – 監視における可視性が高まりそう• イベントのCSVエクスポート イベントのCSVエクスポート CSV – 本番ログインとかSQLつかわずにレポート作成業務ができるかな~
  29. 29. Zabbix2.0!•ミッションクリティカルシステム・大規模シス テム向けにますます使えるになると思う• データベースの完全性 – データベースのスキーマを大幅に改善し、一貫性、設定とヒス トリデータのセキュリティを向上しました• ヒストリデータにナノ秒を使用 – ヒストリデータにナノ秒単位で時間を保存することができます 1.8.xからマイグレーションを行った場合、このオプションはデ フォルトで無効になります。新規でセットアップを行った場合 に有効になります。 orz 追記:Zabbix2.0に提供されるスクリプトを 使用すると、1.8.xからのアップデートが可 能となります。
  30. 30. ご清聴ありがとうございました 乗るしかない、このビッグウェーブに・・・ Zabbix2.0期待してます Zabbix2.0期待してます 期待

×