Webサービスを作っているものにとっては、サーバの監視は重要なことです。
サーバが落ちていない事を絶えず確認していたいパラノイアのための
XMPPによるサーバ監視方法を紹介します。

やることは単純で、サーバの動作を監視するデーモンスクリプトの中から、
問題が起こっていない場合に、XMPP経由でJabberクライアントに
「no problem」と、タイムスタンプつきで通知するだけです。

サーバ監視というと、たいていの場合、何か問題が起こった事を通知するように
することが多いです。しかし、この方法では、何も起こっていないことを
定期的に通知させることで、サーバ監視プログラム自体に対する疑念
をはらう事が出来ます。

60秒に一回Gtalkにno problemであることを通知させるようにしています。
Twitterのお陰で、1分間に一度程度の通知はさほど気にならなくなったのと、
心配になったらLogを見ればどの時間まで「no problem」であるかを
確認できるので、便利です。

複数人で開発している場合に、新しく作成したファイルを
svn addし忘れて、Commitもれを発生させてしまうと、
テストが走らなかったり、開発を止めてしまったりと、
様々な悪影響が発生してしまいます。

今回は、Commitもれを防ぐために僕が使ってる方法を紹介します。

やってることは単純で、以下のalias設定を.zshrcに登録しています。

shell>>
alias svn_new='svn stat | grep "^?" | sed "s/? tmp.//" | sed "s/? log.//" | grep .'
<<--

svn statの結果から、log/とtmp/ディレクトリの中身を除外してるだけですね。
あとは、svn_newコマンドを実行すれば、svn add
し忘れてるファイルが無いかどうか簡単に確認できます。

しかし、実際にはconfig/database.ymlやtagsファイルなど、
svn addする必要が無いファイルがだんだん増えてくるので、
そのような場合には適切にsvn:ignoreプロパティを設定していきます。

僕は、手間を省くために、以下のようなzsh関数を作って使っています。

~/.zshrc

shell>>
svn_ignore () {
svn pset svn:ignore -F <(echo $1 && svn pget svn:ignore | sed '/^$/d') $2
}
<<--

使い方はこんな感じです。

shell>>
% svn_ignore something_new_file ./
<<--

svn:ignoreに設定されたファイルは、svn_newに出てこなくなります。

更新履歴

• 2007/12/14 CometのやりすぎでComitになっていたのでCommitに訂正。

debianで普通にsnmpdをパッケージからインストールすると、

pre>>

netstat -lnp | rak snmp

17|udp 0 0 127.0.0.1:161 0.0.0.0:* 13404/snmpd
<<--

このように、127.0.0.1にbindしてlistenするようになっているため、
プライベートネットワーク内のほかのサーバ
（cactiとかが動いているもの）から接続できません。

この辺の設定を変えるには、/etc/default/snmpdを
以下のように編集します。

pre>>
..(略)..

snmpd options (use syslog, close stdin/out/err).

SNMPDOPTS='-Lsd -Lf /dev/null -u snmp -I -smux -p /var/run/snmpd.pid 192.168.10.123'

..(略)..
<<--

192.168.10.123というのは適当な数字です。
あとはsnmpdを再起動しましょう。

