ラベル システム監視 の投稿を表示しています。 すべての投稿を表示
ラベル システム監視 の投稿を表示しています。 すべての投稿を表示

2010/12/20

ZABBIX勉強会でDECOLOGのシステム監視運用のお話をしました。



こんにちは。落ちている点棒は拾う主義のhiroshiです。
今年最後のブログ更新になるかもしれないエントリーです。

去る2010年12月18日(土)18:30~に開催された「第3回ZABBIX勉強会」に登壇してみました!




きっかけは、TwitterでZABBIX-JP代表の寺島さんに「話してみませんか?」とご依頼いただいたことでした。やっててよかったTwitter!そして寺島さん!ありがとうございます!
今思えば「やりましょう。」っていうまたとないチャンスだったのに「DMでメールください」とか本当にダサかったなあって反省しています。

なんていうか、僕こういう勉強会とかセミナーとか行ったことなかったので、非常に緊張してて、当日が近づくにつれ、何度か「病気になったことにしようかなー」とか思わなかったかといったら嘘になるんですが、そういう誘惑に負けずにちゃんとやってよかったです。

どのへんがよかったかということを自分視点でざっくり書き連ねると・・・

  1. 会社、およびDECOLOGの知名度向上に役立った
  2. 思ったより自分とこのノウハウは需要があることがわかった
  3. 恥ずかしくない発表にするためにいろいろ調べたりするので、発表の資料制作の課程で新しいことがいろいろ知れた
  4. チームメンバーの勉強にもなった
  5. 「慣れ」ができた

といったところでしょうか。


1.会社、およびDECOLOGの知名度向上に役立った


これは、つまりリクルーティング力アップにつながりますね。なんせ5人ですから。今だけをみればなんとかなっているものの、今後のことを考えるともっと仲間が欲しいところです。
加えて、これくらいの規模になり、技術的にもそれなりに魅力的なことができる環境にあるという自負はあるものの、大阪ドームでイベントやったり雑誌出したりしても、まだまだエンジニア界隈での知名度は激低で、なかなか「ミツバチワークスで働きたいなあ」と考えてもらえるだけの状況にありません。

名も知れぬ何やってるかよくわからない会社に転職はなかなかしてもらえませんからね。。

そういった意味でのプラスになったことは間違いないと思っています。


2.思ったより自分とこのノウハウは需要があることがわかった


60億PVとか400台とかいっても、上を見れば上がある。だから、僕らのノウハウとかに興味持ってくれる人ってどれだけいるんだろう?と懐疑的だったんですが、そんなことはやってみないとわかりませんよね。実際やってみたところ、それなりに評価していただけたようで、非常に嬉しく思ったと同時に、自信につながりました。


3.恥ずかしくない発表にするために~いろいろ知れた


やっぱり人様になにかお見せしようと思ったら、そこそこ"勘"とか"流れ"でやってたことも、これを機会に裏を取ったりするわけです。その過程で、「あっ!できねーと思ったらできたのか!」とか、「こういうやり方もあったのか!」とか「やってたつもりだったけど、できてねーじゃん!」という部分が発見できたりするんです。

「周辺知識」みたいなものは、それに出会えるかどうかは、常にそのトピックスに対して自分アンテナが張れているかどうか?という基本的な部分はあるものの、最終的には「運」に作用されるところも大きいと思います。だから、取りこぼしはしばしば発生してしまいます。


「発表」というアクションはそういう「周辺知識」を取りこぼしにくくする作用がある気がします。



4.チームメンバーの勉強にもなった


まだ知識が浅いメンバーに対しては、教えたつもりでも伝わりきれていないことが、こういうアクションを通して伝えることができたりします。

また、そうではないメンバーに対しても、ズレがちになるノウハウや方針の基本コンセプトを再度互いに認識しあえる良いきっかけになります。


5.「慣れ」ができた


寄生獣の後藤も「何事も慣れだ」と言っていましたが、まさにそのとおり。0回の経験と1回の経験の差は、1回の経験と100回の経験の差より、差があると思っています。

上述のとおり、発表のメリットはたくさんあるので、今後も機会さえあればガンガンやっていきたいと思っています。

ガンガンやるぜ!となっても、基本的にシャイボーイなので今回の経験がなかったらビビって、すぐショボンとなってしまったかもしれません。そういう良い意味で「慣れ」ができたと思います。




