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 参照。

おわり

流行りのかっこいいツールとかもいいけど、こういうプロジェクトの地固め的なツールも大事ですね。

Tweet

前回書いた さようならPuppet、こんにちはChef が、それなりに反響あったので調子に乗ってもうちょっと書いてみる。

前回、ChefはPuppetに比べて簡単！とか書いたが、実際には慣れるまでそれなりに戸惑うところがあった。

ドキュメント を読み、実際に触っただけでは一発で理解できなかった部分を、自分のメモを元に晒しておく。これだけ読んでもいまいちだと思うので、関連するドキュメントへのリンクも張っておくので合わせて読んでみると高速でChefを理解できるかも！

client vs node

• Chef Client
• Nodes

ドキュメントを読んだりChefを触っていると client と node という二つのワードが出てくる。この二つは似ているけど別物。

client は文字通り Chef server の相手になるもの。 Chef server にアクセスするものはすべて client になる。例えば、管理ツールである knife (後述)や、管理用のWeb UIなども client になる。認証や通信はすべて client が Chef server と行う。

一方、 node というのは、Chefで管理するマシン/サーバ自体を指す。各 node は Chef server にアクセスし自分の設定を持ってくるのが、これは実際には node にある client 経由で行う。

そのため通常は node は client でもある。そして、 client数 >= node数 になる。

書いてしまうと簡単なのだけど、最初は両者がごちゃごちゃになってしまっていた。ここをしっかり理解しておくとトラブルシューティングもしやすくなる。

トラブルシューティングの例:

ある node (の client )で、サーバにアクセスするのに必要な秘密鍵を間違って消してしまい Chef server へのアクセスができなくなってしまった。この場合どうすればいいか？

対応策: 鍵情報は client に結びついているので、 client の鍵ペアを作り直せばいい(または、 client をサーバから削除して作り直す)。 どちらの場合も、 node の情報をいじる必要ない。

knife

• Knife

Chefサーバ上にあるデータを触るためのコマンドラインツール。主に手作業でサーバの情報にアクセスしたいときに使う。管理者が使用するもの。上に書いたように knife 自体も client になる。管理者毎に別の client として登録する。

特に、 node の情報は、他の設定と違いサーバ上にしかないので、このコマンドをよく使う。

例1： node の情報(JSON形式)を $EDITOR で開き編集する

$ knife node edit hogehoge.example.com

例2： 指定した client を削除

$ knife client delete fugafuga.example.com

node と cookbook (recipe) と role

• Cookbooks
• Recipes
• Roles

まず、 node は、上にも書いたように管理対象のサーバのこと。

cookbook は、実際にChefで行いたい設定の手順を記述したもので、基本的に環境に依存するのものは書かない。依存するものは role や node の attributes に書く(後述)。

recipe とは、設定を記述したrubyスクリプトのことを指す(ドキュメント等で cookbook のことを recipe と呼んでいるケースもあるので注意)。

一つの cookbook は複数の recipe を持つことができる。例えば， LDAP cookbookの中に、 LDAPクライアント用の recipe と、LDAPサーバ用の recipe を持つことができる。

role は、サーバの役割を記述したもの。 どの recipe を使うかということを主に書く。また、 node は、基本的に1つ以上の role を持つ。ただし、ちょっとややこしいが、 node は recipe を role を介さないで直接持つこともできる。

たとえば、 “hoge-system-app” role というのを考えてみる。これは “hoge-system” という Webシステムのアプリケーションサーバを想定する。

ここで、

• hoge-system-app1.example.com
• hoge-system-app2.example.com
• hoge-system-app3.example.com

という3つの node があったとする。3つとも、"hoge-system-app" role を持つ。ただし “hoge-syste-app1.example.com” だけは、特別に、"git" クライアントも入れたい。こういう場合には、gitの recipe を直接指定することもできる。

• hoge-system-app1.example.com
  • hoge-system-app role
  • git recipe
• hoge-system-app2.example.com
  • hoge-system-app role
• hoge-system-app3.example.com
  • hoge-system-app role

もちろん、gitの recipe を持つような、 developer role みたいのを作り、それにgitを持たせ、 node にセットすることもできる。

基本的には、 role 経由で管理したほうがいいが、本当に例外の場合はわざわざ role を作らなくてもいいかもしれない。これは設計次第。

attributes

• Attributes
• Templates

attributes は、実際に設定したい値(パラメータ)のこと。上述したように、 cookbook / recipe には、サイト固有の情報を持たせないのが原則なので、そういうものはすべて attributes にして外出しにする。

attributes は recipe 自体や、 recipe 経由で template (erbで記述) から使われる。基本的にrubyのHashそのもの。

attributes は recipe にも設定できるし、 role や node にも書ける。

recipe に書いた attributes がその recipe のデフォルト値で、それを role や node の attributes で必要に応じて上書きする、と考えると理解しやすい。

