fluentdでBigQueryにログを送る設定とハマった時のTips

fluentd触ったことなかったので所々ハマってしまったのと、ハマった時こうデバッグしましたみたいのをメモにしておく。 にしてもfluentdよくできてると思った。 fluentdのイベントサイクルに関してはこのDocがとにかくわかりやすい

docs.fluentd.org

fluentdを起動して設定ファイルがあっているかとか、必要なプラグインがインストールされているかとかは一旦実行してみるといい。

$ fluentd -c fluent.conf

ハマりポイントを回避する１つの手段として、急に設定ファイルを頑張って書き始めないことだと思った。この記事でいうと「fluentdでBigqueryにログを投げる」という設定になるんですが、まずは導通テストをするのをオススメする。 fluentdは、sourceで指定したデータソースからmatchしたものを設定ファイルに基づいて出力するものなので、例えばこんな感じ。 インフラエンジニアとかにとっては当たり前なのかもしれない。アプリケーションエンジニアでいうところの、puts 'hogehoge'だろうなと思った。

<source>
  type forward
  port 24224
</source>
 
<match **>
  type stdout
</match>

24224ポートで受け取ったログソースで、**（正規表現でいうところの全て）をstdout(標準出力)するものなので、少なくともアプリケーション側でログを投げるようにしてfluentdを起動すれば受け取るログ全てを出力することになる。ここで、何もログが測れないのであれば何がおかしいかの調査のスコープを狭くできるのでおすすめ。

fluentd -> Bigquery

fluentd -> Bigqueryに関してはgemがあってこちらを使用させてもらった。

github.com

documentationも充実して素晴らしいOSSです。 サーバー側でgemをインストール

$ fluent-gem install fluent-plugin-bigquery

ストリーミングインサートするならばこんな感じで素直に動く。

<match dummy>
  @type bigquery_insert

 auth_method json_key
    json_key {
        "private_key": "private_key_from_gcp_account",
        "client_email":"email from gcp account"
    }

  project yourproject_id
  dataset yourdataset_id
  table   tablename

  schema [
    {"name": "time", "type": "INTEGER"},
    {"name": "status", "type": "INTEGER"},
    {"name": "bytes", "type": "INTEGER"},
    {"name": "vhost", "type": "STRING"},
    {"name": "path", "type": "STRING"},
    {"name": "method", "type": "STRING"},
    {"name": "protocol", "type": "STRING"},
    {"name": "agent", "type": "STRING"},
    {"name": "referer", "type": "STRING"},
    {"name": "remote", "type": "RECORD", "fields": [
      {"name": "host", "type": "STRING"},
      {"name": "ip", "type": "STRING"},
      {"name": "user", "type": "STRING"}
    ]},
    {"name": "requesttime", "type": "FLOAT"},
    {"name": "bot_access", "type": "BOOLEAN"},
    {"name": "loginsession", "type": "BOOLEAN"}
  ]
</match>

schemaに存在しないカラムがあったりするとBigQueryではエラーになるので、どういうログを扱うかにもよるかもしれないですが、ignore_unknown_valuesのオプションはtrueにすると良さそうだった。

References

fluentdの学習に以下のドキュメント、記事が本当に勉強になりました。素晴らしい記事を公開していただいていることに感謝しています。

Fluentdを使うアプリケーションの導通テストにstdoutプラグインを使う。 | 三度の飯とエレクトロン

Life of a Fluentd event - Fluentd

Fluentd と BigQuery を使用したリアルタイム ログ分析  |  ソリューション  |  Google Cloud

td-agentからデータをBigQueryに入れる | Simple is Beautiful.

Install by Ruby Gem - Fluentd

９月の勉強会記録

前回同様に勉強会をした。 最近、AWSでインフラ構築をメインに勉強しててそろそろポチポチするの疲れてきたのでInfrastructure as codeにしたがってTerraformを勉強することにした。 めちゃ評判良かったのでこの本を買って色々手を動かしてみた。

実践Terraform　AWSにおけるシステム設計とベストプラクティス (技術の泉シリーズ（NextPublishing）) 野村 友規 https://www.amazon.co.jp/dp/4844378139/ref=cm_sw_r_tw_dp_U_x_sEhKDbZNYZJDN

インフラ構築を勉強する中で今までポチポチやってたのがコードを書いて管理できるので随分楽になった気がするし、TerraformのことだけではなくAWSでインフラ構築する上でのベストプラクティス的な事も扱ってくれているので本当に勉強になった。Terraformでインフラ管理する上でディレクトリ構造等も考えないといけなくなるんだろうとは思うんですがこの本ではモジュール設計に関しても書かれているので僕みたいな初心者だけでなく中級者くらいまでも勉強になる印象があります。

