アクセスログビューワーAkariを作った
はじめに
ISUCONなどに参加する際に今まではログビューワーとして、Nginxのログを見るのにkataribe、MySQLのログを見るのにはそれ用のtraceを吐くツール、そしてそれらをWeb上でログストリームごとにまとめたりジャンプできるようにするためのこれまた別のツールを使っており、都合3-4ツールを入れないと十分にログが見れない状況だった。
また、kataribeにしてもMySQLのanalyzerにしてももうちょっとカスタマイズしたいなあと思うことがいくつかあり、それぞれのツールにcontributeしてもよかったのだがこの際全部入りのやつを自分で作ってしまってもいいかなと思って作った。
ツールの名前はAkari。(ChatGPTに考えてもらった)
使い方はREADMEを読んでもらうとして、これを作るにあたって気にしたところと工夫したところについて書く。
diffについて
ISUCONをやっていると基本的にログを見る→改善→ログを見るをずっと繰り返すことになるので、ログの見やすさはかなり大事かなと思っている。
特に、「MySQLでindexを貼ったつもりで貼れていない」「改善したけどスコアに影響していない」というようなことは度々あって、こういう事象に気がつくために今のログと1つ前のログを並べてみたい需要が結構あったので、diffを入れるとこういう事象にも対処がしやすいのではないかと思って入れることにした。
カスタマイズ性について
ISUCONだけにしか使えないのももったいないかなと思ったのと、nginx/mysqlだけをサポートするCLIもニッチすぎるかと思ってTOMLで割と自由にカスタマイズができるようにした。
イメージとしてはパース部分とクエリ部分に分かれている感じ。パース部分はregexpで差し替えられるようにして、ログレコードを1行ずつ拾って指定した構造にパースしていく。クエリ部分はSQLのような感じで、どのカラムをベースにどんな集約関数を使うかを宣言するというようなイメージで作っている。このパース部分とクエリ部分の基本的な設定値を全部TOML経由で拾うことで、view部分はほぼほぼカスタマイズが可能となった。
これは何かを目指してこうしたというよりは、単になるべく汎用的なツールにしようと思っていたら自然とこうなった、が正しいかもしれない。
おかげで、上記に書いたnginxのログもmysqlのログも、対象としているログの形式もみたいデータも違うが、設定を書くだけで両方対応できるようになっている。
ロググループのディレクトリ構造について
ISUCONではもちろんログファイルがたくさん出てくるのでそれらをディレクトリに入れて管理することになるが、Akariで前提とするディレクトリ構造をどうするかは結構迷うところがあった。
Akariが必要になるケースはほぼログファイルがたくさんあって、時系列になっていてそれをしかも比較して見たいということで、サービスのパフォーマンスチューニングをしているとかそういうケースに限られるとは思う。
そのため、まあここはそこまで汎用性を持たせたところであまり意味がないだろうと割り切って、ログファイルは必ずディレクトリに入れてもらい、さらにディレクトリは時系列ごとに並んでいる(文字列でソートするとそれがログファイルの時系列順に並ぶ)という前提を課すことにした。
まぁうちのチームのログのセットアップがそうなっているのでそこの前提はあまり変えたくないなあという理由ももちろんあるが、たとえそうじゃないケースでもdateコマンドで生成した名前のディレクトリにログファイルを放り込むくらいは苦でもないだろうから良いだろうという判断もある。
今後の機能について
パーサーがregexpで書かれることしか想定していないので、jsonのパーサーとか、ltsvのパーサーとかをregexpではなくて専用の構文で書けるとかがあったらもうちょっと便利かも、と思っている。
あとは本当はあるAPIへのアクセスの状況が何秒ごろにどれくらいあるかとかをSVGでグラフにして可視化できると面白いと思いつつできていないのでそれも余裕があればやりたいなと思っている。
一応、timestampをベースに秒ごとにアクセス件数をテーブルに出すのはやっているので、そんなに大変ではないかもという気もしている。
あとはそもそも作ったはいいもののまだパフォーマンスチューニングの場面で実践投入できていないので、その辺りで使いつつ試せたらいいなと思う。
(余談)前回のISUCONはあまり結果残せなかったので次回はこのツールもできれば活かして頑張りたい所存。
Discussion