例：まず、 tokyo-office という role があったとしよう。とある東京オフィスにあるサーバ群はこの role を使うというルールになっている。今、この role に対して、LDAPクライントを設定したいとする。

最初に、LDAP cookbook ( recipe ) を作成する。このとき、LDAPサーバのホスト名(IP address)みたいなのがサイト固有の情報になるので、 attributes に切り出す。

次に作成した、 recipe を tokyo-office role に設定する。このとき attributes として切り出した LDAPサーバの IP addresses を role の attributes ととして設定する。

ここで、もし、その中のある、特定の node だけに対して例外的に特別な値(例えば、テスト用のLDAPサーバを見させたいとか)を書きたい場合には、 その node の attributes に書いて、 role の attributes を上書きする。

自分が理解しているのはこんな感じ。enjoy cooking!

Tweet

ここ最近、サーバの設定ファイルの管理で Chef を使い始めている。まだ全然詳しくないけど、今感じている「Chefの楽しさ」を誰かに伝えておきたかったので、ファーストインプレッションを簡単に。

Puppetを今までそこそこ使っていたので、どうしてもそことの比較な感じになっちゃいます。Puppetも良いのだけど、Chefは後発ということでさらに良くなっている感じ。

基本的な仕組

これは、Puppetとほぼ同じ。クライアント-サーバ型のシステム。設定を書き、それをサーバに置いておく。クライアントはサーバと接続し、自分自身の設定を書き換えたり、必要なソフトウェアをインストールしたりする。

rubyな設定ファイル

Puppetは基本的に独自DSLで設定ファイルを記述すので「覚えるのがめんどくさい」「細かいこと、ちょっと無茶なことをしようとすると大変」。Chefの設定ファイルはrubyそのものなので、rubyで表現できることは何でもできる。とは言えDSL風にもなってるのでrubyを知らなくてもなんとかなるレベルでもある。その辺はさすがにruby。実際にどんな感じで設定を書くか、というのは、 この辺参照 。

ローカルでのテストが楽

chef-soloというコマンドがあり、これを使うとChefサーバに接続せずにローカルだけでテストができる。大袈裟なテスト環境を作らなくても自分の環境でテストできるのがとても楽。

設定ファイルが直感的

Puppetは、manifestとかmoduleとかclassとか、どうも最後まで慣れなかったが、Chefは初めの数時間で、すーっと頭に入ってきた。この差はでかい。

いくつかの理由があるけど、まず、設定ファイルのディレクトリ構成がわかりやすいというのが大きい。

設定ファイル内の主要なディレクトリは、cookbooksとrolesの二つだけ。cookbooksの中には、cookbookと呼ばれるソフトウェア毎の設定を置くサブディレクトリがある。一つのcookbookに関連する設定はそのサブディレクトリ内にすべて置く。

例:

cookbooks
  + sshd
    + recipes
    + templates
    + attributes
  + sudo
    + recipes
    + templates
    + attributes
  + apache2
    + recipes
    + templates
    + attributes
  + .....
roles
  + hoge_app.rb
  + hoge_rproxy.rb

この「cookbook内で完結し独立している」というのがとても扱いやすい。完結しているので、自分で管理するのももちろん楽だけど、他の人や会社がが作っているcookbookの流用もしやすい。 Chef公式のcookbook はもちろん、 37 signalsのcookbooks もよく参考にしている。

roleは、どのcookbookをどういう設定で使うか、というのを書く。そして作成したroleを実際のサーバに割り当てる。一つのサーバが複数のroleを持つこともできる。このroleとcookbookという関係もとてもわかりやすい。

各roleの中にはどのcookbookを使うか、というのを羅列する。例えば，

run_list "recipe[apache2]", "recipe[apache2::mod_ssl]", "role[monitor]"

みたいな感じ。そして、cookbookに対する設定もrole内に書く。

default_attributes "apache2" => { "listen_ports" => [ "80", "443" ] }

(このサンプル から引用)

こんな感じ。とってもわかりやすいでしょ？

Git等との距離感

設定ファイルはもちろんGitとかで管理するのだけど、それと実際のChefの動作部分は特に関係ない。設定ファイルを書き換えた後commit/pushで設定の反映ではなく、rake upload_cookbooks 等のコマンドでサーバへ反映。これがなかなか気持ちいい。ソフトウェアをdeployする感覚と似ている。

よくわかってないところ

サーバ側の設定は 弊社のすばらしいシステム管理者の人 がしてくれたので自分はよくわかってない。結構ややこしいみたい。

嫌いなところ

SEO的にどうよ、な部分。Chef自体もそうだし、出てくる単語もcookbookとかrecipeとかknifeとか、ぐぐるの大変だよ！

そんなわけで

とりあえず使い始めてみましたよ。という感じです。

追記: もうちょっと書いた。

追記2: chefのプレゼン資料のようです。わかりやすい。

Tweet