第4回 ZABBIX-JP勉強会に行ってきた
今日は全力でログ取ってみました。
ラトビアの生活と Zabbix 2.0
- ラトビアで生活
- Zabbix10周年
- 記念でZabbixカンファレンスを開いた
- あとはユーザ企業やパートナー企業
- テクニカルな発表が多かった
- 日本人のセッションが３セッション（自分含む）
- 割合的に考えて日本人多い
- 面白かったセッション
- Zabbix社長「デフォルトのテンプレートを使うな」（監視の間隔が短いからパフォーマンスが悪い）
- Scaling Zabbix
- Zabbix で監視したデータを Cassandra に保存するようにしてスケールさせるようにしている
- 今後 Zabbix は Cassandra と連携する予定（ここがスポンサー）
- Zabbix2.0 の話
- （ホテルの宿泊料：タダだった。コーヒーブレイク中のお金さえ払ってくれればいい）
- プレゼンテーション資料は Zabbix の HP にある
- Zabbix2.0
- ログイン画面のデザイン変わった
- 新機能、主に２つ
- ローレベルディスカバリ
- 大量のネットワークやファイルシステム機器があるものをどう監視するか
- １つ１つ設定していくのはしんどかった
- １つ１つやっていっても、後ろにはラスボスがいるかもしれない
- 自動探索したり自動設定ができるように
- 何らかの方法で機器を列挙して条件に一致する機器を追加する感じ
- Zabbix Java プロキシ
- nanosecondサポート
- 障害検知の時間が秒レベルだったので、同じ秒内に複数のログがあった場合、報告時のログがおかしくなることがあった。
- リモートコマンド
- インベントリの自動入力
- エージェント経由でホスト上のOS情報を自動的に取得しておく
- マルチホームホスト
- 異なるセグメント経由の監視をまとめられる
- スクリーンのテンプレート
- 今まではできなかった。
- マップの改善
- マップ自体よく知らないので分からない
- インターフェースの改善
- 最初に紹介したログイン画面のデザインもそう
- ローレベルディスカバリ
- Zabbix2.0 のリリーススケジュール
- Zabbix2.0 をリリースするために必要なバグトラックの数をZabbixで監視している(Blocking Issue)
- 年内か来年始めぐらいには出したい
- リリースポリシー
- 9ヶ月毎にリリースしましょう
- マイナーバージョンはバグ修正ぐらいで新機能は追加しない
- （マイナーバージョンというのは 2.0.1 とかの、３桁目の値）
- ZABBIX-JPコミュニティ
- ソースコードや翻訳データは Sourceforge から Github に移行する予定（どのように変更したのかが分かりにくいから）
- Zabbix.orgコミュニティ（英語）
金融系でZabbix1.8.5をガチで使ってみた
- 金融系の基幹システムで運用し始めた
- 自己紹介
- 吉田 仁（フューチャーアーキテクト社員）
- フューチャーアーキテクトとは
- いろんなことを最適化したり技術的なことを一括で請け負ってたり
- システム
- 某金融会社の最重要システム
- 秒間250取引
- 年間4000万取引
- 24時間365日運用
- 秒単位で損失が発生する
- 現行システムはできるだけ踏襲したい
- スケールアウト＆コストダウン
- 既存の特殊なログ運用をしているけどこれも踏襲したい
- Zabbix採用までの経緯
- 現行監視システム踏襲
- Zabbix総合監視がバイブルでした
- 方針
- 優先順位設定して、本当にZabbixが必要なところから手をつける
- グラフとかは既存のシステムのままにしておく
- できる限り早く実装してテストする
- 監視実績
- ログ監視の数が多かった
- テンプレートも多く作った
- 物理構成
- シングルサーバー（４コア4GBメモリ、Zabbix1.8.5）
- FC共有ストレージに入れることでハード故障時もすぐに切り替えられる
- 機能構成
- パトランプ
- 「警子ちゃん」を使った
- Zabbixは条件に応じて変えたりできた
- 障害時のイベントロスト
- Zabbixエージェントが動作不能になってもバッファを保持している
- 実際に使って
- デフォルトテンプレートが充実（機能確認が簡単にできたので楽だった）
- 動いてからが大変だった
- クエリを手で書くのが大変だった
- 一括設定があれば楽だったのに（力技で頑張った）
- 複雑な条件が設定できるので、その使い方を教えないといけなかった
- イベント画面の障害のエラーがすぐに分からないことがある
- 画面項目を入れ替えた
- 日付に「日」が入っていない
- 入れた
- レポート出力
- MySQL から直接取得して変換することに
- 性能情報はそのまま保存される
- 圧縮されないので保存期間の検討は重要
- チューニング
- まとめ
- ミッションクリティカルなシステムでも十分使えた
- 結局ツールなので、全体的な視野を忘れないようにしましょう
- 運用者と一緒にやっていくのが重要
- Zabbix2.0
- Zabbix1.8で残念だと思っていたところが確実に改善されていっている
- 乗るしかない、このビッグウェーブに・・・
- 質問
- Q:トリガーとか何段階にもやる複雑な条件で困っている、その辺の対処はどうしているか。
- A:我々は多くても２段階ぐらいまでしかやっていないので、その状況がよくわからないので後で詳しく聞かせて欲しい
- Q:アイテムの監視間隔の設定はいくつか
- A:１分から３分
- Q:オペレータが実際にZabbix触っての感想
- A:今までは国産のある有料の監視ツールを使っていたのだけど、フリーのツールの割にはちゃんと監視できている。オープンソースのプロダクトなのにちゃんと動いている。
エージェントとSNMPだけじゃないZabbix
- 自己紹介
- CROOZ という会社でインフラ
- Zabbix 200ノードぐらい試験導入
- Zabbixの監視
- ZabbixエージェントあるいはSNMP
- でもそれは必須ではない
- もっといろいろ監視しよう！
- ただしZabbixっぽく使う
- テンプレートを作ってホストを作る
- Zabbix内で完結
- IPアドレス以外でホストを区別
- サンプル１
- サンプル２
- サンプル３
- サービスレイヤの監視
- PV、平均レスポンスタイム、メール受信数、アプリケーションエラー件数、画像投稿数、分散ストレージの総容量等を統合して表示する
- Zabbix アグリゲートが使えそう
- ホスト名＝サービス
- 課題
- １ホスト上に複数のアプリインスタンスがある場合、１つのホストに同じテンプレートを複数適用できない
- まとめ
- 物理機器に縛られずに監視を考えてみよう
Zabbix のバグ・パッチ報告の手順
- Zabbixはオープンソース
- 実際どれぐらいフィードバックされてるの？ちゃんとフィードバックしよう
- ZabbixのBTS。ここでバグやパッチの報告を受け付けてます（ support.zabbix.com/browse/ZBX ）
- 英語だけ
- 次のバージョンで直されたりするとかの情報が書かれている
- モチベーション
- リリースノートの thanks to に載る
- 役に立つバグ・パッチ報告だと掲載される
- トップの thanks to は１０個ぐらい
- 日本人は３人ぐらい
- もっと増やしたい
- 確認点
- 報告時に必要な情報
- 再現手順と結果
- 期待する動作
- 自分の環境
- 既存のが無いか
- 最新でも確認
- できればtrunkのバージョン
- ワークアラウンド（これはオプショナル）
- 報告方法
- BTS(JIRA)にアカウント登録
- "ZABBIX BUGS AND ISSUES" に登録
- どうしても日本語にしたい場合は ZABBIX-JP に行ってくれれば翻訳とかする
- 報告後
- 待つ
- 高プライオリティだと早く回答が来る
- richlvからコメントがつくことが多い（richlvはIRCに24時間いる（ちゃんと人間らしい））
- 適切な報告で適切にコメントすれば対処してくれる（はず）
- パッチ投稿の手順
- コードを書く前にZabbix開発者と議論しておくこと
- 自明なバグの場合何も言わずにやっちゃうことも（反省）
- メンテナンスしやすいコードにすること
- 互換性へ配慮すること
- 古いバージョンではなくtrunk用の最新バージョンに対するパッチを作成すること
- "Zabbix Coding Standard"を参照する
- これが公開されるまでは空気を読んでパッチを書いていた
- ちゃんと標準ができたのでこれに従いましょう
- 半月ぐらいで倍ぐらいの量になってたりとかして更新されているので、書く前に毎回確認しよう
- 投稿する時に修正内容をちゃんと書くこと
- コードを書く前にZabbix開発者と議論しておくこと
- 何かあればZABBIX-JPやTwitterで聞いてください
- 質問
- Q:今まで面白かったのは何かありますか？
- A:プロクシがデータをためてしまう
- Q:バグかどうか微妙な内容はどうすればいいの？
- A:まずはフォーラムへ。あるいは寺島さんに相談