という感じで、日曜日が終わり、月曜に入ったあたりの夜更けにガーっと書いたのでちゃんとまとまってないかもしれませんが、もしよければ、各所からのお誘いなどお待ちしております。そして、近い将来に自社で勉強会主催できたらいいなぁと思っています。

そして最後に、ご清聴・反応いただいたみなさん、本当にありがとうございました!







2010/12/14

ZABBIXでmemcachedを監視する



こんにちわ、stoneです。
話のマクラに、その時々の時事ネタとか入れたいのですが、記事の公開のタイミングはhiroshiに任せてあるので、自分ではわからないんですよねぇ。なので、今まで、マクラなしにすごく素っ気ない書き出しをしていたのですが、やっぱり気持ち悪いので、マクラを入れることにします。
いやぁ、熱かったですね、クラシコ。
まさに粉砕っ!!って感じで。CLの決勝ラウンドもこの調子で勝ち上がっていってほしいものです。


さて、マクラも無理矢理いれて、すっきりしたところで(笑)、以前もhiroshiがちょっと紹介しました、zabbixを利用したmemcachedの状態監視についてもうすこし掘り下げてご紹介しようかと思います。

以下、zabbixや、memcached自体については、
ZABBIX本家ページ
memcached本家ページ
をごらんください。


memcachedの稼働データを取り出す

まずなによりも、memcachedから稼働状況のデータを取り出さないことには、話が進みません。以前にも書いたことがあると思いますが、新規のソフトウェアを採用する際、「稼働状況のデータが取れる」というのを選定基準の一つにしています。

memcachedのソースパッケージのscriptディレクトリにmemcached-toolというプログラムがあります。DECOLOGでは、コレを利用してZABBIXに監視させています。memcachedのインストール時に同時に/usr/local/binにmemcached-toolをコピーして置くと後で面倒がなくていいです。

memcahed-toolで、こんな↓でデータがとれます。
$ memcached-tool localhost stats
#localhost:11211 Field       Value
                   bytes  1869063911
              bytes_read 1032067324963
           bytes_written 54746662119672
                 cmd_get 19593630588
                 cmd_set   581606051
   connection_structures        1995
        curr_connections         131
              curr_items     3809885
               evictions           0
                get_hits 18996360805
              get_misses   597269783
          limit_maxbytes  9663676416
                     pid       29872
            pointer_size          64
           rusage_system 2025915.129086
             rusage_user 344758.197787
                 threads           1
                    time  1291213602
       total_connections  3544421727
             total_items   581606051
                  uptime    33891235
                 version       1.2.5
バージョンが古いですが、ご容赦ください。

監視項目

DECOLOGでは、memcachedサーバーの監視項目は、
・ロードアベレージ
・ネットワークトラフィック
・memcachedへの接続数
・キャッシュヒット率
・ストアされているデータの中での最小のTTL
の5つを監視しています。

このうち、ロードアベレージ、ネットワークトラフィックは、ZABBIXのLinux_Templateのアイテムを利用しています。

memcachedへの接続数

上記のmemcached-toolの出力から、「curr_connections」の値をそのままZABBIXに監視させればOKです。
UserParameter=memcached.curr_conn,/usr/local/bin/memcached-tool entrylistcache01 stats | grep curr_conn | awk '{print $2}'

キャッシュヒット率

こちらは、出力されるデータを元にひと手間加えます。
まず、毎分、memcahed-toolsの出力をログに出力します。
/etc/zabbix/scripts/memcachedstat.sh
#! /bin/sh
LOG_DIR=/var/log/memcachedstat
file_name=${LOG_DIR}"/"`date +%M`

/usr/local/bin/memcached-tool localhost stats > $file_name
これを毎分起動して、1分ごとにログを残します。
/etc/cron.d/memcachedstat
* * * * * root /etc/zabbix/scripts/memcachedstat.sh

そして、ヒット率を計算するスクリプトも用意します。
/etc/zabbix/scripts/memcached_hit_ratio.sh
#! /bin/sh
LOG_DIR=/var/log/memcachedstat

range=$1
if [ "x"$range == "x" ]; then
        range=1
fi

curr_file=${LOG_DIR}/`date +%M`
comp_file=${LOG_DIR}/`date -d "$range min ago" +%M`

