2015-01-28 Embulk-plugin-input-pcapng-files書いた
追記 (2015/01/29 20:03)
ver 0.0.2切った. ファイルのソート周りはまだ直してない.
https://rubygems.org/gems/embulk-plugin-input-pcapng-files
追記 (2015/01/29 19:49)
手元で動作確認してたらいつの間にか次のバージョンのembulkがリリースされてた. おかしいぞ…さっきのpullreqで入れてもらったワークアラウンド試し始めたばっかりなのに…(もう不要になった)
https://twitter.com/frsyuki/status/560750747608817665
追記 (2015/01/29 19:38)
frsyuki先生から後ろ方のてきとーなメモに対する, 大変丁寧なコメントを頂けた. なるほどなるほど.
https://gist.github.com/frsyuki/dcfb30690fd453542f45
ついでにいろいろと手直しして頂いて感謝感謝
- https://github.com/enukane/embulk-plugin-input-pcapng-files/pull/1
- https://github.com/enukane/embulk-plugin-input-pcapng-files/pull/2
はじめに
前々からやっているコミケその他イベントでの無線LAN解析(※)に良い感じに使えそうなので pcapngファイルからの入力を取れる “embulk-plugin-input-pcapng-files” なるプラグインを書いてみました.
中身はまんまtshark呼んでるだけですが, 抽出条件をコンフィグに書けたり出力先を柔軟に変更可能だったりと embulkのよさげなところを活かせそうなのが良い感じです.
今までは集めた多量のpcapngファイルを, ひとつひとつ真心()込めてスクリプトに食わせてたので これを期に自動化の流れが造れるとベター. またそこまで行かなくともこれまでに溜め込んだpcapngファイルの再掘り起こしが容易になるので それだけでも良い感じです.
正直pcapngをこんな感じに触りたい人いない気がするので, 誰にも使ってもらえない感…
使い方
コンフィグファイルはこんな感じになります. いわゆるguessはできないので手打ちで全部書く必要があります.
1 2 3 4 5 6 7 8 9 10 11 |
|
- typeにはpcapng_filesを指定します
- pathsには, 処理したいpcapngファイルが入ったディレクトリを配列で指定します
- threadsは, 並列度を指定します
- 上記paths内で見つかったpcapngファイルたちをこのthreadsの数に分配して並行に処理がなされる, はず
- ちゃんと動いてるかは未確認…
- schemaにはpcapng中の抽出したいフィールド名(name)と変換先の型(type)を指定します
- フィールド名は, wireshark/tsharkで -e オプションのfilterとして使っている名前が指定できます
- 型は今のところstringかlongのみ
これをpreviewコマンドで指定してみるとこんな感じ
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 |
|
- previewでは部分的なタスクしか実行されません (ここではtask5.pcapngがぬけている)
- runコマンドで出力される, “次の状態のコンフィグ”も出力されません
- ただし上記のように良い感じに表っぽい出力がなされます
実際にrunコマンドで走らせると以下の様になります
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
|
- -oオプションで実行中のコンフィグと同じパスを指定してやると, 元のコンフィグに「今処理したファイルリスト」を付け加えます
- 既にdoneが合った場合とか考慮してない等々で今はきちんと動いてない模様… (to be fixed)
- いわゆるcommit reportとして, 次回に重複処理しないように考慮 (したかった)
- outがstdoutになっているので, previewの様な表ではなくcsv形式で出力.
embulk弄ってたときのメモ
- embulkのREADMEをよめばだいたいどうにかなる。
- bundleコマンドで作成したディレクトリ以下でプラグインの新規追加・名前変更等したときは, 再度bundleコマンド発行すること
- 本来的にはinputプラグインではなくFile input内のparser/decoderプラグインとして造るべきでは?
- 処理対象のファイル一覧→スレッドへの分配あたりを再開発してる感
- input/output以外のプラグインがどの程度rubyで差し込みできるのかよく見えない. 要調査.
- file inputのメインのロジックはJava側で書かれてるようなのでbundle側からのインタラクション次第か?
- task to threadsのベストプラクティスが欲しい…
- transactionとrunの間のデータ受け渡し, これでいいのかな感
- 引数でスレッドローカルなオブジェクト渡すものだと思ってたけど…