Home > Archives > 2013年12月 Archive

2013年12月 Archive

Fluentd Casual Talks #3 へ参加しました

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っぽいけど、箇条書きの関係でそんな風に見えるだけです(;´x`) そんなつもりは全然ないですよ!

 

あと、以下の事も話しました。

  • そもそもログを吸い上げるところではCPUバウンドな処理はあまりしたくないし、それはつまり、ログを吸い上げてフィルタ処理などは他所のノードで行うことになる。
  • どうせ中間ノード(アグリゲーション)や最終的な出力先(MongoとかDBとかHadoopとか)はWindowsじゃないんでしょ
  • という事はWinで動くagent-liteのようなものだけで十分なのでは

パスワードの先頭4,5文字を公開してしまった某社CTO様から。

  • 世の中には全部Windowsのお客さんとかいるんやで
  • Azureとかもあるんやで

世の中は厳しい。

 

それはそれとして、TDにMonitorに機能が追加されるそうです(無料は嬉しいね!)。でもでも最終的にアラートがあげられないと厳しそう。(後々アラートも対応するそうです)。
Cloudera Managerって何かおかしな事があるとヒントをくれるんですが、TDもそういうの出してくれると嬉しいかもですね。例えば、あるログを検知したら「バッファが溢れておるぞ! このあたりの設定を見直すのじゃ!」みたいな。

 

というわけで、楽しかったでざる。
主催者、および発表者、会場提供のDeNAさんに感謝!

用事があったので参加できなかったけど、飲み会行きたかった(´・ω・)

Windows OSに関する覚え書きと訂正

以前、こちらの記事で以下の事を書いたのですが、これは間違いでした。ごめんなさい(´・ω・`)。

2. GetFileInformationByHandleで取得するBY_HANDLE_FILE_INFORMATIONのnFileIndexHigh, nFileINdexLowを参照する。こちらは再起動、ボリュームのマウントしなおしで値が変わります。

Windows2008R2で再起動、再マウントでファイルシステムがNTFSの場合、変わらないことを確認しました。ではどういう時に変わるのかというと、ファイルシステムがFAT系(FAT, FAT32)の時にRenameをし、そのRenameによって名前が長くなったり、ディレクトリ内の順番が変わったりするような場合に変わりました。
(NTFSでも別ボリュームへ移動した場合は変わります(※1)) 

また、同一性の判定については、nFileIndexHighとnFileINdexLowだけでは不十分で、dwVolumeSerialNumber も合わせて比較する必要があります。まぁ別ボリュームでnFileIndexHighとnFileINdexLowが一致するって事はレアケースだとは思いますが、完全ではないので。

MSDNのRemarkのところに記述があります。

なので、ローテーションされているログをTAILで追跡するような場合、以下の前提が必要になります。

  • NTFSファイルシステムであること
  • ローテーション先が同一ボリュームであること

※1について
NTFSで別ボリュームに移動した場合でも追跡したい場合はDeviceIOCtrlを使う必要があります。

確認したOS

確認したOSはWindows2008R2です。

2008R2はNTカーネル6.1なのでWindows7と同等のカーネルです。一応主要OSのNTバージョンを表にしておきます。

NT Version OS
NT 5.1 Windows XP
NT 5.2 Windows Server 2003
NT 5.2 Windows XP (64bit)
NT 6.0 Windows Vista
NT 6.0 Windows Server 2008
NT 6.1 Windows 7
NT 6.1 Windows Server 2008 R2
NT 6.2 Windows 8
NT 6.2 Windows Server 2012
NT 6.3 Windows 8.1
NT 6.3 Windows Server 2012 R2

手元で確認できるのは、XPとVistaとWin7、EC2上でWindowsServer2008, 2012があるのでもうちょっと別のOSで確認してみます。(-_- )ウーン・・
2003はEC2に無いので無理です。

※追記(2013/12/19 11:00) EC2にWindows Server 2003ありました。QuickStartに出てこないだけで普通にありました。ごめんなさい。

また何かわかったら書きます。

いや、全然違うよ!正しくはこうだよって指摘がありましたらツッコミよろしくお願いします。

Home > Archives > 2013年12月 Archive

Search
Feeds

Return to page top