データベースへのアプリケーション接続がアプリケーション内部であるか、ネットワークイベントが原因であるかを確認します。これはシステム全体でnetfilterに表示されるようです。これを行うには、-j LOGjavascriptを使用してiptablesシステムで発生したすべてのTCPリセットとタイムアウトを記録したいと思います。しかし、基準に合わせて何を使うべきかわかりません。
conntrackいつかそのモジュールに関連する答えが出てくるようですが、ほとんど何も見つかりません。データベースサーバーはMS-SQLで、J2EEアプリケーションはRHEL 5.10 VMで実行されます。後者はログインを実行するシステムです。
編集する：
私が見つけたこのブログ投稿--tcp-flagsオプションを使用してTCPリセットを記録する方法（何よりも）を表示しますiptables。したがって、解決すべき質問は明示的なRSTを持っていませんが、接続が古いかタイムアウトしていると見なされ、閉じた接続を記録する方法を見つけることです。
答え1
IRCに尋ねた結果、ノードが接続が異常終了したと感じた場合、通常は予想されるようです。どの内部的に派生したタイムアウトに達するなどの理由で、RSTパケットは接続側が閉じる前にリモートノードに送信されると予想されます。したがって、どちらの質問も同じ解決策で答えられるようです。つまり、TCPロギングを介してリセットすることです--tcp-flags。
私のRHEL 5.10システム（Debianベースのディストリビューションでも機能する必要があります）でこれを行うための基本的なコマンドは次のとおりです。
root@xxxxxxvlt01 ~ $ iptables -A OUTPUT -m tcp -p tcp --tcp-flags RST RST -j LOG
root@xxxxxxvlt01 ~ $ iptables -A OUTPUT -m tcp -p tcp --tcp-flags FIN FIN -j LOG
一致基準がないと、かなりの数のパケットが一致する可能性があるため、私が扱っているシステムに固有の新しいルールを作成しました。
root@xxxxxxvlt01 ~ $ iptables -A OUTPUT -d xxx.xxx.64.248/32 -m tcp -p tcp --tcp-flags RST RST -j LOG
root@xxxxxxvlt01 ~ $ iptables -A OUTPUT -d xxx.xxx.64.248/32 -m tcp -p tcp --tcp-flags FIN FIN -j LOG
root@xxxxxxvlt01 ~ $ iptables -nvL
Chain INPUT (policy ACCEPT 767K packets, 108M bytes)
pkts bytes target prot opt in out source destination
Chain FORWARD (policy ACCEPT 0 packets, 0 bytes)
pkts bytes target prot opt in out source destination
Chain OUTPUT (policy ACCEPT 448K packets, 68M bytes)
pkts bytes target prot opt in out source destination
0 0 LOG tcp -- * * 0.0.0.0/0 xxx.xxx.64.248 tcp flags:0x04/0x04 LOG flags 0 level 4
0 0 LOG tcp -- * * 0.0.0.0/0 xxx.xxx.64.248 tcp flags:0x01/0x01 LOG flags 0 level 4
root@xxxxxxvlt01 ~ $
これははるかに良いです。タイムアウト後、RSTの内容の確認はIRCの誰かによって提供されたので、誰かが私が間違っていることを証明する場合に備えて、この内容に答えずに残しておきます。一週間後に誰かが私に反論しない限り、私は私の答えを受け入れます。