Green status
list Pankaj Dorlikar
Hi, We are using xymon-4.2.2 on rhel 5.2 server and more than 200 clients (HPC Cluster nodes). Our requirement is : -> If the node is powered down by scheduler for saving the power, it is required that xymon should show its state as green and same for other tests of same node. Nodes powered down by scheduler are identified by pbsnodes command which will show state as power. -> If the node is going down by some other reason other that powering down by scheduler, it should show red like normal clients. -- Pankaj V. Dorlikar
list Japheth Cleaver
▸
We are using xymon-4.2.2 on rhel 5.2 server and more than 200 clients (HPC Cluster nodes). Our requirement is : -> If the node is powered down by scheduler for saving the power, it is required that xymon should show its state as green and same for other tests of same node. Nodes powered down by scheduler are identified by pbsnodes command which will show state as power. -> If the node is going down by some other reason other that powering down by scheduler, it should show red like normal clients.
Assuming your scheduler can have shell script hooks attached to events, I'd add something to send a "disable" command before it brings a node down, and then re-enable as it comes back up. If the nodes are being powered down without state being saved (eg, not suspending/resuming themselves), then just disable "until OK", otherwise I'd use some arbitrary future value. Relevant tests will be blue (not green, as requested), but that will be handled as a non-event for SLA purposes. Separately, it might be a good idea to have a separate server-side test that sends node state about each node to xymon independent of the node itself. That test is a fine place to put logic as well. HTH, -jc
list Pankaj Dorlikar
Hi, Thank you for proving pointers and important clues. 1) Query regarding "server-side test" : We can know the status of the "down" nodes which are down as per schedular's instructions. But how this information will help in setting the blue/green color for those nodes in xymon web page? I mean how to send this data to xymon server? Also will it cover all the tests? 2) How client cas send to send a "disable" command to server? thank you -pankaj
▸
On 8/14/12, user-87556346d4af@xymon.invalid <user-87556346d4af@xymon.invalid> wrote:We are using xymon-4.2.2 on rhel 5.2 server and more than 200 clients (HPC Cluster nodes). Our requirement is : -> If the node is powered down by scheduler for saving the power, it is required that xymon should show its state as green and same for other tests of same node. Nodes powered down by scheduler are identified by pbsnodes command which will show state as power. -> If the node is going down by some other reason other that powering down by scheduler, it should show red like normal clients.Assuming your scheduler can have shell script hooks attached to events, I'd add something to send a "disable" command before it brings a node down, and then re-enable as it comes back up. If the nodes are being powered down without state being saved (eg, not suspending/resuming themselves), then just disable "until OK", otherwise I'd use some arbitrary future value. Relevant tests will be blue (not green, as requested), but that will be handled as a non-event for SLA purposes. Separately, it might be a good idea to have a separate server-side test that sends node state about each node to xymon independent of the node itself. That test is a fine place to put logic as well. HTH, -jc
--
Pankaj V. Dorlikar
list Ryan Novosielski
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 What he is saying is that if there is an event that takes place where you can execute a script at the time it happens, you can disable the server by using the main binary's "disable" function. This binary used to be called "bb" but is now called "xymon" -- take a look at its man page to see how to send a disable message.
▸
On 08/14/2012 03:55 AM, pankaj dorlikar wrote:Hi, Thank you for proving pointers and important clues. 1) Query regarding "server-side test" : We can know the status of the "down" nodes which are down as per schedular's instructions. But how this information will help in setting the blue/green color for those nodes in xymon web page? I mean how to send this data to xymon server? Also will it cover all the tests? 2) How client cas send to send a "disable" command to server? thank you -pankaj On 8/14/12, user-87556346d4af@xymon.invalid <user-87556346d4af@xymon.invalid> wrote:We are using xymon-4.2.2 on rhel 5.2 server and more than 200 clients (HPC Cluster nodes). Our requirement is : -> If the node is powered down by scheduler for saving the power, it is required that xymon should show its state as green and same for other tests of same node. Nodes powered down by scheduler are identified by pbsnodes command which will show state as power. -> If the node is going down by some other reason other that powering down by scheduler, it should show red like normal clients.Assuming your scheduler can have shell script hooks attached to events, I'd add something to send a "disable" command before it brings a node down, and then re-enable as it comes back up. If the nodes are being powered down without state being saved (eg, not suspending/resuming themselves), then just disable "until OK", otherwise I'd use some arbitrary future value. Relevant tests will be blue (not green, as requested), but that will be handled as a non-event for SLA purposes. Separately, it might be a good idea to have a separate server-side test that sends node state about each node to xymon independent of the node itself. That test is a fine place to put logic as well. HTH, -jc
- -- - ---- _ _ _ _ ___ _ _ _
|Y#| | | |\/| | \ |\ | | |Ryan Novosielski - Sr. Systems Programmer |$&| |__| | | |__/ | \| _| |user-ae4522577e16@xymon.invalid - 973/972.0922 (2-0922) \__/ Univ. of Med. and Dent.|IST/EI-Academic Svcs. - ADMC 450, Newark -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlAqFsEACgkQmb+gadEcsb53xACfVP9x3ThR0zKtrYFVfVhHzJoI JNQAoLUaRTt3AcQmrhoArknmclS7WkPw =jBNe -----END PGP SIGNATURE-----
list Pankaj Dorlikar
---------- Forwarded message ---------- From: pankaj dorlikar <user-93d3572686c4@xymon.invalid> Date: Tue, 14 Aug 2012 16:34:00 +0530 Subject: Re: [Xymon] Green status To: Ryan Novosielski <user-ae4522577e16@xymon.invalid> Hi, thank you for reply. But at any point of time, only some of the nodes will be down and all the other nodes will be up. If the server itself goes down, the monitoring of rest of the working nodes will be affected.
▸
On 8/14/12, Ryan Novosielski <user-ae4522577e16@xymon.invalid> wrote:-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 What he is saying is that if there is an event that takes place where you can execute a script at the time it happens, you can disable the server by using the main binary's "disable" function. This binary used to be called "bb" but is now called "xymon" -- take a look at its man page to see how to send a disable message. On 08/14/2012 03:55 AM, pankaj dorlikar wrote:Hi, Thank you for proving pointers and important clues. 1) Query regarding "server-side test" : We can know the status of the "down" nodes which are down as per schedular's instructions. But how this information will help in setting the blue/green color for those nodes in xymon web page? I mean how to send this data to xymon server? Also will it cover all the tests? 2) How client cas send to send a "disable" command to server? thank you -pankaj On 8/14/12, user-87556346d4af@xymon.invalid <user-87556346d4af@xymon.invalid> wrote:We are using xymon-4.2.2 on rhel 5.2 server and more than 200 clients (HPC Cluster nodes). Our requirement is : -> If the node is powered down by scheduler for saving the power, it is required that xymon should show its state as green and same for other tests of same node. Nodes powered down by scheduler are identified by pbsnodes command which will show state as power. -> If the node is going down by some other reason other that powering down by scheduler, it should show red like normal clients.Assuming your scheduler can have shell script hooks attached to events, I'd add something to send a "disable" command before it brings a node down, and then re-enable as it comes back up. If the nodes are being powered down without state being saved (eg, not suspending/resuming themselves), then just disable "until OK", otherwise I'd use some arbitrary future value. Relevant tests will be blue (not green, as requested), but that will be handled as a non-event for SLA purposes. Separately, it might be a good idea to have a separate server-side test that sends node state about each node to xymon independent of the node itself. That test is a fine place to put logic as well. HTH, -jc- -- - ---- _ _ _ _ ___ _ _ _ |Y#| | | |\/| | \ |\ | | |Ryan Novosielski - Sr. Systems Programmer |$&| |__| | | |__/ | \| _| |user-ae4522577e16@xymon.invalid - 973/972.0922 (2-0922) \__/ Univ. of Med. and Dent.|IST/EI-Academic Svcs. - ADMC 450, Newark -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlAqFsEACgkQmb+gadEcsb53xACfVP9x3ThR0zKtrYFVfVhHzJoI JNQAoLUaRTt3AcQmrhoArknmclS7WkPw =jBNe -----END PGP SIGNATURE-----
--
Pankaj V. Dorlikar
--
Pankaj V. Dorlikar
list Steven Carr
How are you monitoring the nodes? do you have a xymon client on each of the nodes or are you doing a simple "ping" check to the node? If you are just doing a simple ping check then, off the top of my head, I would make all nodes "noconn" in the hosts.cfg so Xymon doesn't actually ping them anymore and write a script which uses the data you have to ping nodes and then work out if the node should be up or not, and if the node is down and it shouldn't be then trigger a red alarm for that node. Steve
▸
On 14 August 2012 12:05, pankaj dorlikar <user-93d3572686c4@xymon.invalid> wrote:
---------- Forwarded message ---------- From: pankaj dorlikar <user-93d3572686c4@xymon.invalid> Date: Tue, 14 Aug 2012 16:34:00 +0530 Subject: Re: [Xymon] Green status To: Ryan Novosielski <user-ae4522577e16@xymon.invalid> Hi, thank you for reply. But at any point of time, only some of the nodes will be down and all the other nodes will be up. If the server itself goes down, the monitoring of rest of the working nodes will be affected. On 8/14/12, Ryan Novosielski <user-ae4522577e16@xymon.invalid> wrote:-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 What he is saying is that if there is an event that takes place where you can execute a script at the time it happens, you can disable the server by using the main binary's "disable" function. This binary used to be called "bb" but is now called "xymon" -- take a look at its man page to see how to send a disable message. On 08/14/2012 03:55 AM, pankaj dorlikar wrote:Hi, Thank you for proving pointers and important clues. 1) Query regarding "server-side test" : We can know the status of the "down" nodes which are down as per schedular's instructions. But how this information will help in setting the blue/green color for those nodes in xymon web page? I mean how to send this data to xymon server? Also will it cover all the tests? 2) How client cas send to send a "disable" command to server? thank you -pankaj On 8/14/12, user-87556346d4af@xymon.invalid <user-87556346d4af@xymon.invalid> wrote:We are using xymon-4.2.2 on rhel 5.2 server and more than 200 clients (HPC Cluster nodes). Our requirement is : -> If the node is powered down by scheduler for saving the power, it is required that xymon should show its state as green and same for other tests of same node. Nodes powered down by scheduler are identified by pbsnodes command which will show state as power. -> If the node is going down by some other reason other that powering down by scheduler, it should show red like normal clients.Assuming your scheduler can have shell script hooks attached to events, I'd add something to send a "disable" command before it brings a node down, and then re-enable as it comes back up. If the nodes are being powered down without state being saved (eg, not suspending/resuming themselves), then just disable "until OK", otherwise I'd use some arbitrary future value. Relevant tests will be blue (not green, as requested), but that will be handled as a non-event for SLA purposes. Separately, it might be a good idea to have a separate server-side test that sends node state about each node to xymon independent of the node itself. That test is a fine place to put logic as well. HTH, -jc- -- - ---- _ _ _ _ ___ _ _ _ |Y#| | | |\/| | \ |\ | | |Ryan Novosielski - Sr. Systems Programmer |$&| |__| | | |__/ | \| _| |user-ae4522577e16@xymon.invalid - 973/972.0922 (2-0922) \__/ Univ. of Med. and Dent.|IST/EI-Academic Svcs. - ADMC 450, Newark -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlAqFsEACgkQmb+gadEcsb53xACfVP9x3ThR0zKtrYFVfVhHzJoI JNQAoLUaRTt3AcQmrhoArknmclS7WkPw =jBNe -----END PGP SIGNATURE------- Pankaj V. Dorlikar -- Pankaj V. Dorlikar
list Pankaj Dorlikar
hi, thanks for reply. We have clients installed on all the nodes. At any point of time, the nodes on which job is not running will be powered down. if new job comes, these nodes be powered up and some other nodes will go down which are not running any job.
▸
On 8/14/12, Steven Carr <user-923b20c0d620@xymon.invalid> wrote:How are you monitoring the nodes? do you have a xymon client on each of the nodes or are you doing a simple "ping" check to the node? If you are just doing a simple ping check then, off the top of my head, I would make all nodes "noconn" in the hosts.cfg so Xymon doesn't actually ping them anymore and write a script which uses the data you have to ping nodes and then work out if the node should be up or not, and if the node is down and it shouldn't be then trigger a red alarm for that node. Steve On 14 August 2012 12:05, pankaj dorlikar <user-93d3572686c4@xymon.invalid> wrote:---------- Forwarded message ---------- From: pankaj dorlikar <user-93d3572686c4@xymon.invalid> Date: Tue, 14 Aug 2012 16:34:00 +0530 Subject: Re: [Xymon] Green status To: Ryan Novosielski <user-ae4522577e16@xymon.invalid> Hi, thank you for reply. But at any point of time, only some of the nodes will be down and all the other nodes will be up. If the server itself goes down, the monitoring of rest of the working nodes will be affected. On 8/14/12, Ryan Novosielski <user-ae4522577e16@xymon.invalid> wrote:-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 What he is saying is that if there is an event that takes place where you can execute a script at the time it happens, you can disable the server by using the main binary's "disable" function. This binary used to be called "bb" but is now called "xymon" -- take a look at its man page to see how to send a disable message. On 08/14/2012 03:55 AM, pankaj dorlikar wrote:Hi, Thank you for proving pointers and important clues. 1) Query regarding "server-side test" : We can know the status of the "down" nodes which are down as per schedular's instructions. But how this information will help in setting the blue/green color for those nodes in xymon web page? I mean how to send this data to xymon server? Also will it cover all the tests? 2) How client cas send to send a "disable" command to server? thank you -pankaj On 8/14/12, user-87556346d4af@xymon.invalid <user-87556346d4af@xymon.invalid> wrote:We are using xymon-4.2.2 on rhel 5.2 server and more than 200 clients (HPC Cluster nodes). Our requirement is : -> If the node is powered down by scheduler for saving the power, it is required that xymon should show its state as green and same for other tests of same node. Nodes powered down by scheduler are identified by pbsnodes command which will show state as power. -> If the node is going down by some other reason other that powering down by scheduler, it should show red like normal clients.Assuming your scheduler can have shell script hooks attached to events, I'd add something to send a "disable" command before it brings a node down, and then re-enable as it comes back up. If the nodes are being powered down without state being saved (eg, not suspending/resuming themselves), then just disable "until OK", otherwise I'd use some arbitrary future value. Relevant tests will be blue (not green, as requested), but that will be handled as a non-event for SLA purposes. Separately, it might be a good idea to have a separate server-side test that sends node state about each node to xymon independent of the node itself. That test is a fine place to put logic as well. HTH, -jc- -- - ---- _ _ _ _ ___ _ _ _ |Y#| | | |\/| | \ |\ | | |Ryan Novosielski - Sr. Systems Programmer |$&| |__| | | |__/ | \| _| |user-ae4522577e16@xymon.invalid - 973/972.0922 (2-0922) \__/ Univ. of Med. and Dent.|IST/EI-Academic Svcs. - ADMC 450, Newark -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlAqFsEACgkQmb+gadEcsb53xACfVP9x3ThR0zKtrYFVfVhHzJoI JNQAoLUaRTt3AcQmrhoArknmclS7WkPw =jBNe -----END PGP SIGNATURE------- Pankaj V. Dorlikar -- Pankaj V. Dorlikar
-- Pankaj V. Dorlikar
list Steven Carr
So you could also flag the nodes with the "dialup" flag which will allow the nodes to go down and Xymon wont complain that they are down, but you are still going to have to write your own server side script which determine if a host is down that shouldn't be down and then raise an alert for it. Xymon can't do that out of the box, and I'm not sure if any other monitoring systems can either, the majority of monitoring solutions expect nodes to be up 100% and only have exceptions for scheduled downtime etc. Steve
▸
On 14 August 2012 19:13, pankaj dorlikar <user-93d3572686c4@xymon.invalid> wrote:
hi, thanks for reply. We have clients installed on all the nodes. At any point of time, the nodes on which job is not running will be powered down. if new job comes, these nodes be powered up and some other nodes will go down which are not running any job. On 8/14/12, Steven Carr <user-923b20c0d620@xymon.invalid> wrote:How are you monitoring the nodes? do you have a xymon client on each of the nodes or are you doing a simple "ping" check to the node? If you are just doing a simple ping check then, off the top of my head, I would make all nodes "noconn" in the hosts.cfg so Xymon doesn't actually ping them anymore and write a script which uses the data you have to ping nodes and then work out if the node should be up or not, and if the node is down and it shouldn't be then trigger a red alarm for that node. Steve On 14 August 2012 12:05, pankaj dorlikar <user-93d3572686c4@xymon.invalid> wrote:---------- Forwarded message ---------- From: pankaj dorlikar <user-93d3572686c4@xymon.invalid> Date: Tue, 14 Aug 2012 16:34:00 +0530 Subject: Re: [Xymon] Green status To: Ryan Novosielski <user-ae4522577e16@xymon.invalid> Hi, thank you for reply. But at any point of time, only some of the nodes will be down and all the other nodes will be up. If the server itself goes down, the monitoring of rest of the working nodes will be affected. On 8/14/12, Ryan Novosielski <user-ae4522577e16@xymon.invalid> wrote:-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 What he is saying is that if there is an event that takes place where you can execute a script at the time it happens, you can disable the server by using the main binary's "disable" function. This binary used to be called "bb" but is now called "xymon" -- take a look at its man page to see how to send a disable message. On 08/14/2012 03:55 AM, pankaj dorlikar wrote:Hi, Thank you for proving pointers and important clues. 1) Query regarding "server-side test" : We can know the status of the "down" nodes which are down as per schedular's instructions. But how this information will help in setting the blue/green color for those nodes in xymon web page? I mean how to send this data to xymon server? Also will it cover all the tests? 2) How client cas send to send a "disable" command to server? thank you -pankaj On 8/14/12, user-87556346d4af@xymon.invalid <user-87556346d4af@xymon.invalid> wrote:We are using xymon-4.2.2 on rhel 5.2 server and more than 200 clients (HPC Cluster nodes). Our requirement is : -> If the node is powered down by scheduler for saving the power, it is required that xymon should show its state as green and same for other tests of same node. Nodes powered down by scheduler are identified by pbsnodes command which will show state as power. -> If the node is going down by some other reason other that powering down by scheduler, it should show red like normal clients.Assuming your scheduler can have shell script hooks attached to events, I'd add something to send a "disable" command before it brings a node down, and then re-enable as it comes back up. If the nodes are being powered down without state being saved (eg, not suspending/resuming themselves), then just disable "until OK", otherwise I'd use some arbitrary future value. Relevant tests will be blue (not green, as requested), but that will be handled as a non-event for SLA purposes. Separately, it might be a good idea to have a separate server-side test that sends node state about each node to xymon independent of the node itself. That test is a fine place to put logic as well. HTH, -jc- -- - ---- _ _ _ _ ___ _ _ _ |Y#| | | |\/| | \ |\ | | |Ryan Novosielski - Sr. Systems Programmer
|$&| |__| | | |__/ | \| _| |user-ae4522577e16@xymon.invalid - 973/972.0922(2-0922)
▸
\__/ Univ. of Med. and Dent.|IST/EI-Academic Svcs. - ADMC 450, Newark -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlAqFsEACgkQmb+gadEcsb53xACfVP9x3ThR0zKtrYFVfVhHzJoI JNQAoLUaRTt3AcQmrhoArknmclS7WkPw =jBNe -----END PGP SIGNATURE------- Pankaj V. Dorlikar -- Pankaj V. Dorlikar-- Pankaj V. Dorlikar
list Adam Goryachev
As other people have suggested, you can simply have the "shutdown" process which is responsible for deciding whether a machine is "idle" and needs to be shutdown, also being responsible for sending a "disable" message to xymon. At the time this process decides that a machine needs to be restarted, it will send an "enable" to xymon. This way xymon will monitor everything all the time, anything with a "blue" is down and supposed to be down, anything with green is up and OK, and anything red is.... well, is red. Regards, Adam
▸
On 08/15/2012 04:33 AM, Steven Carr wrote:So you could also flag the nodes with the "dialup" flag which will allow the nodes to go down and Xymon wont complain that they are down, but you are still going to have to write your own server side script which determine if a host is down that shouldn't be down and then raise an alert for it. Xymon can't do that out of the box, and I'm not sure if any other monitoring systems can either, the majority of monitoring solutions expect nodes to be up 100% and only have exceptions for scheduled downtime etc. Steve On 14 August 2012 19:13, pankaj dorlikar <user-93d3572686c4@xymon.invalid <mailto:user-93d3572686c4@xymon.invalid>> wrote: hi, thanks for reply. We have clients installed on all the nodes. At any point of time, the nodes on which job is not running will be powered down. if new job comes, these nodes be powered up and some other nodes will go down which are not running any job. On 8/14/12, Steven Carr <user-923b20c0d620@xymon.invalid <mailto:user-923b20c0d620@xymon.invalid>> wrote:How are you monitoring the nodes? do you have a xymon client on each of the nodes or are you doing a simple "ping" check to the node? If you are just doing a simple ping check then, off the top of my head, I would make all nodes "noconn" in the hosts.cfg so Xymon doesn't actually ping them anymore and write a script which uses the data you have to ping nodes and then work out if the node should be up or not, and if the node is down and it shouldn't be then trigger a red alarm for that node. Steve On 14 August 2012 12:05, pankaj dorlikar<user-93d3572686c4@xymon.invalid <mailto:user-93d3572686c4@xymon.invalid>> wrote:---------- Forwarded message ---------- From: pankaj dorlikar <user-93d3572686c4@xymon.invalid Date: Tue, 14 Aug 2012 16:34:00 +0530 Subject: Re: [Xymon] Green status To: Ryan Novosielski <user-ae4522577e16@xymon.invalid Hi, thank you for reply. But at any point of time, only some of the nodes will be down and all the other nodes will be up. If the server itself goes down, the monitoring of rest of the working nodes will be affected. On 8/14/12, Ryan Novosielski <user-ae4522577e16@xymon.invalid<mailto:user-ae4522577e16@xymon.invalid>> wrote:-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 What he is saying is that if there is an event that takes place where you can execute a script at the time it happens, you can disable the server by using the main binary's "disable" function. This binary used to be called "bb" but is now called "xymon" -- take a look at its man page to see how to send a disable message. On 08/14/2012 03:55 AM, pankaj dorlikar wrote:Hi, Thank you for proving pointers and important clues. 1) Query regarding "server-side test" : We can know the status of the"down"nodes which are down as per schedular's instructions. But how this information will help in setting the blue/green color for those nodes in xymon web page? I mean how to send this data to xymon server? Also will it cover all the tests? 2) How client cas send to send a "disable" command to server? thank you -pankaj On 8/14/12, user-87556346d4af@xymon.invalid
<mailto:user-87556346d4af@xymon.invalid> <user-87556346d4af@xymon.invalid
▸
<mailto:user-87556346d4af@xymon.invalid>> wrote:We are using xymon-4.2.2 on rhel 5.2 server and more than 200 clients (HPC Cluster nodes). Our requirement is : -> If the node is powered down by scheduler for saving the power, it is required that xymon should show its state as green and same for other tests of same node. Nodes powered down by scheduler are identified by pbsnodes command which will show state as power. -> If the node is going down by some other reason other that powering down by scheduler, it should show red like normal clients.Assuming your scheduler can have shell script hooks attached to events, I'd add something to send a "disable" command before it brings a node down, and then re-enable as it comes back up. If the nodes are being powered down without state being saved (eg, not suspending/resuming themselves), then just disable "until OK", otherwise I'd use some arbitrary future value. Relevant tests will be blue (not green, as requested), but that will be handled as a non-event for SLA purposes. Separately, it might be a good idea to have a separate server-side test that sends node state about each node to xymon independent of the node itself. That test is a fine place to put logic as well. HTH, -jc- -- - ---- _ _ _ _ ___ _ _ _ |Y#| | | |\/| | \ |\ | | |Ryan Novosielski - Sr. SystemsProgrammer|$&| |__| | | |__/ | \| _| |user-ae4522577e16@xymon.invalid
<mailto:user-ae4522577e16@xymon.invalid> - 973/972.0922 <tel:973%2F972.0922>
▸
(2-0922)\__/ Univ. of Med. and Dent.|IST/EI-Academic Svcs. - ADMC450, Newark-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlAqFsEACgkQmb+gadEcsb53xACfVP9x3ThR0zKtrYFVfVhHzJoI JNQAoLUaRTt3AcQmrhoArknmclS7WkPw =jBNe -----END PGP SIGNATURE------- Pankaj V. Dorlikar -- Pankaj V. Dorlikar-- Pankaj V. Dorlikar