前回記事ではHerokuのPlatformAPIを使用してリアルタイムにログを解析してグラフを作ってみたわけですが、やっぱり直近の1500行しかログが取れないとあんまりいい感じのグラフにならないわけです。(--
で、PapertrailにもWebAPIがあったことを思い出してそっちを使ってみることにしました。
http://help.papertrailapp.com/kb/how-it-works/http-api
ちなみに検索だけだけどラッパーAPIもあります。
http://oss.flect.co.jp/libs/ja/papertrailTool.html
このラッパー最初に作ったのは多分1年以上前だと思うけど、今見ると色々WebAPI進化してますね。。。
昔は検索以外のAPIなかった気がするけどいつの間にか検索条件の保存とか管理系のAPIもあるっぽい。
まぁ使うことはなさそうだけど、こうしたPaasサービスの提供する機能がなんでもAPIで叩けるようになっているのは良い傾向です。夢が広がります。(^^v
★APIでtail的なことを行う
これ非常に簡単です。
まず、検索APIをパラメータなしで実行するとJSONで以下のレスポンスが返ってきます。
- 含まれるログのIDの最小値
- 含まれるログのIDの最大値
- 直近のログ100件(生成日時、プログラム、メッセージなどが構造化されています。)
これに対して指定できるパラメータには以下のものがあります。
- min_id - 指定された場合このID以降のログを取得する
- max_id - 指定された場合このIDまでのログを取得する
- min_time - 指定された場合この日時以降のログを取得する
- max_time - 指定された場合この日時までのログを取得する
- q - 任意のクエリ(WebUIと同じ書式)
※min_time, max_timeはUNIX TIMEで指定
min/maxの指定でどこから、どこまでを取得するかが指定できるわけですね。ちなみに取得件数は常に最大100件で指定できないようです。
なので、最初にmin_timeを指定していつからのログを取得するかを決めたら、あとはそのレスポンスのmax_idを、次のリクエストのmin_idに指定してループをまわせば連続したログが取得できます。
ここでポイントとなることが2点あります。
min_idに指定したIDのログは結果に含まれない
min_idを指定すると指定したIDのログを先頭にしてそれ以降のログが取得されそうな気がしますが、実際には含まれません。
なので、max_idを次のリクエストのmin_idに設定する際には+1するとかの小細工は必要ありません。(PapertrailのログIDは連番ではないので+1しても抜けることはおそらくありませんが。)
結果が0件の場合でもレスポンスのmax_idは設定される
直近のログまで読んでしまったら、次のログがまだ存在しないということがありえますが、その場合でもレスポンスには最終行のログIDがmax_idに設定されます。
なので「結果が0件の場合に備えて前回のmax_idを取っておいて。。。」みたいなことをする必要はありません。
細かいことですが、この2つのおかげでtailライクなログ取得を組む際のロジックがシンプルになります。
★ログ解析アプリケーション
そんなこんなで、ログ解析アプリはPapertrailのAPITokenを入力すれば誰でも使えるようになりました。(^^v
http://flect-papertrail.herokuapp.com/
Herokuアカウントで使う場合は要求される権限の範囲が広すぎるため、試しに使ってみるのも抵抗がある気がします。開発環境で試してみたいけど本番環境まで一緒に見えちゃうよ！みたいな。
が、PapertrailのAPITokenであれば開発環境で試してみるということもできるので、気が向いた人は使ってみてくださいな。
□□□□
どうでもいいけどこのアプリ、最初に作ったのが今年の4月頃。そこからずっと放置してたのがこの数日でグラフ機能を追加。この先もまたしばらく放置の予定です。
これをトラブルドリブン開発(TDD)とでも名づけましょうか。(^^;
それでは良いお年を(^^)/