2010-07-30 第2回 ZABBIX-JP勉強会のメモ
ATND http://atnd.org/events/6321
Twitter公式タグ #zabbix_jp
場所 ハロー貸会議室 新宿 D会議室
告知URL http://www.zabbix.jp/modules/news/article.php?storyid=185
※USTを視聴してメモ。USTが途中で終わっているので欠落があります。
■Zabbixのパフォーマンスチューニング&インストール時の注意点 寺島広大氏
アジェンダ
Zabbixのインストールとインストール時の注意点
とりあえず監視してみる
Zabbinxサーバのチューニングポイント
パフォーマンス測定
Zabbixのインストールとインストール時の注意点
動作環境
監視サーバ
Zabbixサーバ *
DBサーバ(MySQL PostgreSQL SQLite Oracle)
ウェブインタフェース *
監視対象
SNMPエージェント
Zabbixエージェント *
* パッケージインストール
Zabbixサーバのインストール
CentOS/RHEL
ZABBIX-JPのyumリポジトリ登録
yumで一発インストール
Debian/Ubuntu
aptで一発インストール
Zabbixサーバの設定
/etc/zabbix/zabbix_server.conf
後からハマらないためのMySQL設定
Zabbinxデータベース作成前に/etc/my.cnfを変更
文字化け回避のためのエンコード設定
default-character-set=utf8
デフォルトエンコードをutf8に設定
skip-character-set-client-handshake
SQLクライアントの設定に関わらずサーバ側のエンコード設定をしよう
データ保存ファイルの設定
innodb_file_per_table
単一のデータファイルの肥大化を防ぐために、テーブルごとにデータファイルを作成(DB作成後は変更不可)
MySQLの起動→DB作成
MySQLの起動
DBと接続用アカウントの作成
Zabbixデータベースの初期データのインポート
Zabbixの起動とウェブインタフェースの設定
Zabbixサーバの起動
Apacheの起動
ブラウザでウェブインタフェースにアクセス
ウェブインストーラの実行
インタフェースの設定ファイルを作成
インストーラ完了→ログイン画面
Zabbixサーバのインストール完了
Zabbixエージェントのインストール
CentOS/RHEL
ZABBIX-JPのyumリポジトリ登録
yumで一発インストール
Debian/Ubuntu
aptで一発インストール
Zabbixエージェントの設定&起動
/etc/zabbix/zabbix_agentd.conf
ZabbixサーバのIPアドレス
監視対象として登録する時のホスト命
ListenするIPアドレス
Zabbixエージェントの起動
Zabbixエージェントの起動
Zabbixエージェント側に監視設定は不要
監視設定はZabbixサーバで集中管理
Zabbixエージェントは起動しておくだけ
Zabbixのインストールのまとめ
MySQLの設定がキモ!
ソースからコンパイルする場合はZabbixの詳細を理解しておかないといけないがrpmなら簡単にインストール
ZABBIX-JPのrpmなら日本語利用に当たって必要な設定があらかじめ設定済み。インストール後すぐ使える
Debian系のパッケージは日本語関連の設定が入っていないため、インストール語にPHPの設定を変更する必要あり
ZABBIX-JP RPMを使ったインストール手順
http://www.zabbix.jp/documents
ZABBIXインストレーションガイド
Configureでインストールする手順
初期設定とカスタマイズ
とりあえず監視してみる
テスト環境
2つの監視対象(Zabbixエージェント)を複数登録して監視
ネットワーク的に遅延があまりない環境
ハブで接続
利用するテンプレート
ZABBIX-JPのTemplate_OS_Linuxを利用
ホストの登録
同じ監視対象を複数ホストとして登録
確認ポイント(1) - Zabbixサーバの負荷
Zabbixサーバにもエージェントをインストール、スクリーンを作成して負荷状況を確認
確認ポイント(2) - キュー
「管理」→「キュー」画面で監視の遅延有無を確認
確認ポイント(3) - Zabbixサーバの状態
「レポート」→「Zabbixサーバの状態」画面でホスト、アイテムの登録数を確認
確認ポイント(4) - 監視データ
「監視データ」→「最新データ」画面でヒストリを表示して監視データに遅延がないかを確認
ホストの追加
サーバを追加するとアイテム数が急増するため、一時的にZabbixサーバの負荷が上がる
パフォーマンスチューニング時、MySQLのチューニングにより、I/O性能は格段に上がる。(innodb_buffer_pool_sizeやinnodb_log_file_size)
innodb_flush_method=O_DIRECT もオススメ(OSとMySQLのダブルバッファをしなくなる設定。メモリの使用率下がる。割とセオリーらしい)
→SQLのチューニングが負荷軽減ではないですが、zabbix稼動時にMYSQLのチューニングを行っておかないと、稼動時に設定変更できないものもあります
Zabbinxサーバのチューニングポイント
Zabbixサーバのプロセス
プロセスがやたらある→役割ごとに処理を担当しているプロセスが起動している
Rollerプロセスの役割
Zabbixエージェント、SNMPエージェント、シンプルチェックのポート監視を行なう専用のプロセス
Pingerプロセスの役割
Zabbixエージェント、SNMPエージェント、シンプルチェックのポート監視を行なう専用のプロセス
Zabbixサーバの設定パラメータ(1)
監視プロセス数の調整
StartRollers=5
Zabbixエージェント、SNMPエージェント、シンプルチェックを利用した監視用のプロセスの起動数
StartPingers=1
Ping監視用のプロセス起動数
Zabbix1.6
StartDBSyncers=1
DB書き込み前にメモリキャッシュを行なう専用のプロセスDBSyncersを起動。デフォルト無効
1.8でなくなった→1.8ではDBにアクセスプロセスが独立するなどパフォーマンスが改善されたため
Zabbix1.8
CacheSize=8M
キャッシュサイズ
CacheUpdateFrequency=60
Ping監視用プロセス起動数
HistoryCacheSize=8M
ヒストリデータのキャッシュサイズ
TrendCacheSize=4M
トレンドデータのメモリキャッシュサイズ
HistoryTextCacheSize=16M
テキスト形式のヒストリデータのキャッシュサイズ
InnoDBのメモリ関連のパラメータ
innodb_buffer_pool_size
InnoDBデータのメモリキャッシュサイズ(デフォルト8M)
デフォルト値が少なすぎる。物理メモリの8割まで割り当てOKとマニュアルに記載あり
ただし、OS,http.Zabbixサーバ用のメモリは残しておくこと
InnoDBのログファイル関連のパラメータ
innodb_log_file_size
更新ログを記録するためのファイルサイズ(デフォルト5M)
innodb_log_files_in_group
ログファイルの作成数(デフォルト2)
ログファイルはMySQLのアプリケーションログではなく、DB書き込み前にデータを追記形式で保存しておくところ
ログファイル実体は/var/lib/mysql/lib_logfile
ログファイルの設定を変更したら必ず、MySQL停止→lib_logfile削除→MySQL起動 を行なうこと
ログファイルは64M~128M×2があれば十分。それ以上でもあまり効果がない
MySQL InnoDBのチューニングは『実践ハイパフォーマンスMySQL 第2版』がオススメ
その他のMySQLのチューニングポイント
InnoDBはCPUでスケールしない
少なくともCentOS5/RHEL5ではスケールしない
CPUはコア数より速度を優先するほうが良い
HyperThreadingは絶対オフ(過去に問題が出たことがあり→パフォーマンスが上がらない)
Googleパッチ、InnoDBプラグイン
InnoDBまわりの改善が多数
CPU数に応じてスケールするようになっている
監視プロセス数の調整
StartPollers 5→20
StartPingers 1→5
して、Zabbixを再起動
キューに溜まってなかったのが溜まるようになった
Pollerプロセス、Pingerプロセスがそれぞれデータベースをオープンすることにより、不必要に起動数を増やすとパフォーマンスが落ちる
1.8では処理が変更され、パフォーマンスが向上している。
StartPollers 20→5
StartPingers 5→1
StartDBSyncers 0→1
して、Zabbixを再起動
ロードアベレージが下がった
チューニングまとめ
MySQLのチューニング
innnodb_buffer_pool_sizeとinnnodb_log_file_sizeは必ず修正したほうが良い
I/Oパフォーマンスが向上する
Zaqbbixサーバのプロセス
キューに溜まってなければStartPollers、StartPingersの値を変えても効果なし。むしろ逆効果の場合も
StartDBSyncersの変更は一定の効果あり
※ここでUSTが切れてます
■メールや電話による障害通知と、そのカスタマイズについて 鈴木崇文氏
USTがない…
TwitterTLから拾った内容をコピペしておきます。
・zabbixの障害通知をメールだけでなく、SMSやら、ついったーやら、電話までかけるとな
・メールで電話してくれるサービスもあるらしい http://www.speedcall.jp/
・電話通知の場合はスクリプトを使う。通知用コマンドを作ってZabbix から実行させる
・Skype4Pyを利用
メールサーバが死ぬとメール通知ができないからTwitterで…ということですが、外形監視(サーバの設置場所でない別の所から監視)をすれば?と思った。
当方では、サーバ設置場所以外に会社の2拠点から監視しています。
pingとhttp、DNSくらいですが、これでとりあえず間に合ってます。
警報の通知先は、クローズドなGoogleGroup宛にしておいて、関係者にこのGoogleGroupを登録してもらっています。
(GoogleGroupに通知がいくと、各関係者が通知先にした携帯等に配信される仕組み)
2拠点からなので、1拠点だけだと「その拠点のネットがトラブってる?」という疑いが発生しますが、2拠点両方からだとサーバの不具合が濃厚になるので。
これはNagiosでやってます。サーバ移行で台数が増えるのでZabbixにしようと考えています。
2 件のコメント:
はじめまして。
メモの書き起こしありがとうございます。
一点だけ、「メールサーバが死ぬとメール通知ができないからTwitterで」というのは障害通知を行う方法を多重化することを考えてみたらどうでしょうということだと思います。
例えば、t.maeさんの場合でいえば、外形監視を行ったとしても最終的に通知をする方法がGoogleGroupだけだった場合、GoogleGroupのシステムに障害が発生していたりメンテナンスが行われていたりすると障害の通知が行われなかったり遅れてしまうことになってしまいませんか?
とはいってもtwitterでは「くじら」にやられてしまうかもしれませんが。 (^_^;)
コメントありがとうございます。
確かにGoogleGroupだけでは、これに何かあればマズイですね(今まで大丈夫とはいえ、これからも大丈夫とは限りませんし)
GoogleGroupに流す警報と同じ者をSMSにも流すようにしてみようと思います。
Twitterはくじら浮上が多すぎるのでアレですけど^^;
コメントを投稿