if [ ! -f "$comp_file" ]; then
        echo -1
        exit
fi

curr_hit=`grep get_hits $curr_file | awk '{print $2}' | sed -e 's/\r//'`
curr_miss=`grep get_misses $curr_file | awk '{print $2}' | sed -e 's/\r//'`

comp_hit=`grep get_hits $comp_file | awk '{print $2}' | sed -e 's/\r//'`
comp_miss=`grep get_misses $comp_file | awk '{print $2}' | sed -e 's/\r//'`

hit_delta=`expr $curr_hit - $comp_hit`
miss_delta=`expr $curr_miss - $comp_miss`

if [ $hit_delta == 0 ]; then
    echo -1
else
    echo "scale=2; 100 * $hit_delta / ($hit_delta + $miss_delta)" | bc
fi

まぁ、何をやってるか日本語に直すと、
・毎分ごとのログを残す
・ログのファイル名は、起動時の分(minute)にしておく(00〜59)
・memcached_hit_ratio.shでは、現在のデータと引数で指定された分(minute)までさかのぼったデータとの比較を行う(指定がなけければ、1分前)
・取り出す値は、get_hitsとget_misses
・各々の差分から指定された時間の間のヒット率を計算

これを、ZABBIXにのせます。
UserParameter=memcache.hit_ratio[*],/etc/zabbix/scripts/memcached_hit_ratio.sh $1

ストアされているデータの最小TTL

この項目を監視しようとおもった動機なんですが、ある機能を追加しょうとデバッグを行っていたのですが、キャッシュがすぐに消えてしまう、という現象にあたりました。感覚的には、1分も持たない感じでした。で、調べた結果、やっぱり、memcached-toolが教えてくれました。
「stats」を渡さないと、memcachedの中のメモリの使用状況がわかります。
$ memcached-tool localhost
  #  Item_Size   Max_age  1MB_pages Count   Full?
  1     104 B  33891469 s     195 1957267      no
  2     136 B  33891487 s      58  439789      no
  3     176 B  33891476 s      34  200526      no
  4     224 B  33891486 s      35  162846      no
  5     280 B  33891488 s      35  128192      no
  6     352 B  33891480 s      38  112709      no
  7     440 B  33891483 s      44  103514      no
  8     552 B  33891475 s      54  101027      no
---- snip ----
問題のキャッシュサーバーでは、こんな↓出力がありました。
#  Item_Size   Max_age  1MB_pages Count   Full?
  1     104 B  7698339 s       1   10080     yes
  6     184 B  7173349 s       1    3130      no
  7     208 B       39 s       3   15123     yes
  8     232 B   557835 s    1924 8694555     yes
  9     256 B       83 s      26  106496     yes
 10     288 B       37 s      29  105560     yes
 11     320 B       64 s      20   65520     yes
---- snip ----
「Max_age」の欄がそのメモリブロック(slabと言うらしい)の中で、一番古いデータの保持期間らしいのですが、軒並み1分程度でキャッシュが消えてしまう、という状況になっていました。
この状況を早めに検出するために、Max_ageの値を監視することにしました。

/etc/zabbix/scripts/check_memcached_max_age
#!/usr/bin/perl
my $memcached_tool = '/usr/local/bin/memcached-tool';
my $host = 'localhost';

open(IN, '-|', $memcached_tool, $host) or die "Can't start $memcached_tool: $!";

my $min = 1e100;

while () {
    my @line = split;
    my $max_age = $line[3];
    my $count = $line[6];
    next unless $count > 1;
    $min = $max_age if $max_age < $min;
}

print "$min\n";
ZABBIXでは、
UserParameter=memcache.check_max_age,/etc/zabbix/scripts/check_memcached_max_age
として、現状、86400秒(1日)以下だった場合に、Triggerが発動するようにしてあります。


こういう標準以外の仕込みを入れているサーバーは、他にApacheとか、MySQLとかあるんですが、それも次回以降にご紹介できればと思います。

では、また次回に♪

2010/10/06

LogWatchが多すぎる!!

こんにちは。
ミツバチワークスで技術責任者をしています、stoneと申します。
先駆けてブログを開設・投稿してくれていたhiroshiが、
ハンドルネームで名乗っているので、自分もハンドルネームで名乗ってみることにしました。
なかなかに気恥ずかしいですね、これ。(笑)