新しいscriptとして、`script/performance/request`というものが 新たに加わったみたいです。 pre>> h% ./script/performance/request --help USAGE: ./script/performance/request [options] [session script path] -n, --times [0000] How many requests to process. Defaults to 100. -b, --benchmark Benchmark instead of profiling --open [CMD] Command to open profile results. Defaults to "open %s &" -h, --help Show this help <<-- ふむふむ。ベンチマーク系のスクリプトのようですね。 紹介してる記事を見つけました。 [**New in Rails: a request profiler for profiling your app**](http://blog.codefront.net/2007/10/26/new-in-rails-a-request-profiler-for-profiling-your-app/) >Jeremy Kemper (aka bitsweat) committed a very useful tool into the Rails trunk not too long ago: a request profiler! It’s a human-friendly wrapper script around the ruby-prof library, a nice ruby code profiler, that lets you run multiple requests against a URI in your application and get a detailed code profile report in text and HTML. おーなるほど。前回のRails勉強会で紹介した ruby-prof を human-friendlyにしてくれるツールですか。これは面白そうですね。 試してみようと思って触ってみたら、上のサイトで紹介されてる ものと、Rails 2.0で入ったものは若干インターフェイスが違う模様。 DHHが書いてる [こっちの情報](http://weblog.rubyonrails.com/2007/12/7/rails-2-0-it-s-done) が最新のようです（以下に抜粋）

**Action Pack: New request profiler** Figuring out where your bottlenecks are with real usage can be tough, but we just made it a whole lot easier with the new request profiler that can follow an entire usage script and report on the aggregate findings. You use it like this: $ cat login_session.rb get_with_redirect '/' say "GET / => #{path}" post_with_redirect '/sessions', :username => 'john', :password => 'doe' say "POST /sessions => #{path}" $ ./script/performance/request -n 10 login_session.rb And you get a thorough breakdown in HTML and text on where time was spent and you’ll have a good idea on where to look for speeding up the application. なにやらIntegrationTestのコードのようなものを記述したスクリプト を用意して、そのpathを渡せば良いみたいです。

基本はstableで使いつつ、ちょっと使ってみたい新しい
パッケージがある場合だけ、unstableから持ってくるような使い方を
する場合のaptの設定メモ。

まずはsources.listにunstableを追加。

/etc/apt/sources.list

pre>>
deb http://cdn.debian.or.jp/debian/ etch main contrib non-free
deb-src http://cdn.debian.or.jp/debian/ etch main contrib non-free

deb http://security.debian.org/ etch/updates main contrib
deb-src http://security.debian.org/ etch/updates main contrib

deb http://cdn.debian.or.jp/debian/ unstable main contrib non-free
deb-src http://cdn.debian.or.jp/debian/ unstable main contrib non-free
<<--

それがすんだら、優先度の設定を行います。

/etc/apt/preferences

pre>>
Package: *
Pin: release a=stable
Pin-Priority: 100

Package: *
Pin: release a=stable-proposed-updates
Pin-Priority: 110

Package: *
Pin: release a=unstable
Pin-Priority: 90
<<--

ついでに、キャッシュ容量の設定なども行っておきましょう。

/etc/apt/apt.conf

pre>>
APT::Cache-Limit "100000000";
APT::Default-Release "stable";
<<--

上記の設定ファイルファイルが無い場合は、新しく作成します。

これで完了。あとはapt-get updateすればOK。
必要に応じて、-t unstable オプションを指定して unstableの
パッケージを利用できます。

aptitude update したらこんなエラーメッセージが出たので、対処法をメモ。

/etc/apt/apt.conf.d/70debconf

ini>>
APT::Cache-Limit 100000000;
<<--

後は普通に aptitude update でOK。

SyslogLogger

SyslogLogger is a Logger replacement that logs to syslog.
It is almost drop-in with a few caveats.

SyslogLoggerを使うと、railsのログを syslog に記録するように
する事ができます。

###インストール方法

shell>>
% sudo gem install SyslogLogger
<<--

普通に rubygems としてインストールできます。
続いて、アプリケーションの設定を行います。

config/environments/production.rb

rails>>

SyslogLogger

require 'syslog_logger'
RAILS_DEFAULT_LOGGER = SyslogLogger.new 'appname'
<<--

appnameはアプリケーションを識別する名前に置き換えてください。

さらに、syslogの設定を行います。
rootになって以下の記述を書き加えます。

/etc/syslog.conf

!appname
*.*     /var/log/appname.log

修正が済んだら、空の/var/log/appname.logファイルを作成して
syslogdを再起動します（例えば killall -HUP syslogd）

これで、以後は /var/log/appname.log 及び /var/log/syslog に
ログデータが書き出されるようになります。