Webアプリケーションエンジニアとしてのキャリアは今後も育っていくのだろうけど、インフラ面に関しては力を証明できる何かがないのでせっかくだし、AWSのソリューションアーキテクトアソシエイトを取得しようという感じにして宣言してきた。 １０月は試験勉強して１１月頭くらいに受けるためにとりあえず申し込みだけしてみる。

今月も良い会となった。

「Amazon Web Services 基礎からのネットワーク&サーバー構築」を読んだ

世の流れ的にもDevOpsとかいってアプリケーションエンジニアとインフラエンジニアの見るべき範囲が曖昧になっている中で、個人的にインフラの知識が無さすぎてインフラ周りを見る力がないので 連休使って勉強する事にした。インフラ得意な同僚のオペレーションが理解出来ないみたいな事も死ぬほど悔しいのでそういう意味も込めてるのもある。

Amazon Web Services 基礎からのネットワーク&サーバー構築 改訂版 玉川憲 https://www.amazon.co.jp/dp/4822237443/ref=cm_sw_r_tw_dp_U_x_dfJHDbT4XNSD6

この本が良いよと聞いてたので、金曜日に買って土曜日１日使ってて動かしながらAWSでサーバーを構築できた。 控えめにいっても本当に良い本だったので、「インフラ初心者、アプリケーションエンジニアだけどもっとインフラの事知りたい」みたいな人に心からオススメしたい。 逆にインフラエンジニアとして普段AWSを触って一年くらいたったみたいな人には物足りなさがあるので、もっとIntermediateな本を読む方がいいかもしれないです。

何がそんなにいいのか？

普段、ざっくり理解してる事をAWSを通じて、きちんと理解できる。 例えば、

  • TCP/IP
  • HTTP
  • VPC
  • サブネット
  • セキュリティグループ
  • CIDR
  • DNS

とか。普段、インフラエンジニアが既に構築したものにコードを乗せてるし、SSHに使ってるパブリックDNSなんかも開発環境のセットアップで自動で.confに設定しといてくれるのであまり意識して考えた事なかったので自分でポチポチ構築してみると「なるほどな」と思うところがたくさんあった。一番収穫だったのは、「なんかSSHできない」とか「なんかプロキシに繋がらない」とかの時に確認すべき場所が分かりそうだなと思えた事でした。

この本を通して、構築したのが以下の構成のブログシステムとなった。 VPCにプライベート、パブリックのサブネットを引いて、パブリックにEC2にApacheをインストールしたWebサーバー。プライベートにEC2にMySQLをインストールしたDBサーバーを構築した。プライベートサブネットからはNATゲートウェイを使ってインターネットへ疎通を取るようにして、DBが外から直接攻撃できないようになっている。

f:id:keisuke_t:20190922135335p:plain

図めっちゃ下手だけど、このサイト使ってこういうの書けたのも面白かった。

www.draw.io

次はもうちょい本番よりの構成を試してみたい。後は、ポチポチ辞めてCLIからとかコードで管理するとか。 次の本も買ったので、積まないで読むぞ 素晴らしい本を書いてくださった関係者の皆さんに大感謝です。

勉強合宿に憧れてエセ合宿を実施した

開発合宿とか勉強合宿とかってなんか憧れるんですよね。あまり大人になってから皆で集まって勉強するぞ！とかやったことなくて、基本は1人で集中してやる派ですがたまに、モチベーション維持のためにそういうスタイルで勉強したくなる時があります。ただ、平日に事業部規模とかでやろうとするとできるかも分からないのであまりに面倒だし、休日に会社の人とか誘ってどこか宿とって、、、とかも調整がまあ面倒なので地元の仲の良い友達をしゅっとモチベーション維持のために１日勉強しないかい？みたいな感じで誘って１日開催しました。

会場は、友達の実家が空いていたのでお借りして朝７時くらいから夜18時くらいまでもくもくと集中して行いました。

良かった事

  • 手軽に集中環境を作ることができました。

    • 自宅だと誘惑が多かったり、家庭がある方は長時間集中することが難しかったり1人の時間を休日に作る事自体が困難な方もいると思います。「今日は勉強するぞ」という同じ目的を持った人間同士集まると自然ともくもくと作業する環境ができるので本当に開催して良かった。

  • 全く別領域を知るができる

    • 僕は現在、ウェブアプリケーションエンジニアとして働いてますが共に勉強した友達は全然違う勉強をしてました。夕方頃に勉強を切り上げて今日の成果を５分で話すことも実施したので、「ほ〜こんな勉強をしてるんだなあ」と別領域に関しても知る事ができて新鮮でした

  • 次に繋がる

    • 結果としては大成功だったので、また実施しようという話をしました。定期的にこういう時間を作れる事に価値があると思います。

