Xymon Mailing List Archive search

Can I monitor how many connections are in TIME_WAIT for a specific port

9 messages in this thread

list Paul Root · Tue, 24 Jan 2012 10:13:41 -0600 ·
Hi,
        We are monitoring a particular port that we are having issues with. 8022, it's a proxy port for HP NA.

        Anyway, I have an expect script that goes in and tests the functionality of the port. But when it starts to go bad, this script get stuck in TIME_WAIT, along with the users connecting to the port.

        So, can I look at the port data before I try connecting, and if there are a bunch of TIME_WAIT connections, just skip the test entirely?

        I'm running the test from the xymon server, so I was thinking of pulling the data out of xymon directly. Would that by xymoncmd?

Thanks,
Paul.

Paul Root    - Engineer III
Managed Services Systems - CenturyLink


This communication is the property of CenturyLink and may contain confidential or privileged information. Unauthorized use of this communication is strictly
prohibited and may be unlawful.  If you have received this communication
in error, please immediately notify the sender by reply e-mail and destroy
all copies of the communication and any attachments.
list Asif Iqbal · Tue, 24 Jan 2012 11:24:53 -0500 ·
quoted from Paul Root
On Tue, Jan 24, 2012 at 11:13 AM, Root, Paul <user-76fdb6883669@xymon.invalid> wrote:
Hi,
       We are monitoring a particular port that we are having issues with. 8022, it's a proxy port for HP NA.

       Anyway, I have an expect script that goes in and tests the functionality of the port. But when it starts to go bad, this script get stuck in TIME_WAIT, along with the users connecting to the port.
why not use ssh:8022:s in hosts.cfg ?
quoted from Paul Root

       So, can I look at the port data before I try connecting, and if there are a bunch of TIME_WAIT connections, just skip the test entirely?

       I'm running the test from the xymon server, so I was thinking of pulling the data out of xymon directly. Would that by xymoncmd?

Thanks,
Paul.

Paul Root    - Engineer III
Managed Services Systems - CenturyLink


This communication is the property of CenturyLink and may contain confidential or privileged information. Unauthorized use of this communication is strictly
prohibited and may be unlawful.  If you have received this communication
in error, please immediately notify the sender by reply e-mail and destroy
all copies of the communication and any attachments.
-- 

Asif Iqbal
PGP Key: 0xE62693C5 KeyServer: pgp.mit.edu
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
list Asif Iqbal · Tue, 24 Jan 2012 11:43:59 -0500 ·
quoted from Asif Iqbal
On Tue, Jan 24, 2012 at 11:24 AM, Asif Iqbal <user-6f4b51ac2a40@xymon.invalid> wrote:
On Tue, Jan 24, 2012 at 11:13 AM, Root, Paul <user-76fdb6883669@xymon.invalid> wrote:
Hi,
       We are monitoring a particular port that we are having issues with. 8022, it's a proxy port for HP NA.

       Anyway, I have an expect script that goes in and tests the functionality of the port. But when it starts to go bad, this script get stuck in TIME_WAIT, along with the users connecting to the port.
why not use ssh:8022:s in hosts.cfg ?

       So, can I look at the port data before I try connecting, and if there are a bunch of TIME_WAIT connections, just skip the test entirely?

       I'm running the test from the xymon server, so I was thinking of pulling the data out of xymon directly. Would that by xymoncmd?
if you like to pursue your method and just want to count the number of
TIME_WAIT for port 8022, you can run something like this from xymon
server

xymon localhost  "clientlog host.example.net section=ports" | grep
8022 | grep TIME_WAIT
quoted from Asif Iqbal

Thanks,
Paul.

Paul Root    - Engineer III
Managed Services Systems - CenturyLink


This communication is the property of CenturyLink and may contain confidential or privileged information. Unauthorized use of this communication is strictly
prohibited and may be unlawful.  If you have received this communication
in error, please immediately notify the sender by reply e-mail and destroy
all copies of the communication and any attachments.
--
Asif Iqbal
PGP Key: 0xE62693C5 KeyServer: pgp.mit.edu
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

