LogicMonitorは注意が必要な問題を特定するのに優れていますが、特にネットワークの問題の場合、解決策を正確に把握するのが少し難しい場合があります。 比較的一般的なケースのXNUMXつ–TCP接続の失敗に関するアラート。 最近、ラボ内のサーバーのXNUMXつがこのアラートをトリガーしました。
ホストLabutil01で、異常な数のTCP接続（おそらく着信接続）が失敗しています。 現在、毎秒2.01の失敗した接続があり、ホストを警告レベルにします。 これは2014-02-26：10：54PSTに開始されました。 これは、アプリケーションのバックログパラメータが正しくないか、OSTCPリッスンキューの設定が正しくないことが原因である可能性があります。
OK –では、次のステップは何ですか？ 私たちが最初にしたことは、これが最近の変更なのか、それともしばらくの間続いていたのかを確認することでした。 TCP接続のグラフをざっと見ると、これは新しい問題であることがわかります。
グラフの線は、「TCP接続がSYN-SENT状態またはSYN-RCVD状態のいずれかからCLOSED状態に直接遷移した回数とTCPの回数を示していることを（マウスオーバーで）説明しています。接続は、SYN-RCVDからLISTEN状態に直接移行しました。」
OK、それは最善の説明ではないかもしれませんが、基本的には、TCPアプリケーションがSYNを送信して接続を開こうとしましたが、RSTが返されました。 （TCPのすべての複雑さを本当に理解したい場合、そして多くの場合、それらを理解するのは良いことですが、私はお勧めします スティーブンスによるTCP / IPの図解 –オールディーズだがグッディーズ。）
では、どのアプリケーションがRSTを取得したのでしょうか。 この時点で、さまざまなログファイルを調べてみることができます（問題のアプリケーションがこの情報をログに記録し、見たい場所に記録することを期待します）。または、ネットワーク上のRSTを調べることもできます。
このサーバーはLinuxボックスであったため、TCPdumpを使用しますが、Wiresharkを使用してWindowsでも同じことができます。
私が最初に実行したtcpdumpは次のとおりです。
tcpdump -n -v'tcp [tcpflags]＆（tcp-rst）！= 0 '
これは、名前解決なしでTCPdumpを実行するコマンドです（速度が低下する可能性があります）。 詳細出力を使用して、tcp-rstビットが設定されているtcpフラグを持つすべてのパケットを表示します。 （つまり、すべてのTCP RSTパケット。）
そして、これは明らかに私たちに…何も示しませんでした。
[root@labutil01 ~]# tcpdump -n -v 'tcp[tcpflags] & (tcp-rst) != 0' tcpdump: eth0 でリッスン、リンクタイプ EN10MB (イーサネット)、キャプチャ サイズ 65535 バイト 15:08:17.537699 IP (tos 0x0、ttl 64、id 0、オフセット 0、フラグ [DF]、プロト TCP (6)、長さ 40) 10.0.1.141.http > 10.0.1.86.34559: フラグ [R.]、cksum 0x8411 (正しい) )、シーケンス 0
30秒間に2つのパケットが報告され、WebサーバーがRSTを介してこのサーバーからの接続を切断しました（これは有効なことです）。 しかし、XNUMX秒あたりXNUMX回のリセットを探しているので、そうではありませんでした。 では、次にどこを見ればよいのでしょうか。
上記の出力で、tcpdumpがデフォルトのインターフェースeth0でリッスンして実行されたことに注意してください。 このホストに他のネットワークインターフェイスがある場合は、そこでタスクを繰り返して、どのインターフェイスをリッスンするかをtcpdumpに指示することができます。 ただし、このサーバーにはXNUMXつのインターフェイスしかありません。
それとも？
プログラムは通常、すべてのLinux（およびWindows）サーバーが持つループバックポートを介して通信します。 そこで聞いたときに何が起こるか見てみましょう。 -i 国旗…。
[root@labutil01 ~]# tcpdump -ilo -n -v 'tcp[tcpflags] & (tcp-rst) != 0' tcpdump: lo でリッスン、リンクタイプ EN10MB (イーサネット)、キャプチャ サイズ 65535 バイト 15:13 :13.476095 IP (tos 0x0、ttl 64、id 0、オフセット 0、フラグ [DF]、プロト TCP (6)、長さ 40) 127.0.0.1.7211 > 127.0.0.1.41838: フラグ [R.]、cksum 0x57d9 (正しい)、seq 0、ack 2154306035、win 0、length 0 15:13:13.476216 IP (tos 0x0、ttl 64、id 0、offset 0、flags [DF]、proto TCP (6)、length 40) 127.0.0.1.7211。 127.0.0.1.41839 > 0: Flags [R.]、cksum 25x0bc (正しい)、seq 3335718308、ack 0、win 0、length 15 13:14.476576:0 IP (tos 0x64、ttl 0、id 0、オフセット6、フラグ [DF]、プロト TCP (40)、長さ 127.0.0.1.7211) 127.0.0.1.41840 > 0: フラグ [R.]、cksum 171x0a (正しい)、seq 2138200998、ack 0、win 0、長さ15 13:14.476721:0 IP (tos 0x64、ttl 0、id 0、オフセット 6、フラグ [DF]、プロト TCP (40)、長さ 127.0.0.1.7211) 127.0.0.1.41841 > 0: フラグ [R. ]、cksum 5xaec0 (正しい)、seq 1520953540、ack 0、win 0、length XNUMX
ああ…毎秒7211回のリセット。 問題のようです。 一部のプロセスがポートXNUMXでwww.logicmonitor.comに接続しようとしていますが、そのプロセスが実行されていないため、サーバーはRSTを送り返しています。
これは私たちの問題を解決しますか？ そうですね、通常はポート7211でリッスンするアプリケーションが何であるかがわかっていれば、それは可能です。「ああ、ポート7211 –それが何であるかはわかっています！」 または、ポートが443や23などのよく知られたポートです。次に、WebサーバーまたはTelnetサーバーを起動します（または、プロセスがTelnetサーバーに接続しようとするのを停止します）。
この場合、ポート7211がコレクターのコンポーネントによって使用されていることがわかったので、そのコンポーネントのログファイルを調べたところ、テストビルドにライブラリがないため、そのコンポーネントが機能しなくなっていました。 ライブラリをインストールし、コンポーネントを起動すると、RSTとアラートが消えました。
そして、そのポートでリッスンする必要があるプロセスがわからず、RSTを送信している場合はどうでしょうか。 まあ、少なくともあなたはそれが何であるかを知っています 。 そして今、あなたはもう少し知っているすべてのそれらのログファイルを見ることができます–そして何を除外するか。
もっと見たいです？ ここで私たちに従ってください：
または、@メールでお問い合わせください [メール保護]