良い環境作りのための色々

  • レンタルWi-Fi
    • 速度もでるし、そんなダウンロードが必要な勉強もすることはなかったので充分でした。1人１０００円とかで済むのでマストです。ただ、ipv6未対応で僕の作業が一部できなかったので次回はそこだけ注意します。
  • 飲み物（いっぱい）
    • 外出るの億劫になるのでお菓子とか飲み物とか氷とか買い込んどくといいです。飽きたらお菓子ぽりぽり食べながら友達と作りたいTシャツの話とかしてました。あ、Tシャツ作るならSUZURIでどうですか？

suzuri.jp

  • 当日のスケジュール
    • きちんとタイムスケジュールを引いてやると中だるみも減っていいです。僕らは、午前の部、お昼休憩、午後の部、成果発表と時間を決めて実施しました。
  • 成果を発表する
    • 実際何が成果だったかを発表することが大事だと感じました。１つは学習した内容を人に説明できるかということ。２つはこの会が意味のあるものであることを認識できること。ここで成果がでなくなってきたらこの会はやめようかなと思っています。
  • 次回の予定をたてる
    • 次回の予定も適当にたてました。来月の日曜日にまた開催します。

tmuxをもうちょっと簡単に扱えるように良い感じのコマンドを開発した

みなさんtmuxってますか？ ターミナルで色んなことしたい人にとってはtmuxは必須ツールの１つかと思います。僕はだいたい１レポジトリ１セッションくらいで名前を切って作業していて各セッションに更にタブを生やして作業するのをスタイルとしています。 昨今のターミナルは非常に優秀でタブで似たようなことはできると思いますが、やはりtmuxかっこいいので使いたくなってしまうのが性なのです。がしかし、僕は非常に物覚えが悪くaliasを貼ってもなおtmuxでの新規セッションの作成や他セッションへのアタッチの動きに中々慣れず、例えばセッションにアタッチ中であればデタッチせずともtmux switch-client -t hogeとかでスイッチできますが、セッションから抜けている状態であればコマンドが変わってtmux attach -t hogeとかになりますよね。こういう切り替えが僕の脳では厳しく、もうちょっと簡単に扱えないものかと思っていました。 そこで、この辺の判断はプログラムに任せるかつセッション選択型のCLIツールを作ろうと思いました。

github.com

最近はCLIツールをGo言語で書いて、CLIツールの開発にはcobraというパッケージを使っています。

使用例としては、et とタイプすると選択型でプロンプトされるので、用途にあった選択数値をタイプするだけです。

$ et
=====Create new session or Attach another session=====
0: Create New Session
1: bugbounty
2: easy-tmux (Attached)
3: shutto
4: some-server
======================================================
Enter what you want:

kill-sessionのサブコマンドも実装していて、kを後ろにつければkill-sessionモードで選択型のプロンプトが表示されるようになっています。

$ et k
=====KILL SESSION=====
1: bugbounty
2: easy-tmux (Attached)
3: shutto
4: some-server
=======================
Enter what you want:

f:id:keisuke_t:20190702004400p:plain

f:id:keisuke_t:20190702004629p:plain

今後のどの辺をアップデートしていくかはtmuxを使いながら考えたいなあと思っていて、例えばtmuxからシンプルにデタッチする事もコマンドで解決したいかとか、tmuxにはセッション以外にもウィンドウ（タブ）もあるので、これらもコマンドで同様に切り替えやkillができるようにしたいかとかはコマンド自体の複雑性が増す可能性があるのとそもそもコマンド化しなくてもこの辺は良いキーマップが公式に用意されているので今の所は必要ないかなあと思ってます。逆にやりたいのは、ymlやtomlファイルにセッション名やウィンドウ名、もしくはペーン数を設定できて$ et load とかでいつものワーキングターミナルが立ち上がるみたいなのはやりたいなと思っています。なので、そこら辺アップデートしつつtmux環境で気持ちよく作業できるような感じにしていければ最高かなと思ってます。

転職して一年がたった

去年の４月半ば頃今の会社に転職したのでちょうど一年がたったみたいです。 僕が転職をして「良いな」と思った事がいくつかあるので書きます。未来の僕が常にそう振る舞えるように言い聞かせながら書きます。

1、素晴らしいチームメイトに出会えた（そして君もそういうチームが作れるようになってくれ）

僕が今頑張れてるのはこのチームで抜きん出れるように頑張りたいなと思えてるからだと思います。いつもみなさんお世話になってます。こんな大きなサービスにエンジニアとして転職したわけですが恥ずかしながら僕は入社した当時はGitもロクに使えない人間でしたので「本当にこいつは大丈夫なのか」と心配させてしまったかもしれませんが、こっそり皆さんのスレ（社内のSlackでは人々は個人スレを立てて今日の作業ログや独り言をつぶやく文化がある）を覗いて、「ふむふむこういう技術があるのか」「これは聞いたことがないな。調べてみよう」と自分なりに色んなことを人からパクって勉強していました。実はこれはとても効果的で自分より力のある人がやってる事を真似て学習することは自分だけじゃ普段調べようと思わないような事に出会えるので本当におすすめです。

