ふとTiarraでとったIRCのログをBigQueryに流し込むようにしたら手元にログを長期間残す必要もないし、検索もできるし便利そうだなと思ったので設定してみました。Twitterのログもあって若干流れますがBigQuery的には誤差の範囲レベル(1日1MB程度)なのでStreaming Insertして、たまーに検索しても無料枠で余裕で収まりそうです。

主な流れはTiarraで吐いたテキストログをfluentdのin_tailで読んで、fluent-plugin-bigqueryでBigQueryに流し込むという何の変哲もない形です。

Docker

ですでに手元のTiarraはDocker(docker-compose)で起動しているのでfluentdもDockerで起動しています。fluent-plugin-bigqueryはfluentdの公式イメージに追加する必要があるので適当に追加します。

FROM fluent/fluentd

RUN apk --no-cache --update add ruby-bigdecimal ruby-dev build-base && \
    fluent-gem install fluent-plugin-bigquery

ruby-bigdecimalが必要ということはREADMEにあるのですが、ruby-devとbuild-baseも必要で追加していないとfluent-plugin-bigqueryをインストール中にstrptimeのビルドで失敗します。

BigQuery Schema (schema.json)

次にBigQueryのスキーマを用意します。今回は次のようなものになっています。

[
    { "name": "Time", "type": "TIMESTAMP" },
    { "name": "User", "type": "STRING" },
    { "name": "Server", "type": "STRING" },
    { "name": "Room", "type": "STRING" },
    { "name": "Text", "type": "STRING" }
]

テーブル自体はこのスキーマを使ってfluent-plugin-bigqueryに自動生成させるので、BigQuery側にはプロジェクトとデータセットだけ作っておきます。このスキーマファイルは次のfluent.confと同じところにおいてください(最終的にdockerでマウントされるところ)。

fluentd (fluent.conf)

最後にfluentdの設定です。

source(入力)はssig33 - Tiarra のログを fluentd で流すを参考にin_tailを設定します。手元ではTIGのログが流れてくるのとサーバー名を分解するために少し変更しています。ログはローテートされるので %Y.%m.%d.txt で。

出力はfluent-plugin-bigqueryの設定を auto_create_table で設定します。これ自体は何のことはない設定なのですが table を年で分けるようにしようとしたところでハマりました。

table にはプレースホルダ文字列を使えることになっているのですが、文字列置換が有効になる条件としてまず buffer time/timekey を設定しているというものがあります。そこで timekey を設定すると %Y ではなく %d 精度のプレースホルダを持つ設定を要求します(参考: output.rb)。しかし今回は%Yでいいのに…困った…と考えた末に fetch_schema_table という使っていない設定項目に log_%Y%m%d 入れて回避しました。

とはいえ真面目にBigQueryを使うレベルなら日別にすると思うので(扱いづらいし…)罠にははまらないとは思います。日付パーティションにしてもいいかもとか頭をよぎりますが量も大してないので最悪あとで何とかすればいいでしょう(適当。

<source>
    @type tail
    path /fluentd/log/tig/tig-twitter/%Y.%m.%d.txt,/fluentd/log/ircnet/*/%Y.%m.%d.txt,/fluentd/log/freenode/*/%Y.%m.%d.txt
    tag tiarra
    
    format /^(?<time>[^ ]+)\ (<(?<room>[^ ]*)@(?<server>[^ ]*):(?<user>[^ ]*)>|\((?<room>[^ ]*)@(?<server>[^ ]*):(?<user>[^ ]*)\)|>(?<room>[^ ]*)@(?<server>[^ ]*):(?<user>[^ ]*)<|-(?<user>[^ ]*)-|>(?<user>[^ ]*)@[^ ]*<)\ (?<text>.*?)(?: \u0003\d+\([^)]+\).*)?$/
    time_format %H:%M:%S
</source>

<match tiarra>
    @type bigquery

    method insert

    auth_method json_key
    json_key /fluentd/etc/serviceaccount_key.json

    project <YourProjectName>
    dataset <YourDataSetName>
    table Log_%Y

    auto_create_table true
    schema_path /fluentd/etc/schema.json

    # table でplaceholderを使うために必要
    # buffer time/timekeyの設定が必要でそのためにplaceholderの%dをもつ設定が必要なので使わない項目をダミーとして使う…
    fetch_schema_table log_%Y%m%d

    <buffer time>
        timekey 1d
    </buffer>
    <inject>
        time_key time
        time_type string
        time_format %s
    </inject>
