Cybozu Meetup #6 サイボウズのサービスを支えるログ基盤

Shin'ya Ueoka @ueokande

先ほどの資料を公開しました「サイボウズのサービスを支えるログ基盤」 slideshare.net/ShinyaUeoka/ss… #CybozuMeetup

Kazuyuki Honda @hakobera

オンプレだと Kafka は順当としても、Fluentd で at least once が難しいってなんだろう？Go で自前で書いた理由と実装方法が知りたい twitter.com/ueokande/statu…

wyukawa @wyukawa

Kafkaへのログ転送 初めはFluentdでKafkaへ転送してたが、 at least onceを満たすことが難しいと判明し転送エージェントをGoで実装とのことらしいけど、詳細が知りたいな。マルチプロセスの管理が面倒になってGoで実装したとかならまだわかるんだけど。

そのっつ (Naotoshi Seo) @sonots

fluentd で at least once を保証するのが困難と判明というのはどういう話だろ。 / “サイボウズのサービスを支えるログ基盤” htn.to/FUc8g5

Kimura, Sotaro @kimutansk

fluentdでExactly onceではなく、At least onceが出来ないってどういう意味なんでしょうね。普通にできるような。何か欠落するパターンが発生した？ / “サイボウズのサービスを支えるログ基盤” htn.to/dZ41cF

NAKANO Akihito (ackintosh.eth) @NAKANO_Akihito

Fluentd で at least once が難しい理由が気になる...! / 他2コメント b.hatena.ne.jp/entry/s/www.sl… “サイボウズのサービスを支えるログ基盤” htn.to/urY8yBB

Shin'ya Ueoka @ueokande

@NAKANO_Akihito @kimutansk @sonots @wyukawa @hakobera fluentdの件を補足しますと、fluentdのコアはv0.12からat least onceになったけど、プラグインはその保証ができない感じです。

Shin'ya Ueoka @ueokande

@NAKANO_Akihito @kimutansk @sonots @wyukawa @hakobera あと、in_tailプラグインが、fluentd死亡時にファイルが2回ローテートされたりするとうまく拾ってくれないことがあります。

SKS/ファントムの申し子 @repeatedly

プラグインの実装によってはat-least-onceではない，ってのは確かだが，kafkaプラグインのrequired_acks 1以上かつエラーが起きたときのバッファのretryで問題が起きたってことなんだろうか？それだとバグだと思うから報告して欲しかった……

そのっつ (Naotoshi Seo) @sonots

@ueokande @NAKANO_Akihito @kimutansk @wyukawa @hakobera あぁ、なるほど。うちだとログファイルを時間つきで出力して(つまりローテートしない)、このプラグインで github.com/civitaspo/flue… 指定ディレクトリ以下のファイルを全部攫うようにして対処してる感じです。

SKS/ファントムの申し子 @repeatedly

時間制限つきでファイルを監視するのは昔考えたことあるんだけど，結構要件的にレアなのと，fluentdだけが落ちることってほぼなくて，何か問題があってもすぐ再起動が行われるから，2段階ローテートの問題が起きたことがなかったんだよな

そのっつ (Naotoshi Seo) @sonots

@ueokande @NAKANO_Akihito @kimutansk @wyukawa @hakobera ここで言っているプラグインって、kafka プラグインのことですか？

Shin'ya Ueoka @ueokande

@sonots @NAKANO_Akihito @kimutansk @wyukawa @hakobera out_exec_filterがバッファ溢れしたときに、データを捨てられた気がします

そのっつ (Naotoshi Seo) @sonots

@ueokande @NAKANO_Akihito @kimutansk @wyukawa @hakobera 溢れた時に捨てるのは、どのバッファプラグインもそうですね。うちでは buffer_queue_limit をめちゃくちゃ大きくして対処するなどしています。see gist.github.com/sonots/02de35a…

Kimura, Sotaro @kimutansk

@ueokande @sonots @NAKANO_Akihito @wyukawa @hakobera バッファあふれが発生した場合捨てられないようにするのはfluentdに限らずかなり困難（バッファ数大きめに設定するにしてもディスクの限界以上は割り振れない）だと思うのですが、Goで作成したクライアントの場合、それはどうやって防止しているのでしょうか？

Shin'ya Ueoka @ueokande

@kimutansk @sonots @NAKANO_Akihito @wyukawa @hakobera 溢れるようなバッファは存在しないような設計にしてます。ログはファイルのみが対象なので、データはディスク上に永続されています。Kafka側が詰まっても、最後に送ったログの続きから読んで再送するだけです。

Kimura, Sotaro @kimutansk

@ueokande @sonots @NAKANO_Akihito @wyukawa @hakobera なるほど。自前ではメタデータだけを保持して、バッファリングはしないことで出力元のアプリケーション自体でディスクをあふれない限りは問題ないという形になるわけでしたか。補足ありがとうございます。