On Tue, Jan 24, 2012 at 11:24 AM, Asif Iqbal <vadud3 at gmail.com> wrote:

On Tue, Jan 24, 2012 at 11:13 AM, Root, Paul <Paul.Root at centurylink.com> 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.

---

Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon

-- 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?

On Tue, Jan 24, 2012 at 11:53 AM, Ralph Mitchell <ralphmitchell at gmail.com> wrote:

On Tue, Jan 24, 2012 at 11:43 AM, Asif Iqbal <vadud3 at gmail.com> wrote:

...

On Tue, Jan 24, 2012 at 11:24 AM, Asif Iqbal <vadud3 at gmail.com> wrote:

...

On Tue, Jan 24, 2012 at 11:13 AM, Root, Paul <Paul.Root at centurylink.com> 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

-- 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?

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:vadud3 at gmail.com] 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

On Tue, Jan 24, 2012 at 11:13 AM, Root, Paul <Paul.Root at centurylink.com> 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.

---

Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon

-- 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.

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 Managed Services Systems - CenturyLink

-----Original Message----- From: Buchan Milne [mailto:bgmilne at staff.telkomsa.net] 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.