tenshiとは
サーバ上のログファイルは、ただ記録しておいて問題があったときの調査に使うだけではなく、リアルタイムで監視することでアプリケーションやサーバの不具合の早期発見をすることができる。問題が表面化する前に対策を行なうにはログの監視が不可欠だ。
しかし、サーバは、種類も数もどんどん増えていくものだし、それに合わせログファイルの種類も量もどんどん増えていく。全部見るのはもちろん不可能だし、適当に通知をしてもメールボックスを溢れさしてしまうことになり、結局は無視することになってしまい意味がない。
そこで、賢く効率的に監視するために tenshi というツールが非常に便利に使える。
このツール、最近しばらく使っていなかったのだが、最近会社で再び使い始め、便利さを再確認したので紹介してみる。知る人は知るツールだと思うけどいまいちマイナーなのかな？
tenshiは、元々はGentoo Linuxプロジェクトのインフラ用に作られたものなのだけど(だったと思う)、今では色々なLinuxディストリビューションや、*BSDのパッケージに入っているようだ。うちではFreeBSDで使っている。
tenshiの基本的な動作
- 指定したログファイルを常時監視 (最近ではsyslogサーバとして動くモードもあるみたい)
- 設定した条件にマッチした(またはマッチしない)ログが現れたら、指定したタイミング(リアルタイム/毎時間/毎日とか)でメールで指定した管理者に通知
tenshiの優れている点
- とても小さいツールで導入や設定が簡単。設定ファイルを一つ書くだけ。
- ログのマッチングルールは正規表現なので柔軟。どんな形式のログファイルでもテキストファイルなら対応可能。
- メール通知する頻度をマッチングルール毎に変更できる。たとえば「多分重大なエラーではないけど、一日に一度くらいは受け取って眺めておきたいようなログ(例えば、Webサーバの404 Not Foundエラーのログとか)」の指定ができる。
- 同じようなエラーをまとめてくれる。同じエラーが大量に出たときでもメールボックスが溢れにくい。
tenshiの運用
もちろん、各サーバにtenshiを入れてもいいのだけど、うちでは、ログサーバにsyslog経由でログを集め、そこでtenshiを動かしている。監視対象は、Railsアプリケーションのログや、データベースのログ、OSのログなど広い範囲。
また、tenshiのマッチングルールは、ホワイトリスト方式で運用している。つまり、とりあえず最初はすべてのログを通知。そして無視できるものをホワイトリストとしてどんどん追加していく。
この方法だと「未知なログ」を闇に葬ることなくしっかり通知してくれるので、予期しない不具合の兆候(ってだいたいそうだよね)を見逃すことなく通知してくれる。
tenshiの設定
- 一つ以上のqueueを作成する。queueは正規表現でマッチしたログを突っ込む場所。queue毎に通知先のメールアドレスや通知タイミング(その場で通知や、1日1回通知とか)を設定できる
- 通知させたいログを正規表現でマッチさせqueueまたはtrashに突っ込む。trashは見なくてもいいログの宛先。
詳しくは http://www.inversepath.com/tenshi_man.html 参照。
おわり
流行りのかっこいいツールとかもいいけど、こういうプロジェクトの地固め的なツールも大事ですね。
記事の内容についての質問、苦情、間違いの指摘等なんでもtwitterでどうぞ。 Tweet
RSSリーダで読む