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/12/06

daemontoolsの利用法をいくつか


こんにちわ、stoneです。

いままで、MySQL関連のご紹介をいくつかしてきましたが、今回は、少々切り口を変えて、daemontoolsについて、いくつかご紹介してみたいと思います。


daemontoolsのものすごく簡単な概要

daemontoolsとは、プロセス監視を行ってくれるデーモンプロセスです。
監視対象のプロセスが、何らかの理由で落ちた場合、daemontoolsが自動的に再起動を行ってくれます。DECOLOGでは、qmail、memcached、keepalived、gearmand等のプロセス監視で利用しています。
daemontoolsそのものの詳しいことは、本家サイトhttp://cr.yp.to/daemontools.html等を参照してください。


ディレクトリ構成

daemontoolsは、/service/xxxxxxというディレクトリを見つけると、その下にあるrunファイルを実行します。DECOLOGでは、/etc/supervice/xxxxxxというディレクトリを作成し、対象プロセスのすべての準備が整った後、
# cd /service
# ln -s /etc/supervice/xxxxxx
として、daemontoolsの監視下に置きます。
daemontoolsは、runに不備があっても、問答無用で起動しようとするので、この様な方法をとっています。


daemontools + memcacached

memcachedをdaemontoolsの監視下に置く際の、runスクリプトは以下のようになっています。
#! /bin/sh

PATH=/usr/local/bin:$PATH
BOOT_LOG=/var/log/memcached.log

USER=nobody
PORT=11211
CACHESIZE=2048
MAXCONN=2000
OPTIONS=""

exec memcached -p $PORT -u $USER -m $CACHESIZE -c $MAXCONN $OPTIONS
memcachedは、/usr/local/bin以下にインストールされていると想定しています。
ここでは、通常memcachedをデーモンとして立ち上げる際の「-d」オプションを指定しません。
また、CACHESIZEやMAXCONNは、アテの値なので、起動前に適宜変更しています。


daemontools + keepalived

keepalivedの場合のrunスクリプトは、こんな↓感じです。
#! /bin/sh

PATH=/usr/local/sbin:$PATH

exec 2>&1
exec keepalived -n -d -D -S6

ここでもkeepalived自体のデーモンプロセス化を避ける「-n」オプションを指定します。
また「-S6」オプションは、このオプション指定すると、syslogのlocal6にログが出力されます。なので、/etc/syslog.confに
*.info;mail.none;authpriv.none;cron.none;local6.none  /var/log/messages
local6.*  /var/log/keepalived.log
と記述しておけば、keepalivedのログは、/var/log/keepalived.logに出力されます。


また、keepalivedは、HUPシグナルを受け付けてくれるので、何らかの変更があった場合、
# svc -h /service/keepalived
で、再起動することができます。


daemontools + gearmand

gearmandでのrunスクリプトは、こんな↓感じです。
#! /bin/sh

PATH=/usr/local/sbin:$PATH
LOG=/var/log/gearmand.log

USER=root
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/usr/local/lib
exec gearmand -u $USER -l $LOG
しつこいですが、ここでもデーモンプロセス化しないように「-d」を指定しません。
そういえば、gearmandは、立ち上げた後、このサーバーで何かオペレーションした記憶がありません。gearmandのことを、忘れかけていました。(笑)


readproctitleのメッセージを消す

daemontoolsを使用していると困るのが、readproctitleというエラーメッセージ用のプログラムです。これは、runスクリプトを実行の際に、何かエラーが発生した場合、このreadproctitleにエラーメッセージが表示されます。
$ ps ax
----snip----
 5164 ?        S      0:00 readproctitle service errors: ...........................................
----snip----
何かエラーが起きると、この「....」の部分にエラーメッセージが表示されるのですが、これが自動的にクリアされません。なので、DECOLOGでは、以下のようになプログラムを用意しています。

/service/clearmsg/run
#! /bin/bash
yes '' | head -4000 | tr '\n' .
このままだと、このスクリプトが何度も実行されてしまうので、事前に
# touch /service/clearmsg/down
として、通常は、停止状態にしておきます。で、エラーを消したいときに、
# svc -o /service/clearmsg
として、一回だけ上記のrunスクリプトを実行させます。
この辺は、みなさん、困っているらしく検索すると似たような対処法がいくつも出てきます。


daemontoolsを完全に落とす

サーバーの役割の組み替えや、移動などで、daemontoolsが不要になるケースがあります。この場合、単純にdaemontools関連のプロセス(svscan、readproctitle、supervise等)をkillしても、すぐに同じプロセスが再起動されてしまいます。
daemontoolsは、インストールする際に/etc/inittabに
SV:123456:respawn:/command/svscanboot
という記述を追加しています。
daemontoolsを完全に落とす場合は、/etc/inittabのこの行を消すか、コメントアウトして、
# telinit q
とすると、完全にプロセスが落ちます。


次回は、うーん。。。。。。
まだ数台で運用していた頃の思い出話にしようか、サーバー監視にしようか、さっき思い出したgearmanの話にしようか、ちょっと、迷ってます。まぁ、書き始めるときの気分で決めます。(笑)

では、また次回に♪