-- 
Asif Iqbal
PGP Key: 0xE62693C5 KeyServer: pgp.mit.edu
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
list Ralph Mitchell · Tue, 24 Jan 2012 11:53:56 -0500 ·
quoted from Asif Iqbal
On Tue, Jan 24, 2012 at 11:43 AM, Asif Iqbal <user-6f4b51ac2a40@xymon.invalid> wrote:
On Tue, Jan 24, 2012 at 11:24 AM, Asif Iqbal <user-6f4b51ac2a40@xymon.invalid> wrote:
On Tue, Jan 24, 2012 at 11:13 AM, Root, Paul <user-76fdb6883669@xymon.invalid>
wrote:
Hi,
       We are monitoring a particular port that we are having issues
with. 8022, it's a proxy port for HP NA.

       Anyway, I have an expect script that goes in and tests the
functionality of the port. But when it starts to go bad, this script get
stuck in TIME_WAIT, along with the users connecting to the port.
why not use ssh:8022:s in hosts.cfg ?

       So, can I look at the port data before I try connecting, and if
there are a bunch of TIME_WAIT connections, just skip the test entirely?

       I'm running the test from the xymon server, so I was thinking of
pulling the data out of xymon directly. Would that by xymoncmd?
if you like to pursue your method and just want to count the number of
TIME_WAIT for port 8022, you can run something like this from xymon
server

xymon localhost  "clientlog host.example.net section=ports" | grep
8022 | grep TIME_WAIT

This works too:

     /home/xymon/server/bin/xymon localhost "xymondlog
server.domain.com.ports"

Ralph Mitchell
list Paul Root · Tue, 24 Jan 2012 10:54:24 -0600 ·
That's not sufficient. I have to go into the process and connect to it. But we think it may be exasperating the problem.

I'm watching how many connections we have in ports, but I'm also running my expect script test. What I'm thinking now, is tying them together. If we see it having trouble in ports, there's no reason to run the expect script.

Paul Root    - Engineer III
Managed Services Systems - CenturyLink

-----Original Message-----
From: Asif Iqbal [mailto:user-6f4b51ac2a40@xymon.invalid]
Sent: Tuesday, January 24, 2012 10:25 AM
To: Root, Paul
Cc: xymon at xymon.com
Subject: Re: [Xymon] Can I monitor how many connections are in
TIME_WAIT for a specific port
quoted from Asif Iqbal

On Tue, Jan 24, 2012 at 11:13 AM, Root, Paul
<user-76fdb6883669@xymon.invalid> wrote:
Hi,
       We are monitoring a particular port that we are having issues
with. 8022, it's a proxy port for HP NA.

       Anyway, I have an expect script that goes in and tests the
functionality of the port. But when it starts to go bad, this script
get stuck in TIME_WAIT, along with the users connecting to the port.
why not use ssh:8022:s in hosts.cfg ?

       So, can I look at the port data before I try connecting, and
if there are a bunch of TIME_WAIT connections, just skip the test
entirely?

       I'm running the test from the xymon server, so I was thinking
of pulling the data out of xymon directly. Would that by xymoncmd?

Thanks,
Paul.

Paul Root    - Engineer III
Managed Services Systems - CenturyLink


This communication is the property of CenturyLink and may contain
confidential or privileged information. Unauthorized use of this
communication is strictly
prohibited and may be unlawful.  If you have received this
communication
in error, please immediately notify the sender by reply e-mail and
destroy
all copies of the communication and any attachments.
--
Asif Iqbal
PGP Key: 0xE62693C5 KeyServer: pgp.mit.edu
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
This communication is the property of CenturyLink and may contain confidential or privileged information. Unauthorized use of this communication is strictly
prohibited and may be unlawful.  If you have received this communication
in error, please immediately notify the sender by reply e-mail and destroy
all copies of the communication and any attachments.
list Paul Root · Tue, 24 Jan 2012 10:55:17 -0600 ·
That's what I need.

