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.
Gangliaはじめました

  @qpstudy#2

    2010.7.24
     yuzorock
■自⼰紹介
 名前:

        yuzorock(ユーゾロック) http://twitter.com/yuzorock

 仕事:
  某インターネットポータルサイトのインフラ(サーバ)エンジニア
 今⽇の話:
  パフォーマンス(リ...
■監視とは
 インフラエンジニアが⾏う監視には大きく分けて以下の2種類があると思います。


 死活監視:
  サーバやNW機器がpingやsshに正常に応答するかや提供しているサービス(http
  等)が正常に応答を返しているかを監視する。...
■集中監視
 監視の⽅法としては、中央の監視サーバで集中的に監視する⽅法が⼀般的。
 集中的に監視の⽅法としては時系列のグラフで⾒るのが⼀般的。
 最近ではRRDtoolというツールを使うのが⼀般的。
 RRDtoolについては以下の資料が秀逸...
■RRDtoolを使ったデータ収集からグラフ化して表⽰までの流れ

       収集       RRDへ登録      グラフ化   表⽰

                  ⼀般的なRRDtoolの範疇

 収集:
  中央の監視サーバ...
■何が⾒れるか?何を⾒ることができるか?
 ツールにて標準で取れる値が用意されています。ことがあります。
 多くのツールはCPU使用率、ロードアベレージ、NW使用量等が取れる。
 基本的に値が取れるものであれば自分で何でも追加できる。
 但し、...
■⾒てどうするか?何のために⾒るか?
 リソースの消費状況を⾒て傾向把握や設備増設等の計画を⽴てるのに活用します。
 トラブルシューティング時の原因調査にも活用したりします。
  ・最近では気にかけないといけないリソースの1つに電⼒使用量(w)...
■最近のWebサービスのサーバ管理はどうなっているか
 冗⻑化や性能向上を考え、何かの機能を1台のサーバのみで提供していることは少な
 く、同じ機能を複数のサーバ群でクラスタ的に使っていることがほとんど。
 仮想化やクラウドによりサーバインスタ...
■そこでGanglia、やっとGanglia
 Gangliaはクラスタやグリッド向けリソースモニタリングツール。
 クラスタを構成するサーバ群の情報を自動的に⾜し合わせてそのクラスタのリソー
 ス消費量を確認できる。私がGangliaを使って...
■デモサイト:http://monitor.millennium.berkeley.edu/
LTここで終わり

Gangliaいいよ!!
■Gangliaについて
 バージョンは大きく3.0系と3.1系に分かれる。
 今から使うのであれば3.1系がおすすめ。
 3.1系の最新バージョンは3.1.7(2010年7⽉24⽇現在)。
 CentOSの場合、EPEL(Extra Pack...
■Gangliaのタイプ
 リソースモニタリングには大きく以下の2つのタイプがあります。
 エージェント型:
  情報収集対象となるクライアント側でエージェント(デーモン)を起動するタイ
  プ。マネージャ側の設定負荷は軽いことが多い。Gang...
■Gangliaの構成イメージ
                                                          クラスタ
                                    ①データ送信 ...
■ここ(Ganglia)で(私が)⾔うクラスタとは
  常々、⾊々な観点からパフォーマンス(リソース消費)情報を⾒たいと考えていた。
      ex:機能毎(あるサービスのWebサーバ)、ラック毎、仮想マシン毎等
  それで、その枠毎の中でど...
■1台のサーバを複数のクラスタに所属させるには
 Gangliaのクラスタ(名)はポート番号と紐づいています。
 なので、1つのサーバを複数のクラスタに所属させるには、そのサーバ上で複数の
 ポートでデーモンを起動する必要があります。
 ポート...
■Gangliaの構成イメージ(複数クラスタ)
                            gmond

                                    クライアント

                   ...
■クラスタ構成の管理
 このように1台のサーバを複数のクラスタに所属させると管理が複雑になります。
 具体的には、この辺が問題になります。
  ・クライアント側に所属するクラスタ分の設定ファイルを送ることになる
  ・クライアント側で自動起動の...
■Gangliaのデータ保持期間(デフォルト)

       収集間隔(
       収集間隔(秒)    記録単位(
                  記録単位(回)    記録数   記録単位   記録保持期間
           ...
■Gangliaのデータ保持期間(参考)

            収集間隔(
            収集間隔(秒)        記録単位(
                           記録単位(回)        記録数    ...
■Gangliaのデータ保持期間(参考の参考)
 Cactiのデータ保持期間(デフォルト)
 Cactiは収集間隔は5分、平均値と最大値を持っているため、データ量は1取得データ
 (RRDファイル)あたり54KB程度です。

       収集...
■新しい監視を追加するには
 いくつか⽅法はありますが、ここでは3.1.0から対応可能になったPythonスクリプ
 トによる⽅法を紹介します。
 ・クライアント側にganglia-gmond-modules-pythonが必要
 ・/usr/...
■最後に
 Cactiと⽐べるとユーザ管理機能がないとか新しいグラフが追加しにくいとか⾊々不
 便な点もあると思いますが、このクラスタという概念にほれてGangliaを使い始め
 ました。
 将来的にはこれでビジネス周りの数字も全て⾒れるように...
Upcoming SlideShare
Loading in …5
×

Gangliaはじめました

32,342 views

Published on

Gangliaはじめました

  1. 1. Gangliaはじめました @qpstudy#2 2010.7.24 yuzorock
  2. 2. ■自⼰紹介 名前: yuzorock(ユーゾロック) http://twitter.com/yuzorock 仕事: 某インターネットポータルサイトのインフラ(サーバ)エンジニア 今⽇の話: パフォーマンス(リソース)監視とは何かという話と、そのツールでGangliaと いうのがあっておすすめですよという話。 おまけ: 初⼼者にも優しいインフラ勉強会なのでGangliaの細かい話はないです。 細かい話は後ろにつけましたので、質問あればtwitterで@yuzorockして下さい。 できればハッシュタグ#qpstudyつけて。 ⽇本語の情報が少ないので使っている⽅と⾊々と情報交換したいです。
  3. 3. ■監視とは インフラエンジニアが⾏う監視には大きく分けて以下の2種類があると思います。 死活監視: サーバやNW機器がpingやsshに正常に応答するかや提供しているサービス(http 等)が正常に応答を返しているかを監視する。 Nagios、OpenView等のツールが有名。 パフォーマンス(リソース)監視: サーバやNW機器の負荷状態(ロードアベレージ)、リソース消費量(CPU、 メモリ、HDD等)等の経過を時系列で監視する。 Cacti等のツールが有名。Gangliaはこっち。 ※両⽅の監視を同時に⾏うツールもあるが今回は触れない。
  4. 4. ■集中監視 監視の⽅法としては、中央の監視サーバで集中的に監視する⽅法が⼀般的。 集中的に監視の⽅法としては時系列のグラフで⾒るのが⼀般的。 最近ではRRDtoolというツールを使うのが⼀般的。 RRDtoolについては以下の資料が秀逸。 RRDtoolを使う by久保⽥ 拓朗さん http://www.bonz.squares.net/~takuro/rrdtool-LAST-version1.1.pdf
  5. 5. ■RRDtoolを使ったデータ収集からグラフ化して表⽰までの流れ 収集 RRDへ登録 グラフ化 表⽰ ⼀般的なRRDtoolの範疇 収集: 中央の監視サーバにクライアントであるサーバやNW機器の情報を集めてくる フェーズ。基本的にはツールの機能として提供される。 RRDへ登録,グラフ化: RRDtoolにて機能(コマンド)が提供されているが、複雑(煩雑)な部分があ るためツールでラップされていて意識しなくてもいいことが多い。 表⽰: ⼀般的にはWebページとして表⽰され、ツールによって提供される。 ユーザ管理機能、認証機能、グラフの配置、クライアントの登録等の機能が提供 される。所謂⾒た目の部分なのでこれが自分達の目的に合っているかがツール選 定の大きなポイントとなる。RRDtoolだけ使って自作する会社(⼈)も多い。
  6. 6. ■何が⾒れるか?何を⾒ることができるか? ツールにて標準で取れる値が用意されています。ことがあります。 多くのツールはCPU使用率、ロードアベレージ、NW使用量等が取れる。 基本的に値が取れるものであれば自分で何でも追加できる。 但し、自分で追加するには多少複雑な部分があり、そのためツールのコミュニティ や有志によりプラグインが用意されていることがある。 その豊富さもツール選定のポイントの1つとなる。
  7. 7. ■⾒てどうするか?何のために⾒るか? リソースの消費状況を⾒て傾向把握や設備増設等の計画を⽴てるのに活用します。 トラブルシューティング時の原因調査にも活用したりします。 ・最近では気にかけないといけないリソースの1つに電⼒使用量(w)が追加され ているように感じます。これはデータセンターにおけるラック設置の⽀配的要 素になってきているからです。最近のCPU(マザーボード?)には電⼒使用量 に応じてCPU速度を変化させることが出来るものがあり、そのようなサーバで あれば電⼒使用量の値を取ることが出来ると思います。 ・リソースの使用量だけではなく、サーバが持ってるビジネスに関する数値も取 るといいと思います。会員数、売上げ、ラック代⾦とか。それらと四則演算を 駆使するだけでパー何とか(客単価、1クエリ当たりの費用とか)を簡単に取る ことが出来ます。そうすることで会社に関する数字をこれでほとんど抑えるこ とができ、スーツや経営層から喜ばれるとともに、自分がその⽴場になった時 に強⼒な武器になります。打合せの時も表計算ソフトなんかで資料を作らずに これを⾒ながら出来ると効率的でいいですね。
  8. 8. ■最近のWebサービスのサーバ管理はどうなっているか 冗⻑化や性能向上を考え、何かの機能を1台のサーバのみで提供していることは少な く、同じ機能を複数のサーバ群でクラスタ的に使っていることがほとんど。 仮想化やクラウドによりサーバインスタンス数は増える傾向にある。 Webサーバ Webサーバ Webサーバ Webサーバ Webサーバ Webサーバ Webサーバ Webサーバ Webサーバ Webサーバ Webサーバ Webサーバ Webサーバ Webサーバ Webサーバ DBサーバ Webサーバ APサーバ Webサーバクラスタ DBサーバクラスタ APサーバクラスタ 集中監視 サーバ
  9. 9. ■そこでGanglia、やっとGanglia Gangliaはクラスタやグリッド向けリソースモニタリングツール。 クラスタを構成するサーバ群の情報を自動的に⾜し合わせてそのクラスタのリソー ス消費量を確認できる。私がGangliaを使っている理由はこれが⼀番大きい。2番目 はサーバ群の固体情報の視認性(⼀覧性)が⾼い。 エージェント型で、クライアントに設定ファイルを配ってデーモンを起動すれば良 く、マネージャー側で何もしなくていいので、大量のサーバを管理する場合にやり やすい。 facebookでも使っているらしい。
  10. 10. ■デモサイト:http://monitor.millennium.berkeley.edu/
  11. 11. LTここで終わり Gangliaいいよ!!
  12. 12. ■Gangliaについて バージョンは大きく3.0系と3.1系に分かれる。 今から使うのであれば3.1系がおすすめ。 3.1系の最新バージョンは3.1.7(2010年7⽉24⽇現在)。 CentOSの場合、EPEL(Extra Packages for Enterprise Linux)レポジトリからyum で簡単にインストールできるが3.0.7なのでおすすめしない。
  13. 13. ■Gangliaのタイプ リソースモニタリングには大きく以下の2つのタイプがあります。 エージェント型: 情報収集対象となるクライアント側でエージェント(デーモン)を起動するタイ プ。マネージャ側の設定負荷は軽いことが多い。Gangliaは基本こっち エージェントレス型: クライアント側でエージェントを起動する必要がなく、何らかの⽅法(snmp,ssh ログイン等)で情報を収集するタイプ。マネージャ側の設定負荷が⾼いことが多 い。Cactiは基本こっち また、通信(収集)の向きについては集中監視サーバ(マネージャ)からクライア ントにアクセスして収集するタイプ(Cactiは基本こっち)とクライアントからマ ネージャに対してデータを送るタイプ(Gangliaは基本こっち)がある。
  14. 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. 15. ■ここ(Ganglia)で(私が)⾔うクラスタとは 常々、⾊々な観点からパフォーマンス(リソース消費)情報を⾒たいと考えていた。 ex:機能毎(あるサービスのWebサーバ)、ラック毎、仮想マシン毎等 それで、その枠毎の中でどれだけのリソースが使われているのかを簡単に把握した いと考えていた。それをクラスタと呼んでいます。自分としてはクラスタというよ りもパースペクティブ(観点・視点)の⽅がイメージ的に近いと考えています。 なので、1台のサーバが複数のクラスタに所属する可能性があります。 これはGangliaの基本思想とは異なるところなのかもしれません。 ラック毎 ラック毎 D F D1 F1 機能毎 D2 F2 機能毎 機能毎 A B C D3 E F3 G H 機能毎 VM毎 VM毎
  16. 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. 17. ■Gangliaの構成イメージ(複数クラスタ) gmond クライアント gmond UDP:10000 gmond gmond マネージャ UDP:11001 gmond クライアント UDP:12005 gmond gmond gmond クライアント gmond gmetad gmond gmond クライアント RRD ファイル
  18. 18. ■クラスタ構成の管理 このように1台のサーバを複数のクラスタに所属させると管理が複雑になります。 具体的には、この辺が問題になります。 ・クライアント側に所属するクラスタ分の設定ファイルを送ることになる ・クライアント側で自動起動の設定を所属するクラスタ分だけすることになる ・gmondを監視しようとするとクラスタ分監視しないといけなくなる そのため、私は、 ・クライアント側には所属しないもの含め全てのクラスタ分の設定ファイルを全 台に送り ・マネージャ側でホストとクラスタの対応表を作って、マネージャ側から全台に sshログインして、落ちていたら上げるというcronを仕込んでいます。 demontool等の使用も考えましたが、クライアント側でコントロールするのは難し いと思い、こうやっています。正直、仕組み的にいけてないと思っていますが他に いい⽅法が思いつきません。puppetもクラスタの変更に対応しにくいです。 こうやってるよとか良いアイデアあればぜひ!!
  19. 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. 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"
  21. 21. ■Gangliaのデータ保持期間(参考の参考) Cactiのデータ保持期間(デフォルト) Cactiは収集間隔は5分、平均値と最大値を持っているため、データ量は1取得データ (RRDファイル)あたり54KB程度です。 収集間隔( 収集間隔(秒) 記録単位( 記録単位(回) 記録数 記録保持期間( 記録単位 記録保持期間(日) 300 1 500 5分 1.7 300 1 600 5分 2.1 平均値 300 6 30分 700 30分 14.6 300 24 755 2時間 62.9 300 288 797 1日 797.0 300 1 500 5分 1.7 300 1 600 5分 2.1 最大値 300 6 30分 700 30分 14.6 300 24 775 2時間 64.6 300 288 797 1日 797.0
  22. 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で値を取れるものが多いのでそれを取っ ています。
  23. 23. ■最後に Cactiと⽐べるとユーザ管理機能がないとか新しいグラフが追加しにくいとか⾊々不 便な点もあると思いますが、このクラスタという概念にほれてGangliaを使い始め ました。 将来的にはこれでビジネス周りの数字も全て⾒れるようにしたいと考えているので ⻑い付き合いになりそうです。 Webに⽇本語の情報が少ないように思えますので今後⾊々と情報交換できるといい なと考えています。 Enjoy!!

×