おがた (@xtetsuji) です。
ずいぶん以前に公開したんですが、Postfixのメールログを行指向にする maillog-hashnize.pl というプログラムをご紹介します。
もともと社内で使っていたプログラムだったのですが、数年前の当時、上司等に掛けあってたぶん初めて会社発OSSとして世に出せたプログラムです。公開方法も当時は最善策が思いつかず、個人アカウントでGistに貼りつけて公開という感じ。その際、会社の製品ブログで会社の取り組みとしてこれの紹介をしたのですが、いつの間にかその製品ブログ自体が無くなってしまったので、これを紹介する日本語の文章は無くなってしまいました。
紹介記事も無くなり、私もこのプログラムの存在自体ずっと忘れていたのですが、つい先日、海外の方からこれを使っている旨書かれた英語のメールをいただきました。その方の要求にぴったりだったようです。あまり英語が読めない私にも、賞賛する英単語の数々に恐縮してしまうくらいでした。また「私はPerlプログラマーではなくて自力ではできないものの、こういった機能が欲しいのです」といった内容も書かれており、かつそれが私にとって妥当な機能拡張であると思えたので、それに関して対応する旨返信も行いました。
実際、Postfixのログをどうにかしてくれるプログラムがないか検索してみると、pflogsumm 等の「集計やサマリーを出してくれるプログラム」はあるのですが、Postfixのmaster配下の各デーモンが出力したログの行をキューIDで束ねて一通のメールがどうなったかを一行にしてくれるプログラムというのは珍しい存在でした。今現在探してもなかなか見つからないんじゃないでしょうか。
しかしながら私の業務では、こういう行指向に修正するプログラムの必要性がありました。一通一通のメールがどのような経緯でサーバに入ってきて、どのような最終処理がなされたか、開発者以外の人と詳細を議論するための見やすいデータを出力する必要があったのです。その時に活用されるアプリケーションは大体Excelになります。
以前は、MySQLやPostfixの業界で著名な「とみたまさひろ」さんという方が、この要望に合うRuby製のpflogというツールを公開していて、業務ではずっとこれを主に使っていたのですが、Postfixのバージョンが上がってPostfix2.3以降のログを入力すると謎のエラーが出るという現象に出会いました。原因を調査して納得したんですが何だったかな…。
そんなこんなで、Postfix2.3以降の対応を含めて、かつオリジナルのpflogにあったバークレーDB出力機能などの滅多に使わない機能を削ったPerlプログラム maillog-hashnize.pl を作成しました。pflog同様、キューIDで行指向に一行に束ねてCSVファイルとして出力します。pflogで時々ハマったExcelのデータ誤認対策も色々と入れました。
RubyのプログラムをPerlに書きなおしたのはいくつか理由があって
- 各所でDebianを使っていた都合、システムPerlの存在はRuby以上に身近だった
- 生粋のPerlの会社なので、各種作業サーバにRubyインタプリタ自体が入っていなかった
- RubyよりもPerlのほうが行読み込みや正規表現のパースが若干速かった
- 今後機能拡張をするときRubyの知識が足りない事がネックになるのを心配した
という理由でした。特にRubyが嫌いだったわけでもなく、自分のRubyの勉強の教材になればいいかなとも思ったのですが、その時と将来的な事を考えて、一気にPerlに移植することにしました。社内にいるプログラマーの数が片手で数えられるほど少ないことも、個人的趣味を越えて不必要に社内採用プログラム言語を増やせない理由でした。機能拡張の要望があったときに業務では迅速に対応する必要がありますので。
私が思うに、Rubyが行読み込みや正規表現パースのパフォーマンスでPerlに劣るのは仕方が無いことで、Rubyのオブジェクト生成のコストやPerlの狂ったほどの正規表現チューニングが要因としてあるでしょう。実際にベンチマークを取った結果はほとんど優位な差は無かったのですが、業務では数千万行から数億行のログを処理する必要があったので、軽微な差が及ぼす時間的コストの違いは無視できませんでした。
後輩に業務を引き継いだ後は、会社のリポジトリ内の maillog-hashnize.pl を触ることはなくなりましたが、業務でもときどきこのプログラムが使われているようです。
とりあえずライセンスはArtisticとGPLのデュアルライセンスなので、私のほうでforkして、外部で使ってくださる方向けに機能拡張をしていこうと考えています。基本機能としてpflogとの互換性が保てれば色々と都合が良いので、その方向で拡張をしていきます。良い結果が出たらまたブログでご紹介します。
本日検索して、初めてこのスクリプトを見つけました。
非常に便利が良く、これから活用させていただきます。ありがとうございます。
私の場合には、postfixで転送していますので、元々のtoが分かるように、orig_to=<のカラムを追加させていただきました。
75c75
for my $key ( qw(from to orig_to) ) {
144a145
> original to
160c161
@$q{qw(client_hostname client_ipaddr from to orig_to message-id status relay delay size information)});
村上さま
maillog-hashnize.pl お使い頂きありがとうございます。お役に立てたようで嬉しいです。
確かに orig_to も重要な情報ですね。私も現在の会社でメーリングリストサーバの運営をしていて orig_to を見ることがしばしばあります。今の機能で長く使われている maillog-hashnize.pl なので本体自体への改修をどうするかは未定ですが、何らかの方法で orig_to 等のノウハウも反映したいです。