Thanks!
quoted from Paul Root

Paul Root    - Engineer III
Managed Services Systems - CenturyLink

-----Original Message-----
From: Asif Iqbal [mailto:user-6f4b51ac2a40@xymon.invalid]
Sent: Tuesday, January 24, 2012 10:44 AM
To: Root, Paul
Cc: xymon at xymon.com
Subject: Re: [Xymon] Can I monitor how many connections are in
TIME_WAIT for a specific port

On Tue, Jan 24, 2012 at 11:24 AM, Asif Iqbal <user-6f4b51ac2a40@xymon.invalid> wrote:
On Tue, Jan 24, 2012 at 11:13 AM, Root, Paul
<user-76fdb6883669@xymon.invalid> wrote:
Hi,
       We are monitoring a particular port that we are having issues
with. 8022, it's a proxy port for HP NA.

       Anyway, I have an expect script that goes in and tests the
functionality of the port. But when it starts to go bad, this script
get stuck in TIME_WAIT, along with the users connecting to the port.
why not use ssh:8022:s in hosts.cfg ?

       So, can I look at the port data before I try connecting, and
if there are a bunch of TIME_WAIT connections, just skip the test
entirely?

       I'm running the test from the xymon server, so I was thinking
of pulling the data out of xymon directly. Would that by xymoncmd?
if you like to pursue your method and just want to count the number of
TIME_WAIT for port 8022, you can run something like this from xymon
server

xymon localhost  "clientlog host.example.net section=ports" | grep
8022 | grep TIME_WAIT

Thanks,
Paul.

Paul Root    - Engineer III
Managed Services Systems - CenturyLink


This communication is the property of CenturyLink and may contain
confidential or privileged information. Unauthorized use of this
communication is strictly
prohibited and may be unlawful.  If you have received this
communication
in error, please immediately notify the sender by reply e-mail and
destroy
all copies of the communication and any attachments.
--
Asif Iqbal
PGP Key: 0xE62693C5 KeyServer: pgp.mit.edu
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

--
Asif Iqbal
PGP Key: 0xE62693C5 KeyServer: pgp.mit.edu
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
This communication is the property of CenturyLink and may contain confidential or privileged information. Unauthorized use of this communication is strictly
prohibited and may be unlawful.  If you have received this communication
in error, please immediately notify the sender by reply e-mail and destroy
all copies of the communication and any attachments.
list Asif Iqbal · Tue, 24 Jan 2012 12:01:02 -0500 ·
On Tue, Jan 24, 2012 at 11:53 AM, Ralph Mitchell
quoted from Paul Root
<user-00a5e44c48c0@xymon.invalid> wrote:
On Tue, Jan 24, 2012 at 11:43 AM, Asif Iqbal <user-6f4b51ac2a40@xymon.invalid> wrote:
On Tue, Jan 24, 2012 at 11:24 AM, Asif Iqbal <user-6f4b51ac2a40@xymon.invalid> wrote:
On Tue, Jan 24, 2012 at 11:13 AM, Root, Paul <user-76fdb6883669@xymon.invalid>
wrote:
Hi,
       We are monitoring a particular port that we are having issues
with. 8022, it's a proxy port for HP NA.

       Anyway, I have an expect script that goes in and tests the
functionality of the port. But when it starts to go bad, this script get
stuck in TIME_WAIT, along with the users connecting to the port.
why not use ssh:8022:s in hosts.cfg ?

       So, can I look at the port data before I try connecting, and if
there are a bunch of TIME_WAIT connections, just skip the test entirely?

       I'm running the test from the xymon server, so I was thinking of
pulling the data out of xymon directly. Would that by xymoncmd?
if you like to pursue your method and just want to count the number of
TIME_WAIT for port 8022, you can run something like this from xymon
server

xymon localhost  "clientlog host.example.net section=ports" | grep
8022 | grep TIME_WAIT

This works too:

     /home/xymon/server/bin/xymon localhost "xymondlog
server.domain.com.ports"

