Anyone Using qpage (SMS Send Tool) With Xymon
list Wiskbroom
Hello; Anyone out there successfully using qpage? I've read the "Configuring Xymon Alerts" help page, and am unable to get this working. I've installed qpage, and am having some issues getting it to work. I can send SMS pages via the command-line, so I know it is working, I am unable to send when setup in hobbit-alerts.cfg as: SCRIPT /usr/local/bin/sendsms UserName FORMAT=SMS SERVICE=cpu,disk COLOR=red,yellow RECOVERED REPEAT=1440 DURATION>90s Here is /usr/local/bin/sendsms: #!/bin/sh /usr/local/bin/qpage -l0 -m -p $* I've tried $1 and $*, both are inoperable. Thank you, .vp
list Eric Meddaugh
We use qpage with hobbit alerting, however we use it more like this: SERVICE=cpu,disk COLOR=red,yellow RECOVERED REPEAT=1440 DURATION>90s SCRIPT /usr/local/bin/sendsms UserName You can add a FORMAT=SMS to the SCRIPT line above if you'd like, we do not use the FORMAT=SMS. We have the script read in the variables and make the text message from there to send out, these are the variables passwd into the SCRIPT, it can use the RCPT as the "UserName" to txt: #BBCOLORLEVEL The current color of the status #BBALPHAMSG The full text of the status log triggering the alert #ACKCODE The "cookie" that can be used to acknowledge the alert #RCPT The recipient, from the SCRIPT entry #BBHOSTNAME The name of the host that the alert is about #MACHIP The IP-address of the host that has a problem #BBSVCNAME The name of the service that the alert is about #BBSVCNUM The numeric code for the service. From SVCCODES definition. #BBHOSTSVC HOSTNAME.SERVICE that the alert is about. #BBHOSTSVCCOMMAS As BBHOSTSVC, but dots in the hostname replaced with commas #BBNUMERIC A 22-digit number made by BBSVCNUM, MACHIP and ACKCODE. #RECOVERED Is "1" if the service has recovered. #EVENTSTART Timestamp when the current status (color) began. #DOWNSECS Number of seconds the service has been down. #DOWNSECSMSG When recovered, holds the text "Event duration : N" where N is the DOWNSECS value. #CFID Line-number in the hobbit-alerts.cfg file that caused the script to be invoked. Can be useful when troubleshooting alert configuration rules.
▸
-----Original Message-----
From: user-ddebaeecde97@xymon.invalid [mailto:user-ddebaeecde97@xymon.invalid]
Sent: Thursday, June 10, 2010 11:30 AM
To: user-ae9b8668bcde@xymon.invalid
Subject: [hobbit] Anyone Using qpage (SMS Send Tool) With Xymon
Hello;
Anyone out there successfully using qpage? I've read the "Configuring
Xymon Alerts" help page, and am unable to get this working.
I've installed qpage, and am having some issues getting it to work. I can send SMS pages via the command-line, so I know it is working, I am unable to send when setup in hobbit-alerts.cfg as:
SCRIPT /usr/local/bin/sendsms UserName FORMAT=SMS SERVICE=cpu,disk COLOR=red,yellow RECOVERED REPEAT=1440 DURATION>90s
Here is /usr/local/bin/sendsms:
#!/bin/sh
/usr/local/bin/qpage -l0 -m -p $*
I've tried $1 and $*, both are inoperable.
Thank you,
.vp
list Wiskbroom
Hmm, I have SERVICE and other info *after* the SCRIPT variable, when I tried yours, I got attempts to qpage for other disk conditions. Could you please provide me with the entire sendsms script? Thanks, .vp
▸
We use qpage with hobbit alerting, however we use it more like this: SERVICE=cpu,disk COLOR=red,yellow RECOVERED REPEAT=1440 DURATION>90s SCRIPT /usr/local/bin/sendsms UserName You can add a FORMAT=SMS to the SCRIPT line above if you'd like, we do not use the FORMAT=SMS. We have the script read in the variables and make the text message from there to send out, these are the variables passwd into the SCRIPT, it can use the RCPT as the "UserName" to txt: #BBCOLORLEVEL The current color of the status #BBALPHAMSG The full text of the status log triggering the alert #ACKCODE The "cookie" that can be used to acknowledge the alert #RCPT The recipient, from the SCRIPT entry #BBHOSTNAME The name of the host that the alert is about #MACHIP The IP-address of the host that has a problem #BBSVCNAME The name of the service that the alert is about #BBSVCNUM The numeric code for the service. From SVCCODES definition. #BBHOSTSVC HOSTNAME.SERVICE that the alert is about. #BBHOSTSVCCOMMAS As BBHOSTSVC, but dots in the hostname replaced with commas #BBNUMERIC A 22-digit number made by BBSVCNUM, MACHIP and ACKCODE. #RECOVERED Is "1" if the service has recovered. #EVENTSTART Timestamp when the current status (color) began. #DOWNSECS Number of seconds the service has been down. #DOWNSECSMSG When recovered, holds the text "Event duration : N" where N is the DOWNSECS value. #CFID Line-number in the hobbit-alerts.cfg file that caused the script to be invoked. Can be useful when troubleshooting alert configuration rules. -----Original Message----- From: user-ddebaeecde97@xymon.invalid [mailto:user-ddebaeecde97@xymon.invalid] Sent: Thursday, June 10, 2010 11:30 AM To: user-ae9b8668bcde@xymon.invalid Subject: [hobbit] Anyone Using qpage (SMS Send Tool) With Xymon Hello; Anyone out there successfully using qpage? I've read the "Configuring Xymon Alerts" help page, and am unable to get this working. I've installed qpage, and am having some issues getting it to work. I can send SMS pages via the command-line, so I know it is working, I am unable to send when setup in hobbit-alerts.cfg as: SCRIPT /usr/local/bin/sendsms UserName FORMAT=SMS SERVICE=cpu,disk COLOR=red,yellow RECOVERED REPEAT=1440 DURATION>90s Here is /usr/local/bin/sendsms: #!/bin/sh /usr/local/bin/qpage -l0 -m -p $* I've tried $1 and $*, both are inoperable. Thank you, .vp
list Sean Clark
I have come across a funny issue, and am wondering if it's a bug - it certainly doesn't seem to be the desired behavior, and I wonder if anyone can help me with it. Here is the scenario I have a device that is configured in hobbit-alerts.cfg like this: PAGE=%foodev/foocmt SCRIPT=/sw/xymon/server/scripts/briefEmailRegularImportance user-437689af665c@xymon.invalid REPEAT=60 COLOR=red RECOVERED SCRIPT=/sw/xymon/server/scripts/FullEmailRegularImportance user-0858b16b7c0b@xymon.invalid DURATION>20 REPEAT=60 It turns red, and calls the first script The person who got the first email sends a hobbitdack with the proper cookie for the test/pair and it all is well 2 hours pass - it has not called the second line, because it is "ack'd" I restart Xymon -- it loads the hobbitdboard from the .chk file, that host/test pair has same cookie, same ack message BUT - it instantly calls both scripts as soon as it comes online - even thought it had been "acked" Has anyone seen this/found a workaround/know what I mean? -Sean This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.
list Josh Luthman
Are you expecting engineer to be emailed when noc isn't? Is the problem that engineer isn't being notified? If so can you click the "info" icon for one of the hosts? You should see both email addresses. Obviously the problem is with the second SCRIPT or the collision of two SCRIPT commands. Has anyone tested to see if the second one is ever interpreted? You may want to try this: #begin PAGE=%foodev/foocmt SCRIPT=/sw/xymon/server/scripts/briefEmailRegularImportance user-437689af665c@xymon.invalid REPEAT=60 COLOR=red RECOVERED PAGE=%foodev/foocmt SCRIPT=/sw/xymon/server/scripts/FullEmailRegularImportance user-0858b16b7c0b@xymon.invalid DURATION>20 REPEAT=60 #end I can say this works for 100% certainty: HOST=%.*\.imaginenetworksllc\.com MAIL user-2cb415b7efbb@xymon.invalid COLOR=RED DURATION>2m REPEAT=60 RECOVERED FORMAT=SMS HOST=* MAIL user-4c45a83f15cb@xymon.invalid COLOR=RED DURATION>2m REPEAT=60 RECOVERED Josh Luthman Office: XXX-XXX-XXXX Direct: XXX-XXX-XXXX XXXX Wayne St Suite XXXX Troy, OH XXXXX “Success is not final, failure is not fatal: it is the courage to continue that counts.” --- Winston Churchill
▸
On Thu, Jun 10, 2010 at 4:32 PM, Clark, Sean <user-2db5fbcae9a7@xymon.invalid> wrote:I have come across a funny issue, and am wondering if it's a bug - it certainly doesn't seem to be the desired behavior, and I wonder if anyone can help me with it. Here is the scenario I have a device that is configured in hobbit-alerts.cfg like this: PAGE=%foodev/foocmt SCRIPT=/sw/xymon/server/scripts/briefEmailRegularImportance user-437689af665c@xymon.invalid REPEAT=60 COLOR=red RECOVERED SCRIPT=/sw/xymon/server/scripts/FullEmailRegularImportance user-0858b16b7c0b@xymon.invalid DURATION>20 REPEAT=60 It turns red, and calls the first script The person who got the first email sends a hobbitdack with the proper cookie for the test/pair and it all is well 2 hours pass - it has not called the second line, because it is "ack'd" I restart Xymon -- it loads the hobbitdboard from the .chk file, that host/test pair has same cookie, same ack message BUT - it instantly calls both scripts as soon as it comes online - even thought it had been "acked" Has anyone seen this/found a workaround/know what I mean? -Sean This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.
list Sean Clark
It's an escalation - if it's been in alert state for > 20 minutes, page engineer, unless it's been ack'd This worked well for us with bb btf, but with hobbit, it works well unless you restart - like I said on restart, it act's like none of the alerts have been ack'd and instantly hitting all rules, instead of realizing that it was in an ack state, and none of the scripts need to be run -Sean
▸
-----Original Message-----
From: Josh Luthman [mailto:user-4c45a83f15cb@xymon.invalid]
Sent: Thursday, June 10, 2010 4:49 PM
To: user-ae9b8668bcde@xymon.invalid
Subject: Re: [hobbit] Bug or Undesired behavior on restart - Xymon 4.2.3
Are you expecting engineer to be emailed when noc isn't? Is the
problem that engineer isn't being notified?
If so can you click the "info" icon for one of the hosts? You should
see both email addresses. Obviously the problem is with the second
SCRIPT or the collision of two SCRIPT commands. Has anyone tested to
see if the second one is ever interpreted?
You may want to try this:
#begin
PAGE=%foodev/foocmt
SCRIPT=/sw/xymon/server/scripts/briefEmailRegularImportance
user-437689af665c@xymon.invalid REPEAT=60 COLOR=red RECOVERED
PAGE=%foodev/foocmt
SCRIPT=/sw/xymon/server/scripts/FullEmailRegularImportance
user-0858b16b7c0b@xymon.invalid DURATION>20 REPEAT=60
#end
I can say this works for 100% certainty:
HOST=%.*\.imaginenetworksllc\.com
MAIL user-2cb415b7efbb@xymon.invalid COLOR=RED DURATION>2m REPEAT=60
RECOVERED FORMAT=SMS
HOST=*
MAIL user-4c45a83f15cb@xymon.invalid COLOR=RED DURATION>2m REPEAT=60 RECOVERED
Josh Luthman
Office: XXX-XXX-XXXX
Direct: XXX-XXX-XXXX
XXXX Wayne St
Suite XXXX
Troy, OH XXXXX
"Success is not final, failure is not fatal: it is the courage to
continue that counts."
--- Winston Churchill
On Thu, Jun 10, 2010 at 4:32 PM, Clark, Sean <user-2db5fbcae9a7@xymon.invalid> wrote:I have come across a funny issue, and am wondering if it's a bug - it certainly doesn't seem to be the desired behavior, and I wonder if anyone can help me with it. Here is the scenario I have a device that is configured in hobbit-alerts.cfg like this: PAGE=%foodev/foocmt SCRIPT=/sw/xymon/server/scripts/briefEmailRegularImportance user-437689af665c@xymon.invalid REPEAT=60 COLOR=red RECOVERED SCRIPT=/sw/xymon/server/scripts/FullEmailRegularImportance user-0858b16b7c0b@xymon.invalid DURATION>20 REPEAT=60 It turns red, and calls the first script The person who got the first email sends a hobbitdack with the proper cookie for the test/pair and it all is well 2 hours pass - it has not called the second line, because it is "ack'd" I restart Xymon -- it loads the hobbitdboard from the .chk file, that host/test pair has same cookie, same ack message BUT - it instantly calls both scripts as soon as it comes online - even thought it had been "acked" Has anyone seen this/found a workaround/know what I mean? -Sean This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.
This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.