Fluentd Casual Talks #3 に参加してきました。
各発表の内容は資料を見るなり、誰かがまとめていたりするので、そちらを見れば良いと思います。今回参加した理由は、Windows版のFluentdについての発表があったからです。というわけで、発表者の方と休憩時間に話した内容をまとめます。
- NTFS限定、かつネットワークドライブは挙動を保証しない事をドキュメントに書いた方が良いと思う
- 監視対象がローテーションしていて、かつ別ボリュームへ移動している場合は保証外である事を明示した方が良いと思う
- NTカーネルのバージョンをどこからサポートするか明示した方が良いと思う
-
- 特にXPのバージョン(Windows Server 2003の1つ前のカーネル)まで遡ると、NTFSの挙動が違います
- GetFileInformationByHandleで判断する時は、FileIndexの他にdwVolumeSerialNumberも合わせて比較しないとダメです
- Win32Fileの実装がどこかで見たことあるコードのような。あのコードはPOSIXのインターフェースに合わせるように設計されているが、WinならWin32File, そうでないならKernel(or File)のインスタンスを使うというようなコードではなく、所謂ifdef win32ならWin32Fileを直接使うような記述をしているので、忠実にPOSIXのインターフェースに準拠する必要はないのでは。むしろデッドコードが多すぎてよろしくない気がします。
- FileBufferが動かないのはFile操作がPOSIX準拠のままなので、そっちもWin32APIを使えば動くはずです（同一ボリュームであればMoveしてもOpenしているファイルハンドルは追従してくれます）
- File操作に古いAPIを使っていて64ビット値の扱いが煩雑になっている。Ex系のAPIを使った方がスマートに書けます
- 本体とin_tail, out_forwawrdがだいたい動くようになったら、次はパフォーマンスカウンタとWindowsのイベントログを吸い上げたいって要求は出てくるよね
このあたりを話した気がします。
1つ忘れた事として以下があります。何か意図があるならごめんなさい、スルーしてください。
- Win32API.new() を各メソッド中で行うのではなく、initialize中で行った方がよいのでは？
※読み返したら、なんか書き方がDisっぽいけど、箇条書きの関係でそんな風に見えるだけです(；´ｘ｀) そんなつもりは全然ないですよ！
あと、以下の事も話しました。
- そもそもログを吸い上げるところではCPUバウンドな処理はあまりしたくないし、それはつまり、ログを吸い上げてフィルタ処理などは他所のノードで行うことになる。
- どうせ中間ノード（アグリゲーション）や最終的な出力先（MongoとかDBとかHadoopとか）はWindowsじゃないんでしょ
- という事はWinで動くagent-liteのようなものだけで十分なのでは
パスワードの先頭4，5文字を公開してしまった某社CTO様から。
- 世の中には全部Windowsのお客さんとかいるんやで
- Azureとかもあるんやで
世の中は厳しい。
それはそれとして、TDにMonitorに機能が追加されるそうです（無料は嬉しいね！）。でもでも最終的にアラートがあげられないと厳しそう。（後々アラートも対応するそうです）。
Cloudera Managerって何かおかしな事があるとヒントをくれるんですが、TDもそういうの出してくれると嬉しいかもですね。例えば、あるログを検知したら「バッファが溢れておるぞ！ このあたりの設定を見直すのじゃ！」みたいな。
というわけで、楽しかったでざる。
主催者、および発表者、会場提供のDeNAさんに感謝！
用事があったので参加できなかったけど、飲み会行きたかった(´・ω・)