only if you setup rules for it and have a test column for ports.

Ralph Mitchell
quoted from Paul Root

-- 
Asif Iqbal
PGP Key: 0xE62693C5 KeyServer: pgp.mit.edu
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
list Buchan Milne · Wed, 25 Jan 2012 17:02:12 +0200 ·
quoted from Asif Iqbal
On Tuesday, 24 January 2012 18:13:41 Root, Paul wrote:
Hi,
        We are monitoring a particular port that we are having issues with.
8022, it's a proxy port for HP NA.

        Anyway, I have an expect script that goes in and tests the
functionality of the port. But when it starts to go bad, this script get
stuck in TIME_WAIT, along with the users connecting to the port.

        So, can I look at the port data before I try connecting, and if
there are a bunch of TIME_WAIT connections, just skip the test entirely?
Why don't you just (in hobbit-clients.cfg or analysis.cfg) use something like this

        PORT LOCAL=%([.:]389) STATE=TIME_WAIT MIN=0 MAX=750 COL=yellow
        PORT LOCAL=%([.:]389) STATE=TIME_WAIT TRACK=ldap-wait MIN=0 MAX=1500 COL=red

(example taken directly from a similar requirement for monitoring highly utilised LDAP servers with badly behaving clients - regex could probably be improved but works fine for my purposes)
quoted from Asif Iqbal

        I'm running the test from the xymon server, so I was thinking of
pulling the data out of xymon directly. Would that by xymoncmd?
Why script around it when built-in features can detect and alert on the error condition (and provide graphs as well in case you want to correlate the exact number of connections in a specific state to other events)?

Regards,
Buchan
list Paul Root · Wed, 25 Jan 2012 09:11:04 -0600 ·
As I said before, this isn't sufficient.

HP NA is so flakey, that this port test would show whether the port answers in the simple case, but it doesn't test that the port actually works for what we need it to do.

I have to have my script test the functionality of the port, not just that it answers.

Thanks for everyone's help. I have what I need to get done what I need.

Paul Root    - Senior Engineer
quoted from Buchan Milne
Managed Services Systems - CenturyLink

-----Original Message-----
From: Buchan Milne [mailto:user-9b139aff4dec@xymon.invalid]
Sent: Wednesday, January 25, 2012 9:02 AM
To: xymon at xymon.com
Cc: Root, Paul
Subject: Re: [Xymon] Can I monitor how many connections are in
TIME_WAIT for a specific port

On Tuesday, 24 January 2012 18:13:41 Root, Paul wrote:
Hi,
        We are monitoring a particular port that we are having issues
with.
8022, it's a proxy port for HP NA.

        Anyway, I have an expect script that goes in and tests the
functionality of the port. But when it starts to go bad, this script
get
stuck in TIME_WAIT, along with the users connecting to the port.

        So, can I look at the port data before I try connecting, and
if
there are a bunch of TIME_WAIT connections, just skip the test
entirely?
Why don't you just (in hobbit-clients.cfg or analysis.cfg) use
something like
this

        PORT LOCAL=%([.:]389) STATE=TIME_WAIT MIN=0 MAX=750 COL=yellow
        PORT LOCAL=%([.:]389) STATE=TIME_WAIT TRACK=ldap-wait MIN=0
MAX=1500
COL=red

(example taken directly from a similar requirement for monitoring
highly
utilised LDAP servers with badly behaving clients - regex could
probably be
improved but works fine for my purposes)

        I'm running the test from the xymon server, so I was thinking
of
pulling the data out of xymon directly. Would that by xymoncmd?
Why script around it when built-in features can detect and alert on the
error
condition (and provide graphs as well in case you want to correlate the
exact
number of connections in a specific state to other events)?

Regards,
Buchan
This communication is the property of CenturyLink and may contain confidential or privileged information. Unauthorized use of this communication is strictly
prohibited and may be unlawful.  If you have received this communication
in error, please immediately notify the sender by reply e-mail and destroy
all copies of the communication and any attachments.