さて、とても幸運なことに、ここ数年というもの、DECOLOGというサービスは、
ユーザー数/トラフィックともに順調に伸びて行っている状態で、
その要求に応える為に、サーバーの増設も毎月のようにおこなっています。

当初、DECOLOGは、たった1台のサーバーで運営されていました。
現在では、300台以上のサーバーで構成されています。
もちろん、それ以前に、その規模のサーバー群を扱ったこともないですし、
まさか、自分が100台以上のサーバーで構成されるサービスに関わるなんて、
夢にも思ってませんでした。

台数が増えるにつれ、数台での運用していた頃には想像できなかったことが、
いろいろ出てくるのですが、今回は、そんな「想像できなかったこと」のうちの
1つを紹介したいと思います。



現在、DECOLOGを構成するサーバー群のログの監視には、LogWatchを利用しています。
ご存知のようにLogWatchは、dailyでレポートメールを送ってきてくれるのですが、
10数台ぐらいまでは、毎朝、異常がないか、目視でレポートメールを確認をしていました。

が、これが、台数がふえるにつれ、LogWatchのチェックだけで、
かなりの時間が必要になってきてしまうんですね。
そして、ついには、もう、目視では、チェックしきれないほどの量になってしまいました。
連休明けや、夏休み/冬休み明けともなると、LogWatchだけで、
1000通を超えることもありました。
問題に直面してみれば、至極当然の結果なのですが、自分には、想像の範囲外の問題でした。

もう、チェックし切れないなら、レポートを切ってしまえばいいのですが、
「もし何か見落としがあったら。。。」と思うと、バチンと切ってしまう勇気も持てませんでした。

そこで、考えたのが、今、ウチで使っている「LogWatch Watch」(笑)です。
だいたい、こんな↓流れで動いてます。
  • LogWatchのレポートメールをLogWatch Watchが動いているサーバーにも送信
  • メールを受けると、フィルタリングプログラムが起動
  • フィルタリングプログラムには、あらかじめ、無視していい記述を登録しておき、
    それから漏れた記述をデータベースに保存
  • Webインターフェースを用意して、登録外の記述をチェック
実際のフィルタリングは。。。。
  • Cron: run-parts /etc/cron.(hourly|weekly|daily)を無視
  • Diskspace: 90%以上になったら、データベースに登録
  • sshd: "SFTP subsystem requests"を無視
とった感じで、登録する/無視するの判断をしています。

これを作って、実際に使ってみると、思った以上に便利でした。
1日数百行のチェックから、1日50項目以下のチェックですみます。

実際の画面は、こんな↓感じです。


現在は、時間の合間を見つけて、改良を進めて、キーボードショートカットで動くようになっています。
j: 下へ
k: 上へ
x: 項目を削除
m: 項目を保護(削除できないように)
とviライクな操作感で、サクサクとチェック・削除をしています。

DECOLOG本体での機能追加や修正のプログラミングは、
バグを仕込んでしまうと影響がとても大きいから、
一定以上の緊張感をもって臨んでいるのですが、
こういう「まかない」的なプログラムを書いてるときは、
その緊張感から解放されて、本当にプログラミングが楽しく感じられます。
自分勝手にイメージして、自分勝手に実装できますしね。(笑)


他にも、問題に直面するまで想像できなかったことに、
  • クラスCのIPアドレスが足りなくなる
  • L2/L3のスイッチの限界値に行き当たる
などあるのですが、これらは、また、機会があったら、 後日、ご紹介することにしますね。 

では、また次回に

2010/09/29

DECOLOGのZABBIXを使ったシステム監視

こんにちは、hiroshiです。今は土曜の昼下がり、週1連載なんて言わなきゃよかったなーと思いながら男が一度言ったことは1ヶ月はやらねばだめだよね!ということで記事を書いてます。

今日はDECOLOGのシステムの監視についてです。
「便りがないのは良い知らせ」と言いますが、その便りが「システム落ちました」だとシビれますよね。

そうならないためには、システムを常時監視し、なるべく事前に異常に気づける仕組みづくりが欠かせません。

DECOLOGではシステムの監視にオープンソースツール「ZABBIX」を使っています。