</match>

あとはこれでfluent/fluentd-docker-imageを参考にDockerでマウントしつつ起動すればログがBigQueryに良しなに送られます。便利。

以前からWi-Fiの電波の届き具合があまりよくないなと感じていて、アクセスポイントもAterm WR8500Nなので10年前のものだし、それ一台(途中で中継器を足したけど)で一軒家をカバーするのもまあ厳しいしもういい加減変えてもいいでしょう…。ということで、電波の届き具合で悩んだのでやはりここはメッシュWi-Fiにしてみようと思いTP-Link Decoを設置しました。

メッシュWi-Fiは一つのネットワークを複数のユニットでいい感じにカバーする仕組みらしいです(雑な説明)。まあ賢いローミングシステムをお手軽に構築できるものって感じでしょうか。Google Wi-Fiなどもこの手の製品ですね。Decoはスターターキットとして3つのユニットがセットになっています。

とはいえ個人的にはTP-Linkにはいろいろ思うところがあり、C5400を買ったときのメモを見ていただくとお察しいただけるかと思いますがブリッジモード(APモード)ではまった経験と最近話題のNTPサーバーへのアクセスの件もあって、正直心象はよくなかったのですが選択できる製品もあまりなく。あとから調べたらASUSのWi-Fi ルーターは組み合わせてメッシュを組めるとか…でもEthernet Backhaul相当があるのかはわからないですね。NETGEARのOrbiは2+1だとちょっとお高いです。

実際設置してどうだったのかというと安定のTP-Linkクオリティです(ほめていない)。今回もまたブリッジモード(APモード)で設定したのですが、とにかくちゃんと設定して安定して動くまでが怪しい…。

怪しかったのは次のようなところ。

• ユニットの追加セットアップしていたらなぜかネットワーク設定が消える
• ユニットの追加セットアップしたらなぜか同じ名前の別なネットワークが生み出される
• ユニットがネットワークから外したり、追加するとネットワークがしばらく不安定になる
  • 追加したのとは別なユニットが切断状態になって、しばらく待っていると復帰する謎
• ユニットがオフライン扱いだけどつながっている
  • 再追加すると上記の通りしばらく不安定になるのであまりやりたくない…
• プライマリとなるユニットがいるはずなのですが区別つかない
  • 最初ルーターモードから切り替えたときはゲートウェイって表示されていた
• 何が悪いのか見るすべがないのでエスパー力を問われる
  • Ethernet Backhaul してるのが悪いんじゃないか説?(追記あり)
  • 単に接続待ち?

良かったところは設定の手順自体は簡単だったり、ネットワークが安定すれば切り替えもまあまあスムーズだし、Backhaulしているおかげでどこにつないでも速度が出るというあたりでしょうか。C5400の時と同じで一度動けばWi-Fiは優秀みたいな…。

なんというかTP-Linkのルーターのブリッジモードはやっぱりやめた方がいいんじゃないかというのを改めて感じますね。Ethernet Backhaulせず、ルーターモードで使う分にはサクッとネットワークを組み立てられそうですが、ブリッジモードはある程度苦労を覚悟することをお勧めします。

まあとりあえず電波が家中に届くようになってなんとなく動いているので結果オーライということで。

追記(2018-01-03): どうやらEthernet Backhaulが鬼門らしく、ブリッジモードでEthernet Backhaulを有効にしたDecoユニットを追加すると謎の再起動や参加失敗(オフライン扱いになったり消えたりする)が発生するのでEthernet Backhaulを一旦諦めました。詳しくは検証していないのですがどうもスイッチと相性が悪い場合に似たようなことが発生するらしくそれかもしれません。

フォーラムの書き込みによるとD-Linkの一部スイッチはIEEE1905.1 プロトコルをうまく通さないため問題(リブートループ)が出る場合があるという話があり、D-Linkのスイッチではないものの手元も似たような現象なので原因は同じかもしれません。もし不安定なようであればスイッチを外してEthernet Backhaulを試していくのがよいようです。