More Related Content Similar to Gangliaはじめました (20) 2. ■自⼰紹介
名前：
yuzorock（ユーゾロック） http://twitter.com/yuzorock
仕事：
某インターネットポータルサイトのインフラ（サーバ）エンジニア
今⽇の話：
パフォーマンス（リソース）監視とは何かという話と、そのツールでGangliaと
いうのがあっておすすめですよという話。
おまけ：
初⼼者にも優しいインフラ勉強会なのでGangliaの細かい話はないです。
細かい話は後ろにつけましたので、質問あればtwitterで@yuzorockして下さい。
できればハッシュタグ#qpstudyつけて。
⽇本語の情報が少ないので使っている⽅と⾊々と情報交換したいです。
3. ■監視とは
インフラエンジニアが⾏う監視には大きく分けて以下の2種類があると思います。
死活監視：
サーバやNW機器がpingやsshに正常に応答するかや提供しているサービス（http
等）が正常に応答を返しているかを監視する。
Nagios、OpenView等のツールが有名。
パフォーマンス（リソース）監視：
サーバやNW機器の負荷状態（ロードアベレージ）、リソース消費量（CPU、
メモリ、HDD等）等の経過を時系列で監視する。
Cacti等のツールが有名。Gangliaはこっち。
※両⽅の監視を同時に⾏うツールもあるが今回は触れない。
5. ■RRDtoolを使ったデータ収集からグラフ化して表⽰までの流れ
収集 RRDへ登録 グラフ化 表⽰
⼀般的なRRDtoolの範疇
収集：
中央の監視サーバにクライアントであるサーバやNW機器の情報を集めてくる
フェーズ。基本的にはツールの機能として提供される。
RRDへ登録,グラフ化：
RRDtoolにて機能（コマンド）が提供されているが、複雑（煩雑）な部分があ
るためツールでラップされていて意識しなくてもいいことが多い。
表⽰：
⼀般的にはWebページとして表⽰され、ツールによって提供される。
ユーザ管理機能、認証機能、グラフの配置、クライアントの登録等の機能が提供
される。所謂⾒た目の部分なのでこれが自分達の目的に合っているかがツール選
定の大きなポイントとなる。RRDtoolだけ使って自作する会社（⼈）も多い。
7. ■⾒てどうするか？何のために⾒るか？
リソースの消費状況を⾒て傾向把握や設備増設等の計画を⽴てるのに活用します。
トラブルシューティング時の原因調査にも活用したりします。
・最近では気にかけないといけないリソースの1つに電⼒使用量（w）が追加され
ているように感じます。これはデータセンターにおけるラック設置の⽀配的要
素になってきているからです。最近のCPU（マザーボード？）には電⼒使用量
に応じてCPU速度を変化させることが出来るものがあり、そのようなサーバで
あれば電⼒使用量の値を取ることが出来ると思います。
・リソースの使用量だけではなく、サーバが持ってるビジネスに関する数値も取
るといいと思います。会員数、売上げ、ラック代⾦とか。それらと四則演算を
駆使するだけでパー何とか（客単価、1クエリ当たりの費用とか）を簡単に取る
ことが出来ます。そうすることで会社に関する数字をこれでほとんど抑えるこ
とができ、スーツや経営層から喜ばれるとともに、自分がその⽴場になった時
に強⼒な武器になります。打合せの時も表計算ソフトなんかで資料を作らずに
これを⾒ながら出来ると効率的でいいですね。
13. ■Gangliaのタイプ
リソースモニタリングには大きく以下の2つのタイプがあります。
エージェント型：
情報収集対象となるクライアント側でエージェント（デーモン）を起動するタイ
プ。マネージャ側の設定負荷は軽いことが多い。Gangliaは基本こっち
エージェントレス型：
クライアント側でエージェントを起動する必要がなく、何らかの⽅法（snmp,ssh
ログイン等）で情報を収集するタイプ。マネージャ側の設定負荷が⾼いことが多
い。Cactiは基本こっち
また、通信（収集）の向きについては集中監視サーバ（マネージャ）からクライア
ントにアクセスして収集するタイプ（Cactiは基本こっち）とクライアントからマ
ネージャに対してデータを送るタイプ（Gangliaは基本こっち）がある。
14. ■Gangliaの構成イメージ
クラスタ
①データ送信 gmond
・マネージャ側の設定ファイルgmond.confで
設定すること（主に） クライアント
－クラスタ名
－マネージャの受けポート番号 ②データ受信
gmond gmond
例)UDP: クライアント
port10000
マネージャ
gmond
③データ問合せ クライアント
gmetad ④サマリデータも計算
・クライアント側の設定ファイルgmond.confで
設定すること（主に）
⑤データ吐出し
－クラスタ名
－マネージャのIPアドレス
RRD ※マルチキャストも使えるけど使ってない
ファイル －マネージャの受けポート番号
・/クラスタ名/サーバ名/データ種別.rrdな感じで吐出される －データ送信周期
※対象サーバ数が多くなるとI/OネックになってRRDへの登録が遅れデータの
登録漏れが出てグラフが切れるため、tmpfsにシンボリックリンクを貼って
メモリディスクに吐出されるようにしている。
facebookの⼈もVelocity2010でそうしてるって⾔ってた。1000台超えたら。
HDDへの退避（バックアップ）を忘れずに！！
15. ■ここ（Ganglia）で（私が）⾔うクラスタとは
常々、⾊々な観点からパフォーマンス（リソース消費）情報を⾒たいと考えていた。
ex:機能毎（あるサービスのWebサーバ）、ラック毎、仮想マシン毎等
それで、その枠毎の中でどれだけのリソースが使われているのかを簡単に把握した
いと考えていた。それをクラスタと呼んでいます。自分としてはクラスタというよ
りもパースペクティブ（観点・視点）の⽅がイメージ的に近いと考えています。
なので、1台のサーバが複数のクラスタに所属する可能性があります。
これはGangliaの基本思想とは異なるところなのかもしれません。
ラック毎 ラック毎
D F
D1 F1 機能毎
D2 F2 機能毎
機能毎 A B C D3 E F3 G H 機能毎
VM毎 VM毎
16. ■1台のサーバを複数のクラスタに所属させるには
Gangliaのクラスタ（名）はポート番号と紐づいています。
なので、1つのサーバを複数のクラスタに所属させるには、そのサーバ上で複数の
ポートでデーモンを起動する必要があります。
ポート番号とクラスタ名はgmond.confで設定します。1つのgmond.confで設定でき
るポート番号とクラスタ名は1つのみです。
よって、複数のクラスタに所属させるには複数のgmond.confを用意して、それらを
読み込んで別々のデーモンを起動する必要があります。
gmondのconfファイル読み込みオプションは-cです。
gmond.confの命名規則は、「gmond-分類-クラスタ識別⼦-ポート番号.conf」とかに
すると管理がしやすくなると思います。
/usr/sbin/gmond -c /etc/gmond/conf/gmond-0-ALL-10000.conf
/usr/sbin/gmond -c /etc/gmond/conf/gmond-1-sumo_web-11001.conf
/usr/sbin/gmond -c /etc/gmond/conf/gmond-2-4F_15-12005.conf
分類は0「ALL」、1「機能毎」、2「ラック毎」とか
17. ■Gangliaの構成イメージ（複数クラスタ）
gmond
クライアント
gmond
UDP:10000 gmond
gmond
マネージャ UDP:11001 gmond クライアント
UDP:12005 gmond
gmond
gmond クライアント
gmond
gmetad gmond
gmond クライアント
RRD
ファイル
18. ■クラスタ構成の管理
このように1台のサーバを複数のクラスタに所属させると管理が複雑になります。
具体的には、この辺が問題になります。
・クライアント側に所属するクラスタ分の設定ファイルを送ることになる
・クライアント側で自動起動の設定を所属するクラスタ分だけすることになる
・gmondを監視しようとするとクラスタ分監視しないといけなくなる
そのため、私は、
・クライアント側には所属しないもの含め全てのクラスタ分の設定ファイルを全
台に送り
・マネージャ側でホストとクラスタの対応表を作って、マネージャ側から全台に
sshログインして、落ちていたら上げるというcronを仕込んでいます。
demontool等の使用も考えましたが、クライアント側でコントロールするのは難し
いと思い、こうやっています。正直、仕組み的にいけてないと思っていますが他に
いい⽅法が思いつきません。puppetもクラスタの変更に対応しにくいです。
こうやってるよとか良いアイデアあればぜひ！！
19. ■Gangliaのデータ保持期間（デフォルト）
収集間隔(
収集間隔(秒) 記録単位(
記録単位(回) 記録数 記録単位 記録保持期間
15 1 15秒
244 15秒 3,660秒
3,660秒≒1時間
15 24 244 6分 1,464分 24時間
1,464分≒24時間
平均値 15 168 42分
244 42分 10,248分
10,248分≒7日
15 672 168分
244 168分 40,992≒28日
40,992≒28日
15 5760 374 1日 374日
374日≒1年
1取得データ(RRDファイル)あたり上記のデータ数となり、ヘッダ情報含め約12KB
となる。デフォルトの取得データ数は41個程度で、そうすると1ホストあたり12KB
×41個≒500KB程度のデータ量となる。但しRRDファイルなので、時間が経っても
基本的にデータ量は著しくは増えない。オンメモリ（tmpfs）にする場合の必要メモ
リ量の計算にはこの値を使うことになる。
Gangliaは過去に遡って⾒るという概念があまりないらしく、そのためデータ保持期
間はそれぞれのグラフに必要最低限なものしかないようです。
直前の1時間、1⽇、1週間、1ヶ⽉、1年とかいう感じで。
20. ■Gangliaのデータ保持期間（参考）
収集間隔(
収集間隔(秒) 記録単位(
記録単位(回) 記録数 記録保持期間(
記録単位 記録保持期間(日)
15 20 600 5分 2.1
15 120 700 30分
30分 14.6
平均値
15 480 755 2時間 62.9
15 5760 797 1日 797.0
それだと、過去に遡って同じ粒度で確認することが出来ないので、上記のように15
秒間隔のデータを諦めて、他の間隔の記録数を増やすことで2倍程度の過去データを
保持するようにしている。
これだと1取得データ(RRDファイル)あたり、ヘッダ情報含め約23KB程度となる。
Cactiのデフォルトのデータ保持期間を参考にしています。
収集間隔の15秒は多分変更不可で、記録単位と記録数の設定はgmetad.confのRRAs
⾏で設定します。
上記設定だとこんな感じ。※実際は1⾏です
RRAs "RRA:AVERAGE:0.5:20:600" "RRA:AVERAGE:0.5:120:700"
"RRA:AVERAGE:0.5:480:755" "RRA:AVERAGE:0.5:5760:797"
22. ■新しい監視を追加するには
いくつか⽅法はありますが、ここでは3.1.0から対応可能になったPythonスクリプ
トによる⽅法を紹介します。
・クライアント側にganglia-gmond-modules-pythonが必要
・/usr/lib/ganglia/python_modules/の下にPythonスクリプトを設置※
・/etc/ganglia/conf.d/の下に拡張⼦.pyconfファイルを設置※
・gmond.confで上記ディレクトリの*.pyconfを読込むようになっている
・Gangliaのドキュメントルート/graph.d/配下にphpファイルを置く※
・GangliaのWebインタフェースのドキュメントルート/templates/default/配下の
各種ビューファイルにグラフを追加
※はテンプレが用意されているもの 結構めんどいですね！！
私が純正以外に追加しているのは、サーバの電⼒使用量くらいで、最近のサーバで
は標準添付の管理ソフトを⼊れればsnmpで値を取れるものが多いのでそれを取っ
ています。