ZABBIXはServerとAgentからなるクラサバ形式のツールで、CPU・メモリ・HDDの使用率などのおなじみなものはもちろん、標準出力に出せるものならなんでも取れてしまう優れものです。と書きましたが、他のツールのことは知らないのでこれはZABBIXに限ったことじゃないかもしれないです。

ちなみに例えばmemcachedのコネクション数を取りたい時なんかは、zabbix_agentd.confに↓のような感じにかけばよいわけです。
UserParameter=memcached.curr_conn,/usr/local/bin/memcached-tool localhost stats | grep curr_conn | awk '{print $2}'
grep curr_connのところはawkでNR==8とかでもいいかもですね。まあ、取れればなんでもいいワケです。

そして取得したデータをお好みのグラフにまとめたり、そのグラフをスクリーンという画面単位に整理できたりするのです!まあ、これも他のツールでもできることかもしれないですけど。

しかもしかもですよ、それぞれの監視項目に閾値を設定してそれを超えたらメール送信したりもできちゃうのです。・・・きっとこれも他のツールでもできるんだろうなー。

なぜZABBIXかというと「これ」っているのはなくて、DECOLOGの場合はstoneが導入当時、やりたいことができるツールを探していくつか試した結果、導入もすんなりいってしっくりきた最初のツールがZABBIXで、今も特に困ったことがないのでZABBIXを使い続けています。

困ってなきゃ、なんでもいいんです。今Cacti使ってて困ってることがなければCactiでいいと思います。ツールの変更とかは困ってきたら、もしくは困ることが見え始めてきたら考えるというノリでやってます。これは利用するプログラム言語もIDEもなんでもそうなんですが、あまり先のことまで考えすぎてはいけないと思ってます。

さて、そのZABBIXを使って何を監視しているか?ですが、基本的な死活監視およびCPU,メモリ,HDDの使用率、トラフィックなどは全サーバ視てます。というかZABBIXのAgentセットアップしてServerと疎通とると同時に勝手にみてくれてます。あとは用途ごとに定番のものがあります。だいたい以下です。

プロキシサーバー(バランサー)
DECOLOGのトラフィックはすべて数台のリバースプロキシサーバーを通って複数台のWEBサーバなりsquidサーバなりに振られるんですが、まずここのトラフィックが最重要監視項目です。何か問題がある場合は、ここに高確率で表れます。プログラムの更新とかネットワーク関係の設定変更とかをやる際は、タスクごとにいろいろ監視しながらやりますが、ここの監視は絶対に含まれます。
図1.とある日のとある時間のトラフィック
ここに変な動きがあったら何かがおかしい可能性が高い!

WWW/AP

CPUのロードアベレージとapacheのBusyWorkerを見てます。

DB
masterはロードアベレージとコネクション数で、slaveはさらにreplication delayを見てます。

memcached
コネクション数とキャッシュHit率を見てます。

squid
キャッシュHit率とファイルディスクリプタ数を見てます。

メールサーバ
キューの数とか送信状態を見てます。


と、こんな感じの定番項目以外は、必要に応じてグラフを起こして監視します。

グラフは、同じ役割のものを全部束ねて作ります。こんなイメージです。
こうすると、サーバに異常があったり、設定におかしなところがあったりすると、1本だけおかしな動きになるのでわかりやすいです。
たとえば
こんな感じです。これはとあるDBのロードアベレージのグラフですが、バックアップ用のDBを使って負荷のかかるSQLを流しているのでバックアップ用のDBの線(赤いの)だけロードアベレージが跳ね上がってます。

異常監視だけじゃなくて、上記のような例だと、「この線が下降してきたら、SQL処理が終わったんだな」みたいな用途にも使えます。

あとは、とにかく気になったものはグラフを起こしてスクリーンにまとめます。スクリーンには名前が付けられるので分かりやすい名前をつけます。たとえば「Squid Overview」とかです。しばらく、そのまま運用してみて、「やっぱこれいらねえな」ということになれば、なくなりますし、「これいいね!」ということになると、「04 Squid Overview」というように名前の手前に数字が付くというAKIRAのナンバーズのような制度を設けています。

今回はここまでにします。

各監視項目には必要に応じて閾値が設けられており、その閾値を超えるとアラートメールを飛ばすように設定していますが、次回はそのアラートメールについて書く予定です。違ったらごめんなさい。

次回が1ヶ月目のはずなので後1回はかならず週刊を守るべくがんばります。

では、また次回に会いましょう。