先に環境を。
OS RedHatEnterpriseLinux 6.2 (ESX5.0上で動作)
ruby 1.9.3p194 (2012-04-20 revision 35410) [x86_64-linux]
fluentd (0.10.19, 0.10.13)
送信側(fluent_send)
<source>
正規表現等々
</source>
<match sendmail.*>
type forward
host fluent_recv
port 24224
buffer_type file
buffer_path /var/log/fluent/myapp-forward
retry_limit 50
flush_interval 10s
</store>
</match>
受信側(fluent_recv)
<source>
type forward
port 24224
bind 0.0.0.0
</source>
<match sendmail.*>
// マッチング処理
</match>
「detached forwarding server」が出力されたので、twitterで嘆いてると、@kzk_moverさんにありがたい助言を頂いてhttp://d.hatena.ne.jp/oranie/20120323/1332498317あたりを参考にしながらUDPが怪しいんじゃないかってところまではわかった。
でも、一つの物理サーバー上で動いてるVM間での通信なので、VMのネットワークのみを使用してる。
もちろんFWはないし、iptablesもSE Linuxもオフってみる。
・・・が、うまくいかない。
実際にtcpdumpで見てみると、確かにudpの通信が来ていない。。
コマンド:tcpdump -X port 24224 -e -vv
※念のため-eを指定して、MACアドレスも確認する。(仮想NICのため)
だがしかし!
nmapしてみると、ちゃんとudpが通ってる。※
受信側のtcpdumpでパケットを確認。
コマンド:nmap -p 24224 -sU あて先IP
ってことは、rubyのudpが問題??ってことで、シンプルなudpテストコードを書いてみる。
で、結果はNG。tcpdumpでは送信側のパケットは見えるけど、受信側には何も出てこない。Require “socket”udp = UDPSocket.open()sockaddr = Socket.pack_sockaddr_in(24227,”10.30.120.139”)udp.send(“hello”, 0, sockaddr)udp.close()
どうもrubyが怪しいってことはわかったけど、原因がわからない。
VMが怪しいのではと思い、送信元を物理マシンに変更すると、正常に送信された!
VM+rubyの組み合わせがNGってところまで絞れた。
ネットワークを一時的に無差別モードにしてみたけど、変わらない。
VMwareToolsのバージョンを上げたり、仮想HWのバージョンを上げても変化なし。
VMの切り分けで策が尽きたので、yum updateを走らせてみる。
そしてOSをrebootすると、rubyのテストコードが送信、受信側それぞれでパケットを確認できた!
ってことは、OS or ソフトレベルの問題っぽい。
アップデートされたソフトを"/var/log/yum.log"で確認して、怪しそうなのを絞り込む。
数が多かったけど、あやしそうなのは・・・カーネル。
VMのスナップショット機能を使って、update前に戻してから、カーネルのみアップデートしてOSをrebootしてテストコードを流すと、バッチリパケットを確認できた。
これをもとにググってみると、この情報を発見!
https://access.redhat.com/knowledge/ja/node/67823
要するに、下記の環境だと小さいudpパケットをロスしちゃいますよーってことらしい。
今回たまたまこれに該当してた。
Environment
RHEL 6 update 2
kernel-2.6.32-220.el6.i686 / kernel-2.6.32-220.2.1.el6.x86_64 / kernel-2.6.32-220.el6.x86_64
vmxnet3
1.1.18.0-k- Vmware ESX Host
それにしても、fluentdをVM上のマシンで使うってのは結構ありそうな話やけど日本語の情報は全然なかった。
みんな人知れず解決しちゃってるのかなー。