2、公式ドキュメントやソースコードを読むようになった（君がメンターとして活躍するときはこれをすすめてくれ）

以前の僕は公式ドキュメントよりも投稿サイトに投稿された記事を読む事が多かったです。悪いとはいいませんが、もしプロとして仕事をするならばこれだけでは足りず公式ドキュメントや場合によってはソースコードを読まないとハマった沼から抜け出せなくなる事があります。僕のメンターはドキュメントを読む人で、ペアプロなんかをしてて投稿サイトの記事を読もうとすると「いや、今真上にドキュメントの検索結果でてましたよねwなんでそっち見ないんですかw」と突っ込んでくれたので（本当にありがとう。いつも隣で話しかけてすみません。）、僕も癖になりました。直近の出来事でもソースコードを読む事で解決できた事がありました。１つのことを解決できるかできないかで大きく変わる事があるので、一生の癖にしたいです。

３、書いたコードをアウトプットするようになった（これ以上に良い習慣はない。とにかくコードを書くんだ）

以前の僕は、本を読んでふむふむで終わる事が多かったです。Githubに「til(Today I Learned)」というリポジトリを作って日々勉強した事はそこにcommitするようにしています。やっぱりコードは書かないと一生良くなりません。実際に動かさないと何も分からないで終わる事がほとんどだと感じます。 Go言語でCLIツールをいくつか実装したのでチームに宣伝して使ってくれてる人がいるんですが、「こうした方がもっとわかりやすそう」「これバグっぽい」（ごめん）をすぐに教えてくれるのでまたそれを解決するためにコードを書くようになって良い事しかないので積極的にアウトプットすると自分のためになります。

[おまけ] ずっとやりたかったキックボクシングをはじめた

同僚がキックボクサーなので、お誘いいただいて同じジムでキックボクシングをはじめました。普段座ってる事が多いので健康にも良くないし、仕事というものは煮え切らない事があってストレスを感じる事だってあります。大人は自分で自分をコントロールできないといけない（自論です）と思っているので、安全に発散する手段として最高のスポーツだと思います。職場にキックボクシング始めたい人がいたら本当におすすめです。

最後に

僕がこれまでやれてこれたのは皆さんの存在ありきかなと思います。皆追い抜くぞというその一心が今の原動力なのだと思います。 もうちょい落ち着いたらご飯にいきましょう。

Github/Github EnterpriseのIssue/PRからTrelloカードを作れるコマンドをGoで書いた

今、僕のいるWebチームではタスク管理の一つとしてTrelloを使っています。 Trelloカードにポイントをつけれるプラグインをいれているのでスプリントの終わりにチーム全体で何ポイントを消化できたのかを測ることでチームのスプリントでの実力を測ることができます。 大きなタスクや見積もりをしたタスク等は、カードを作成して管理ができているのですが、日によって急に差し込んでくるようなタスク（バグ修正、調査依頼、クエリ作成依頼）のようなものはカードを作成することを忘れてしまう事があります。 そういう事が積み重なっていくと、振り返りMTGで「あれやった気がする？」「多分、これもやったので追加します。（あんまり覚えてないけど）」みたいな事が発生します。

1ptでも忘れている場合、正確にチームの実力を測る事ができずこの体制の良い所が失われてしまう気がしたので、カード作成の負担を減らすためにターミナルにissueまたはPRのURLを入力するとタイトルと詳細を取ってきてカードを作ってくれるコマンドを実装しました。

コマンドはGo言語で実装しました。配布が容易なのでこういうツールを作るにはもってこいだなあと思うのと、今年一番興味ある言語だからです。

$ go get -u github.com/garigari-kun/perica

Trelloのアクセスキー、トークン、リストのIDとGithub/Github Enterpriseのアクセストークンをconfigファイルに設定すれば使えます。

今、実装面で悩んでるのが、Trelloはボード、リスト、カードという単位で分類分けされてるのですが、僕の探した範囲だとリストIDを簡単に見つける導線がなかったので、pericaコマンドにリストIDを調べる機能を実装して補っています。ボードIDとボードの名前はアクセス先のURLから手に入るので、以下のようにしてリストIDを割り出しています。

$ perica https://trello.com/b/board_id/board_name

リストIDまでconfigファイルに設定しらもえれば、以下のような感じでTrelloカードを設定したリストへ作成することができます。

$ perica https://github.com/garigari-kun/perica/issues/2

f:id:keisuke_t:20190323135840p:plain

カードさえ作成していれば、日の終わりに行われる夕会でポイントをつけて、[Done]のリストへ移動することができるので、面倒なカード作成からおさらばできそうです。

ps. pericaコマンドの名前の由来は「ペリっとカードが作れる」です。

github.com