Hi.
I am trying to improve the html e-mail alert script a bit. I want the background to be blue if the cause of a recovery is a disable. Is there some variable sent to the alert script that indicates that a disable is the cause of a recovery, or do I have to create logic for this in the script, guessing based on the colors in the status message?
/Johan
I haven't tried this but I assume you could add the $bbcolorlevel "blue" to this script and add a status message of your choice to indicate it's been disabled?
I think your idea is a good one and I'm going to attempt to implement it on my system.
#!/bin/bash
if [ "$RECOVERED" -eq 1 ]; then STATUS="RECOVERED" else case $BBCOLORLEVEL in red) STATUS="CRITICAL" ;; yellow) STATUS="WARNING" ;; purple) STATUS="stopped reporting" ;; *) STATUS="unknown status" ;; esac fi
MESSAGE="To: $RCPT Subject: $BBHOSTNAME $STATUS Content-Type: text/plain X-Priority: 1 (Highest) X-MSMail-Priority: High
$BBALPHAMSG"
echo "$MESSAGE" | sendmail -t exit 0
From: Johan Sjöberg [mailto:johan.sjoberg at deltamanagement.se] Sent: Thursday, February 10, 2011 5:26 AM To: xymon at xymon.com Subject: [xymon] Alerts variables
Hi.
I am trying to improve the html e-mail alert script a bit. I want the background to be blue if the cause of a recovery is a disable. Is there some variable sent to the alert script that indicates that a disable is the cause of a recovery, or do I have to create logic for this in the script, guessing based on the colors in the status message?
/Johan
This e-mail message and any attached files are confidential and are intended solely for the use of the addressee(s) named above. If you are not the intended recipient, any review, use, or distribution of this e-mail message and any attached files is strictly prohibited.
This communication may contain material protected by Federal privacy regulations, attorney-client work product, or other privileges. If you have received this confidential communication in error, please notify the sender immediately by reply e-mail message and permanently delete the original message. To reply to our email administrator directly, send an email to: postmaster at orlandohealth.com .
If this e-mail message concerns a contract matter, be advised that no employee or agent is authorized to conclude any binding agreement on behalf of Orlando Health by e-mail without express written confirmation by an officer of the corporation. Any views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of Orlando Health.
This works in a test script... If Xymon actually sends the $bbcolorlevel of blue it should work in an alert script. I'll try that on a test host and see if it works properly.
#!/bin/bash
RCPT=daniel.nordquist at orhs.org BBHOSTNAME=test123 BBSVCNAME=testsvc BBCOLORLEVEL=blue BBALPHAMSG="This is the test message..." RECOVERED=1
if [ "$RECOVERED" -eq 1 ] && [ "$BBCOLORLEVEL" != blue ]; then STATUS="RECOVERED" else case $BBCOLORLEVEL in red) STATUS="CRITICAL" ;; yellow) STATUS="WARNING" ;; purple) STATUS="stopped reporting" ;; blue) STATUS="Alert Disabled" ;; *) STATUS="unknown status" ;; esac fi
MESSAGE="To: $RCPT Subject: $BBHOSTNAME $BBSVCNAME $STATUS Content-Type: text/plain X-Priority: 1 (Highest) X-MSMail-Priority: High $BBALPHAMSG"
echo "$MESSAGE" | sendmail -t exit 0
From: Nordquist, Daniel Sent: Friday, February 11, 2011 12:34 PM To: xymon at xymon.com Subject: [xymon] RE: Alerts variables
I haven't tried this but I assume you could add the $bbcolorlevel "blue" to this script and add a status message of your choice to indicate it's been disabled?
I think your idea is a good one and I'm going to attempt to implement it on my system.
#!/bin/bash
if [ "$RECOVERED" -eq 1 ]; then STATUS="RECOVERED" else case $BBCOLORLEVEL in red) STATUS="CRITICAL" ;; yellow) STATUS="WARNING" ;; purple) STATUS="stopped reporting" ;; *) STATUS="unknown status" ;; esac fi
MESSAGE="To: $RCPT Subject: $BBHOSTNAME $STATUS Content-Type: text/plain X-Priority: 1 (Highest) X-MSMail-Priority: High
$BBALPHAMSG"
echo "$MESSAGE" | sendmail -t exit 0
From: Johan Sjöberg [mailto:johan.sjoberg at deltamanagement.se] Sent: Thursday, February 10, 2011 5:26 AM To: xymon at xymon.com Subject: [xymon] Alerts variables
Hi.
I am trying to improve the html e-mail alert script a bit. I want the background to be blue if the cause of a recovery is a disable. Is there some variable sent to the alert script that indicates that a disable is the cause of a recovery, or do I have to create logic for this in the script, guessing based on the colors in the status message?
/Johan
This e-mail message and any attached files are confidential and are intended solely for the use of the addressee(s) named above. If you are not the intended recipient, any review, use, or distribution of this e-mail message and any attached files is strictly prohibited.
This communication may contain material protected by Federal privacy regulations, attorney-client work product, or other privileges. If you have received this confidential communication in error, please notify the sender immediately by reply e-mail message and permanently delete the original message. To reply to our email administrator directly, send an email to: postmaster at orlandohealth.com .
If this e-mail message concerns a contract matter, be advised that no employee or agent is authorized to conclude any binding agreement on behalf of Orlando Health by e-mail without express written confirmation by an officer of the corporation. Any views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of Orlando Health.
This e-mail message and any attached files are confidential and are intended solely for the use of the addressee(s) named above. If you are not the intended recipient, any review, use, or distribution of this e-mail message and any attached files is strictly prohibited.
This communication may contain material protected by Federal privacy regulations, attorney-client work product, or other privileges. If you have received this confidential communication in error, please notify the sender immediately by reply e-mail message and permanently delete the original message. To reply to our email administrator directly, send an email to: postmaster at orlandohealth.com .
If this e-mail message concerns a contract matter, be advised that no employee or agent is authorized to conclude any binding agreement on behalf of Orlando Health by e-mail without express written confirmation by an officer of the corporation. Any views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of Orlando Health.
Did NOT work in a real alert script...
Anyone know if Xymon sends the color blue or not? Is there another variable that indicates "disabled"?
From: Nordquist, Daniel Sent: Friday, February 11, 2011 12:54 PM To: xymon at xymon.com Subject: [xymon] RE: Alerts variables
This works in a test script... If Xymon actually sends the $bbcolorlevel of blue it should work in an alert script. I'll try that on a test host and see if it works properly.
#!/bin/bash
RCPT=daniel.nordquist at orhs.org BBHOSTNAME=test123 BBSVCNAME=testsvc BBCOLORLEVEL=blue BBALPHAMSG="This is the test message..." RECOVERED=1
if [ "$RECOVERED" -eq 1 ] && [ "$BBCOLORLEVEL" != blue ]; then STATUS="RECOVERED" else case $BBCOLORLEVEL in red) STATUS="CRITICAL" ;; yellow) STATUS="WARNING" ;; purple) STATUS="stopped reporting" ;; blue) STATUS="Alert Disabled" ;; *) STATUS="unknown status" ;; esac fi
MESSAGE="To: $RCPT Subject: $BBHOSTNAME $BBSVCNAME $STATUS Content-Type: text/plain X-Priority: 1 (Highest) X-MSMail-Priority: High $BBALPHAMSG"
echo "$MESSAGE" | sendmail -t exit 0
From: Nordquist, Daniel Sent: Friday, February 11, 2011 12:34 PM To: xymon at xymon.com Subject: [xymon] RE: Alerts variables
I haven't tried this but I assume you could add the $bbcolorlevel "blue" to this script and add a status message of your choice to indicate it's been disabled?
I think your idea is a good one and I'm going to attempt to implement it on my system.
#!/bin/bash
if [ "$RECOVERED" -eq 1 ]; then STATUS="RECOVERED" else case $BBCOLORLEVEL in red) STATUS="CRITICAL" ;; yellow) STATUS="WARNING" ;; purple) STATUS="stopped reporting" ;; *) STATUS="unknown status" ;; esac fi
MESSAGE="To: $RCPT Subject: $BBHOSTNAME $STATUS Content-Type: text/plain X-Priority: 1 (Highest) X-MSMail-Priority: High
$BBALPHAMSG"
echo "$MESSAGE" | sendmail -t exit 0
From: Johan Sjöberg [mailto:johan.sjoberg at deltamanagement.se] Sent: Thursday, February 10, 2011 5:26 AM To: xymon at xymon.com Subject: [xymon] Alerts variables
Hi.
I am trying to improve the html e-mail alert script a bit. I want the background to be blue if the cause of a recovery is a disable. Is there some variable sent to the alert script that indicates that a disable is the cause of a recovery, or do I have to create logic for this in the script, guessing based on the colors in the status message?
/Johan
This e-mail message and any attached files are confidential and are intended solely for the use of the addressee(s) named above. If you are not the intended recipient, any review, use, or distribution of this e-mail message and any attached files is strictly prohibited.
This communication may contain material protected by Federal privacy regulations, attorney-client work product, or other privileges. If you have received this confidential communication in error, please notify the sender immediately by reply e-mail message and permanently delete the original message. To reply to our email administrator directly, send an email to: postmaster at orlandohealth.com .
If this e-mail message concerns a contract matter, be advised that no employee or agent is authorized to conclude any binding agreement on behalf of Orlando Health by e-mail without express written confirmation by an officer of the corporation. Any views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of Orlando Health.
This e-mail message and any attached files are confidential and are intended solely for the use of the addressee(s) named above. If you are not the intended recipient, any review, use, or distribution of this e-mail message and any attached files is strictly prohibited.
This communication may contain material protected by Federal privacy regulations, attorney-client work product, or other privileges. If you have received this confidential communication in error, please notify the sender immediately by reply e-mail message and permanently delete the original message. To reply to our email administrator directly, send an email to: postmaster at orlandohealth.com .
If this e-mail message concerns a contract matter, be advised that no employee or agent is authorized to conclude any binding agreement on behalf of Orlando Health by e-mail without express written confirmation by an officer of the corporation. Any views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of Orlando Health.
This e-mail message and any attached files are confidential and are intended solely for the use of the addressee(s) named above. If you are not the intended recipient, any review, use, or distribution of this e-mail message and any attached files is strictly prohibited.
This communication may contain material protected by Federal privacy regulations, attorney-client work product, or other privileges. If you have received this confidential communication in error, please notify the sender immediately by reply e-mail message and permanently delete the original message. To reply to our email administrator directly, send an email to: postmaster at orlandohealth.com .
If this e-mail message concerns a contract matter, be advised that no employee or agent is authorized to conclude any binding agreement on behalf of Orlando Health by e-mail without express written confirmation by an officer of the corporation. Any views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of Orlando Health.
In <F09A4F6C0E7518488834791F4CD79B118AE82D543B at EXDB03.orhs.org> "Nordquist, Daniel" <Daniel.Nordquist at orlandohealth.com> writes:
Anyone know if Xymon sends the color blue or not? Is there another variable that indicates "disabled"?
Eh ... "blue" means "disabled". The purpose of disabling a test is exactly to STOP sending alerts. So you do not get alerts for a blue status.
Regards, Henrik
No, you don't get alerts, but you get a recovered message when you disable a test that is in alert state. And since we use th html_mail.pl, we currently get "red" e-mails with recovered status when someone disables an alert. I think it would look better with blue color in that case.
/Johan
-----Original Message----- From: Henrik Størner [mailto:henrik at hswn.dk] Sent: den 12 februari 2011 11:09 To: xymon at xymon.com Subject: Re: [xymon] RE: Alerts variables
In <F09A4F6C0E7518488834791F4CD79B118AE82D543B at EXDB03.orhs.org> "Nordquist, Daniel" <Daniel.Nordquist at orlandohealth.com> writes:
Anyone know if Xymon sends the color blue or not? Is there another variable that indicates "disabled"?
Eh ... "blue" means "disabled". The purpose of disabling a test is exactly to STOP sending alerts. So you do not get alerts for a blue status.
Regards, Henrik
To unsubscribe from the xymon list, send an e-mail to xymon-unsubscribe at xymon.com
In <B08F3F3D67451844A7A8A029FCC71E4C1937DC4F70 at WIN01.ad.deltamanagement.se> =?iso-8859-1?Q?Johan_Sj=F6berg?= <johan.sjoberg at deltamanagement.se> writes:
No, you don't get alerts, but you get a recovered message when you disable = a test that is in alert state. And since we use th html_mail.pl, we current= ly get "red" e-mails with recovered status when someone disables an alert. = I think it would look better with blue color in that case.
I am not familiar with "html_mail.pl" - is it something you invoke from a SCRIPT definition in the alerts.cfg file ?
The mails that Xymon generates includes the new status color in the message subject, so a recovery due to the test being disabled comes with a subject like "Xymon [000] server1:htt is disabled (BLUE)"
Regards, Henrik
Yes, exactly. It is a script from Xymonton that is invoked using SCRIPT. So I would like to know if any variable is passed to the script containing the status "disabled"
/Johan
-----Original Message----- From: Henrik Størner [mailto:henrik at hswn.dk] Sent: den 14 februari 2011 11:13 To: xymon at xymon.com Subject: Re: [xymon] RE: Alerts variables
In <B08F3F3D67451844A7A8A029FCC71E4C1937DC4F70 at WIN01.ad.deltamanag ement.se> =?iso-8859-1?Q?Johan_Sj=F6berg?= <johan.sjoberg at deltamanagement.se> writes:
No, you don't get alerts, but you get a recovered message when you disable = a test that is in alert state. And since we use th html_mail.pl, we current= ly get "red" e-mails with recovered status when someone disables an alert.
I think it would look better with blue color in that case.
I am not familiar with "html_mail.pl" - is it something you invoke from a SCRIPT definition in the alerts.cfg file ?
The mails that Xymon generates includes the new status color in the message subject, so a recovery due to the test being disabled comes with a subject like "Xymon [000] server1:htt is disabled (BLUE)"
Regards, Henrik
To unsubscribe from the xymon list, send an e-mail to xymon-unsubscribe at xymon.com
In <B08F3F3D67451844A7A8A029FCC71E4C1941CC1661 at WIN01.ad.deltamanagement.se> =?iso-8859-1?Q?Johan_Sj=F6berg?= <johan.sjoberg at deltamanagement.se> writes:
Yes, exactly. It is a script from Xymonton that is invoked using SCRIPT. So= I would like to know if any variable is passed to the script containing th= e status "disabled"
OK, this turned out to be a slightly larger change than I had anticipated. After testing things a bit, it dawned on me that neither the mail-messages nor the script-based alerts would be able to tell the difference between a genuine recovery (going "green") and a recovery due to the status being disabled. Which doesn't seem right. The patch below should solve this. For mail/SMS alerts the subject and message text has been changed from "recovered" to "disabled". For scripts this can be seen from the value of the RECOVERED variable - it will be "1" for a genuine recovery (unchanged from before) and "2" for a recover- by-disable. The BBCOLORLEVEL setting remains unchanged, i.e. it will NOT be blue. This is because BBCOLORLEVEL holds the value of the color that triggered the alert - not the current color of the status. Note: When you apply this patch (against 4.3.0-RC1), please run "make clean" and then "make" to build the package. Without the "make clean", some of the library modules will probably not get updated - causing weird results. Regards, Henrik Index: lib/loadalerts.c =================================================================== --- lib/loadalerts.c (revision 6631) +++ lib/loadalerts.c (working copy) @@ -958,7 +958,7 @@ return result; } - if (alert->state == A_RECOVERED) { + if ((alert->state == A_RECOVERED) || (alert->state == A_DISABLED)) { /* * Dont do the check until we are checking individual recipients (rulecrit is set). * You dont need to have RECOVERED on the top-level rule, it's enough if a recipient Index: lib/loadalerts.h =================================================================== --- lib/loadalerts.h (revision 6631) +++ lib/loadalerts.h (working copy) @@ -18,7 +18,7 @@ #if defined(LOCALCLIENT) || !defined(CLIENTONLY) #include <pcre.h> -typedef enum { A_PAGING, A_NORECIP, A_ACKED, A_RECOVERED, A_NOTIFY, A_DEAD } astate_t; +typedef enum { A_PAGING, A_NORECIP, A_ACKED, A_RECOVERED, A_DISABLED, A_NOTIFY, A_DEAD } astate_t; typedef struct activealerts_t { /* Identification of the alert */ Index: xymond/xymond_alert.c =================================================================== --- xymond/xymond_alert.c (revision 6631) +++ xymond/xymond_alert.c (working copy) @@ -75,8 +75,8 @@ activealerts_t *ahead = NULL; char *statename[] = { - /* A_PAGING, A_NORECIP, A_ACKED, A_RECOVERED, A_NOTIFY, A_DEAD */ - "paging", "norecip", "acked", "recovered", "notify", "dead" + /* A_PAGING, A_NORECIP, A_ACKED, A_RECOVERED, A_DISABLED, A_NOTIFY, A_DEAD */ + "paging", "norecip", "acked", "recovered", "disabled", "notify", "dead" }; char *find_name(RbtHandle tree, char *name) @@ -662,7 +662,7 @@ * Dont update the color here - we want recoveries to go out * only if the alert color triggered an alert */ - awalk->state = A_RECOVERED; + awalk->state = (newcolor == COL_BLUE) ? A_DISABLED : A_RECOVERED; } if (oldalertstatus != newalertstatus) { @@ -865,6 +865,7 @@ break; case A_RECOVERED: + case A_DISABLED: case A_NOTIFY: anytogo++; break; @@ -895,6 +896,7 @@ break; case A_RECOVERED: + case A_DISABLED: case A_NOTIFY: send_alert(awalk, notiflogfd); break; @@ -929,6 +931,7 @@ break; case A_RECOVERED: + case A_DISABLED: case A_NOTIFY: awalk->state = A_DEAD; /* Fall through */ Index: xymond/do_alert.c =================================================================== --- xymond/do_alert.c (revision 6631) +++ xymond/do_alert.c (working copy) @@ -225,6 +225,12 @@ alert->hostname, alert->testname, recip->cfid); break; + case A_DISABLED: + subjfmt = (include_configid ? "Xymon %s:%s disabled [cfid:%d]" : "Xymon %s:%s disabled"); + snprintf(subj, sizeof(subj)-1, subjfmt, + alert->hostname, alert->testname, recip->cfid); + break; + case A_NORECIP: case A_DEAD: /* Cannot happen */ @@ -310,6 +316,11 @@ alert->hostname, alert->testname); break; + case A_DISABLED: + sprintf(info, "%s:%s DISABLED", + alert->hostname, alert->testname); + break; + case A_NOTIFY: sprintf(info, "%s:%s NOTICE", alert->hostname, alert->testname); @@ -365,7 +376,7 @@ int first = 1; int alertcount = 0; time_t now = getcurrenttime(NULL); - char *alerttxt[A_DEAD+1] = { "Paging", "Acked", "Recovered", "Notify", "Dead" }; + char *alerttxt[A_DEAD+1] = { "Paging", "Acked", "Recovered", "Disabled", "Notify", "Dead" }; dbgprintf("send_alert %s:%s state %d\n", alert->hostname, alert->testname, (int)alert->state); traceprintf("send_alert %s:%s state %s\n", @@ -380,7 +391,7 @@ continue; } - if (recip->noalerts && ((alert->state == A_PAGING) || (alert->state == A_RECOVERED))) { + if (recip->noalerts && ((alert->state == A_PAGING) || (alert->state == A_RECOVERED) || (alert->state == A_DISABLED))) { traceprintf("Recipient '%s' dropped (NOALERT)\n", recip->recipient); continue; } @@ -408,7 +419,7 @@ } alertcount++; } - else if (alert->state == A_RECOVERED) { + else if ((alert->state == A_RECOVERED) || (alert->state == A_DISABLED)) { /* RECOVERED messages require that we've sent out an alert before */ repeat_t *rpt = NULL; @@ -463,7 +474,7 @@ timestamp, alert->hostname, alert->testname, alert->ip, mailrecip, recip->cfid, (long)now, servicecode(alert->testname)); - if (alert->state == A_RECOVERED) { + if ((alert->state == A_RECOVERED) || (alert->state == A_DISABLED)) { fprintf(logfd, " %ld\n", (long)(now - alert->eventstart)); } else { @@ -561,7 +572,17 @@ putenv(bbcolorlevel); recovered = (char *)malloc(strlen("RECOVERED=") + 2); - sprintf(recovered, "RECOVERED=%d", ((alert->state == A_RECOVERED) ? 1 : 0)); + switch (alert->state) { + case A_RECOVERED: + strcpy(recovered, "RECOVERED=1"); + break; + case A_DISABLED: + strcpy(recovered, "RECOVERED=2"); + break; + default: + strcpy(recovered, "RECOVERED=0"); + break; + } putenv(recovered); downsecs = (char *)malloc(strlen("DOWNSECS=") + 20); @@ -572,7 +593,7 @@ sprintf(eventtstamp, "EVENTSTART=%ld", (long)alert->eventstart); putenv(eventtstamp); - if (alert->state == A_RECOVERED) { + if ((alert->state == A_RECOVERED) || (alert->state == A_DISABLED)) { downsecsmsg = (char *)malloc(strlen("DOWNSECSMSG=Event duration :") + 20); sprintf(downsecsmsg, "DOWNSECSMSG=Event duration : %ld", (long)(getcurrenttime(NULL) - alert->eventstart)); } @@ -628,7 +649,7 @@ timestamp, alert->hostname, alert->testname, alert->ip, scriptrecip, (long)now, servicecode(alert->testname)); - if (alert->state == A_RECOVERED) { + if ((alert->state == A_RECOVERED) || (alert->state == A_DISABLED)) { fprintf(logfd, " %ld\n", (long)(now - alert->eventstart)); } else {
Can we apply this code to 4.2.3? -----Original Message----- From: Henrik Størner [mailto:henrik at hswn.dk] Sent: Monday, February 14, 2011 7:40 AM To: xymon at xymon.com Subject: Re: [xymon] RE: Alerts variables In <B08F3F3D67451844A7A8A029FCC71E4C1941CC1661 at WIN01.ad.deltamanagement.se> =?iso-8859-1?Q?Johan_Sj=F6berg?= <johan.sjoberg at deltamanagement.se> writes:
Yes, exactly. It is a script from Xymonton that is invoked using SCRIPT. So= I would like to know if any variable is passed to the script containing th= e status "disabled"
OK, this turned out to be a slightly larger change than I had anticipated. After testing things a bit, it dawned on me that neither the mail-messages nor the script-based alerts would be able to tell the difference between a genuine recovery (going "green") and a recovery due to the status being disabled. Which doesn't seem right. The patch below should solve this. For mail/SMS alerts the subject and message text has been changed from "recovered" to "disabled". For scripts this can be seen from the value of the RECOVERED variable - it will be "1" for a genuine recovery (unchanged from before) and "2" for a recover- by-disable. The BBCOLORLEVEL setting remains unchanged, i.e. it will NOT be blue. This is because BBCOLORLEVEL holds the value of the color that triggered the alert - not the current color of the status. Note: When you apply this patch (against 4.3.0-RC1), please run "make clean" and then "make" to build the package. Without the "make clean", some of the library modules will probably not get updated - causing weird results. Regards, Henrik Index: lib/loadalerts.c =================================================================== --- lib/loadalerts.c (revision 6631) +++ lib/loadalerts.c (working copy) @@ -958,7 +958,7 @@ return result; } - if (alert->state == A_RECOVERED) { + if ((alert->state == A_RECOVERED) || (alert->state == A_DISABLED)) { /* * Dont do the check until we are checking individual recipients (rulecrit is set). * You dont need to have RECOVERED on the top-level rule, it's enough if a recipient Index: lib/loadalerts.h =================================================================== --- lib/loadalerts.h (revision 6631) +++ lib/loadalerts.h (working copy) @@ -18,7 +18,7 @@ #if defined(LOCALCLIENT) || !defined(CLIENTONLY) #include <pcre.h> -typedef enum { A_PAGING, A_NORECIP, A_ACKED, A_RECOVERED, A_NOTIFY, A_DEAD } astate_t; +typedef enum { A_PAGING, A_NORECIP, A_ACKED, A_RECOVERED, A_DISABLED, A_NOTIFY, A_DEAD } astate_t; typedef struct activealerts_t { /* Identification of the alert */ Index: xymond/xymond_alert.c =================================================================== --- xymond/xymond_alert.c (revision 6631) +++ xymond/xymond_alert.c (working copy) @@ -75,8 +75,8 @@ activealerts_t *ahead = NULL; char *statename[] = { - /* A_PAGING, A_NORECIP, A_ACKED, A_RECOVERED, A_NOTIFY, A_DEAD */ - "paging", "norecip", "acked", "recovered", "notify", "dead" + /* A_PAGING, A_NORECIP, A_ACKED, A_RECOVERED, A_DISABLED, A_NOTIFY, A_DEAD */ + "paging", "norecip", "acked", "recovered", "disabled", "notify", "dead" }; char *find_name(RbtHandle tree, char *name) @@ -662,7 +662,7 @@ * Dont update the color here - we want recoveries to go out * only if the alert color triggered an alert */ - awalk->state = A_RECOVERED; + awalk->state = (newcolor == COL_BLUE) ? A_DISABLED : A_RECOVERED; } if (oldalertstatus != newalertstatus) { @@ -865,6 +865,7 @@ break; case A_RECOVERED: + case A_DISABLED: case A_NOTIFY: anytogo++; break; @@ -895,6 +896,7 @@ break; case A_RECOVERED: + case A_DISABLED: case A_NOTIFY: send_alert(awalk, notiflogfd); break; @@ -929,6 +931,7 @@ break; case A_RECOVERED: + case A_DISABLED: case A_NOTIFY: awalk->state = A_DEAD; /* Fall through */ Index: xymond/do_alert.c =================================================================== --- xymond/do_alert.c (revision 6631) +++ xymond/do_alert.c (working copy) @@ -225,6 +225,12 @@ alert->hostname, alert->testname, recip->cfid); break; + case A_DISABLED: + subjfmt = (include_configid ? "Xymon %s:%s disabled [cfid:%d]" : "Xymon %s:%s disabled"); + snprintf(subj, sizeof(subj)-1, subjfmt, + alert->hostname, alert->testname, recip->cfid); + break; + case A_NORECIP: case A_DEAD: /* Cannot happen */ @@ -310,6 +316,11 @@ alert->hostname, alert->testname); break; + case A_DISABLED: + sprintf(info, "%s:%s DISABLED", + alert->hostname, alert->testname); + break; + case A_NOTIFY: sprintf(info, "%s:%s NOTICE", alert->hostname, alert->testname); @@ -365,7 +376,7 @@ int first = 1; int alertcount = 0; time_t now = getcurrenttime(NULL); - char *alerttxt[A_DEAD+1] = { "Paging", "Acked", "Recovered", "Notify", "Dead" }; + char *alerttxt[A_DEAD+1] = { "Paging", "Acked", "Recovered", "Disabled", "Notify", "Dead" }; dbgprintf("send_alert %s:%s state %d\n", alert->hostname, alert->testname, (int)alert->state); traceprintf("send_alert %s:%s state %s\n", @@ -380,7 +391,7 @@ continue; } - if (recip->noalerts && ((alert->state == A_PAGING) || (alert->state == A_RECOVERED))) { + if (recip->noalerts && ((alert->state == A_PAGING) || (alert->state == A_RECOVERED) || (alert->state == A_DISABLED))) { traceprintf("Recipient '%s' dropped (NOALERT)\n", recip->recipient); continue; } @@ -408,7 +419,7 @@ } alertcount++; } - else if (alert->state == A_RECOVERED) { + else if ((alert->state == A_RECOVERED) || (alert->state == A_DISABLED)) { /* RECOVERED messages require that we've sent out an alert before */ repeat_t *rpt = NULL; @@ -463,7 +474,7 @@ timestamp, alert->hostname, alert->testname, alert->ip, mailrecip, recip->cfid, (long)now, servicecode(alert->testname)); - if (alert->state == A_RECOVERED) { + if ((alert->state == A_RECOVERED) || (alert->state == A_DISABLED)) { fprintf(logfd, " %ld\n", (long)(now - alert->eventstart)); } else { @@ -561,7 +572,17 @@ putenv(bbcolorlevel); recovered = (char *)malloc(strlen("RECOVERED=") + 2); - sprintf(recovered, "RECOVERED=%d", ((alert->state == A_RECOVERED) ? 1 : 0)); + switch (alert->state) { + case A_RECOVERED: + strcpy(recovered, "RECOVERED=1"); + break; + case A_DISABLED: + strcpy(recovered, "RECOVERED=2"); + break; + default: + strcpy(recovered, "RECOVERED=0"); + break; + } putenv(recovered); downsecs = (char *)malloc(strlen("DOWNSECS=") + 20); @@ -572,7 +593,7 @@ sprintf(eventtstamp, "EVENTSTART=%ld", (long)alert->eventstart); putenv(eventtstamp); - if (alert->state == A_RECOVERED) { + if ((alert->state == A_RECOVERED) || (alert->state == A_DISABLED)) { downsecsmsg = (char *)malloc(strlen("DOWNSECSMSG=Event duration :") + 20); sprintf(downsecsmsg, "DOWNSECSMSG=Event duration : %ld", (long)(getcurrenttime(NULL) - alert->eventstart)); } @@ -628,7 +649,7 @@ timestamp, alert->hostname, alert->testname, alert->ip, scriptrecip, (long)now, servicecode(alert->testname)); - if (alert->state == A_RECOVERED) { + if ((alert->state == A_RECOVERED) || (alert->state == A_DISABLED)) { fprintf(logfd, " %ld\n", (long)(now - alert->eventstart)); } else { To unsubscribe from the xymon list, send an e-mail to xymon-unsubscribe at xymon.com This e-mail message and any attached files are confidential and are intended solely for the use of the addressee(s) named above. If you are not the intended recipient, any review, use, or distribution of this e-mail message and any attached files is strictly prohibited. This communication may contain material protected by Federal privacy regulations, attorney-client work product, or other privileges. If you have received this confidential communication in error, please notify the sender immediately by reply e-mail message and permanently delete the original message. To reply to our email administrator directly, send an email to: postmaster at orlandohealth.com . If this e-mail message concerns a contract matter, be advised that no employee or agent is authorized to conclude any binding agreement on behalf of Orlando Health by e-mail without express written confirmation by an officer of the corporation. Any views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of Orlando Health.
In <F09A4F6C0E7518488834791F4CD79B118AE82D54DA at EXDB03.orhs.org> "Nordquist, Daniel" <Daniel.Nordquist at orlandohealth.com> writes:
Can we apply this code to 4.2.3?
Already done. Regards, Henrik
-----Original Message----- From: Henrik St=C3=B8rner [mailto:henrik at hswn.dk] Sent: Monday, February 14, 2011 7:40 AM To: xymon at xymon.com Subject: Re: [xymon] RE: Alerts variables
In <B08F3F3D67451844A7A8A029FCC71E4C1941CC1661 at WIN01.ad.deltamanagement.se>= =3D?iso-8859-1?Q?Johan_Sj=3DF6berg?=3D <johan.sjoberg at deltamanagement.se> = writes:
Yes, exactly. It is a script from Xymonton that is invoked using SCRIPT. S= o=3D I would like to know if any variable is passed to the script containing t= h=3D e status "disabled"
OK, this turned out to be a slightly larger change than I had anticipated. After testing things a bit, it dawned on me that neither the mail-messages nor the script-based alerts would be able to tell the difference between a genuine recovery (going "green") and a recovery due to the status being disabled.
Which doesn't seem right.
The patch below should solve this. For mail/SMS alerts the subject and message text has been changed from "recovered" to "disabled". For scripts this can be seen from the value of the RECOVERED variable - it will be "1" for a genuine recovery (unchanged from before) and "2" for a recover- by-disable.
The BBCOLORLEVEL setting remains unchanged, i.e. it will NOT be blue. This is because BBCOLORLEVEL holds the value of the color that triggered the alert - not the current color of the status.
Note: When you apply this patch (against 4.3.0-RC1), please run "make clean" and then "make" to build the package. Without the "make clean", some of the library modules will probably not get updated - causing weird results.
Regards, Henrik
Index: lib/loadalerts.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- lib/loadalerts.c (revision 6631) +++ lib/loadalerts.c (working copy) @@ -958,7 +958,7 @@ return result; }
- if (alert->state =3D=3D A_RECOVERED) { + if ((alert->state =3D=3D A_RECOVERED) || (alert->state =3D=3D A_DIS= ABLED)) { /* * Dont do the check until we are checking individual recip= ients (rulecrit is set). * You dont need to have RECOVERED on the top-level rule, i= t's enough if a recipient Index: lib/loadalerts.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- lib/loadalerts.h (revision 6631) +++ lib/loadalerts.h (working copy) @@ -18,7 +18,7 @@ #if defined(LOCALCLIENT) || !defined(CLIENTONLY) #include <pcre.h>
-typedef enum { A_PAGING, A_NORECIP, A_ACKED, A_RECOVERED, A_NOTIFY, A_DEAD= } astate_t; +typedef enum { A_PAGING, A_NORECIP, A_ACKED, A_RECOVERED, A_DISABLED, A_NO= TIFY, A_DEAD } astate_t;
typedef struct activealerts_t { /* Identification of the alert */ Index: xymond/xymond_alert.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- xymond/xymond_alert.c (revision 6631) +++ xymond/xymond_alert.c (working copy) @@ -75,8 +75,8 @@ activealerts_t *ahead =3D NULL;
char *statename[] =3D { - /* A_PAGING, A_NORECIP, A_ACKED, A_RECOVERED, A_NOTIFY, A_DEAD */ - "paging", "norecip", "acked", "recovered", "notify", "dead" + /* A_PAGING, A_NORECIP, A_ACKED, A_RECOVERED, A_DISABLED, A_NOTIFY,= A_DEAD */ + "paging", "norecip", "acked", "recovered", "disabled", "notify", "d= ead" };
char *find_name(RbtHandle tree, char *name) @@ -662,7 +662,7 @@ * Dont update the color here - we want rec= overies to go out * only if the alert color triggered an ale= rt */ - awalk->state =3D A_RECOVERED; + awalk->state =3D (newcolor =3D=3D COL_BLUE)= ? A_DISABLED : A_RECOVERED; }
if (oldalertstatus !=3D newalertstatus) { @@ -865,6 +865,7 @@ break;
case A_RECOVERED: + case A_DISABLED: case A_NOTIFY: anytogo++; break; @@ -895,6 +896,7 @@ break;
case A_RECOVERED: + case A_DISABLED: case A_NOTIFY: send_alert(awalk, notiflogf= d); break; @@ -929,6 +931,7 @@ break;
case A_RECOVERED: + case A_DISABLED: case A_NOTIFY: awalk->state =3D A_DEAD; /* Fall through */ Index: xymond/do_alert.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- xymond/do_alert.c (revision 6631) +++ xymond/do_alert.c (working copy) @@ -225,6 +225,12 @@ alert->hostname, alert->testname, recip->cfid); break;
+ case A_DISABLED: + subjfmt =3D (include_configid ? "Xymon %s:%s disabled [cfid= :%d]" : "Xymon %s:%s disabled"); + snprintf(subj, sizeof(subj)-1, subjfmt, + alert->hostname, alert->testname, recip->cfid); + break; + case A_NORECIP: case A_DEAD: /* Cannot happen */ @@ -310,6 +316,11 @@ alert->hostname, alert->testname); break;
+ case A_DISABLED: + sprintf(info, "%s:%s DISABLED", + alert->hostname, alert->testname); + break; + case A_NOTIFY: sprintf(info, "%s:%s NOTICE", alert->hostname, alert->testname); @@ -365,7 +376,7 @@ int first =3D 1; int alertcount =3D 0; time_t now =3D getcurrenttime(NULL); - char *alerttxt[A_DEAD+1] =3D { "Paging", "Acked", "Recovered", "Not= ify", "Dead" }; + char *alerttxt[A_DEAD+1] =3D { "Paging", "Acked", "Recovered", "Dis= abled", "Notify", "Dead" };
dbgprintf("send_alert %s:%s state %d\n", alert->hostname, alert->te= stname, (int)alert->state); traceprintf("send_alert %s:%s state %s\n", @@ -380,7 +391,7 @@ continue; }
- if (recip->noalerts && ((alert->state =3D=3D A_PAGING) || (= alert->state =3D=3D A_RECOVERED))) { + if (recip->noalerts && ((alert->state =3D=3D A_PAGING) || (= alert->state =3D=3D A_RECOVERED) || (alert->state =3D=3D A_DISABLED))) { traceprintf("Recipient '%s' dropped (NOALERT)\n", r= ecip->recipient); continue; } @@ -408,7 +419,7 @@ } alertcount++; } - else if (alert->state =3D=3D A_RECOVERED) { + else if ((alert->state =3D=3D A_RECOVERED) || (alert->state= =3D=3D A_DISABLED)) { /* RECOVERED messages require that we've sent out a= n alert before */ repeat_t *rpt =3D NULL;
@@ -463,7 +474,7 @@ timestamp, alert->h= ostname, alert->testname, alert->ip, mailreci= p, recip->cfid, (long)now, servicec= ode(alert->testname)); - if (alert->state =3D=3D A_R= ECOVERED) { + if ((alert->state =3D=3D A_= RECOVERED) || (alert->state =3D=3D A_DISABLED)) { fprintf(logfd, " %l= d\n", (long)(now - alert->eventstart)); } else { @@ -561,7 +572,17 @@ putenv(bbcolorlevel);
recovered =3D (char *)malloc(strlen= ("RECOVERED=3D") + 2); - sprintf(recovered, "RECOVERED=3D%d"= , ((alert->state =3D=3D A_RECOVERED) ? 1 : 0)); + switch (alert->state) { + case A_RECOVERED: + strcpy(recovered, "RECOVERE= D=3D1"); + break; + case A_DISABLED: + strcpy(recovered, "RECOVERE= D=3D2"); + break; + default: + strcpy(recovered, "RECOVERE= D=3D0"); + break; + } putenv(recovered);
downsecs =3D (char *)malloc(strlen(= "DOWNSECS=3D") + 20); @@ -572,7 +593,7 @@ sprintf(eventtstamp, "EVENTSTART=3D= %ld", (long)alert->eventstart); putenv(eventtstamp);
- if (alert->state =3D=3D A_RECOVERED= ) { + if ((alert->state =3D=3D A_RECOVERE= D) || (alert->state =3D=3D A_DISABLED)) { downsecsmsg =3D (char *)mal= loc(strlen("DOWNSECSMSG=3DEvent duration :") + 20); sprintf(downsecsmsg, "DOWNS= ECSMSG=3DEvent duration : %ld", (long)(getcurrenttime(NULL) - alert->events= tart)); } @@ -628,7 +649,7 @@ timestamp, alert->h= ostname, alert->testname, alert->ip, scriptre= cip, (long)now, servicecode(alert->= testname)); - if (alert->state =3D=3D A_R= ECOVERED) { + if ((alert->state =3D=3D A_= RECOVERED) || (alert->state =3D=3D A_DISABLED)) { fprintf(logfd, " %l= d\n", (long)(now - alert->eventstart)); } else {
To unsubscribe from the xymon list, send an e-mail to xymon-unsubscribe at xymon.com
This e-mail message and any attached files are confidential and are intende= d solely for the use of the addressee(s) named above. If you are not the in= tended recipient, any review, use, or distribution of this e-mail message a= nd any attached files is strictly prohibited.
This communication may contain material protected by Federal privacy regula= tions, attorney-client work product, or other privileges. If you have recei= ved this confidential communication in error, please notify the sender imme= diately by reply e-mail message and permanently delete the original message= . To reply to our email administrator directly, send an email to: postmas= ter at orlandohealth.com .
If this e-mail message concerns a contract matter, be advised that no emplo= yee or agent is authorized to conclude any binding agreement on behalf of O= rlando Health by e-mail without express written confirmation by an officer = of the corporation. Any views or opinions presented in this e-mail are sole= ly those of the author and do not necessarily represent those of Orlando He= alth.
To unsubscribe from the xymon list, send an e-mail to xymon-unsubscribe at xymon.com
I apologize for my confusion, but I don't understand what you mean by this. Is this code already in the 4.2.3 version I have installed, and I just need to use the proper scripting to look for the value of the recovery variable; ie - 1 or 2? -----Original Message----- From: Henrik Størner [mailto:henrik at hswn.dk] Sent: Thursday, February 17, 2011 3:23 AM To: xymon at xymon.com Subject: Re: [xymon] RE: Alerts variables In <F09A4F6C0E7518488834791F4CD79B118AE82D54DA at EXDB03.orhs.org> "Nordquist, Daniel" <Daniel.Nordquist at orlandohealth.com> writes:
Can we apply this code to 4.2.3?
Already done. Regards, Henrik
-----Original Message----- From: Henrik St=C3=B8rner [mailto:henrik at hswn.dk] Sent: Monday, February 14, 2011 7:40 AM To: xymon at xymon.com Subject: Re: [xymon] RE: Alerts variables
In <B08F3F3D67451844A7A8A029FCC71E4C1941CC1661 at WIN01.ad.deltamanagement.se>= =3D?iso-8859-1?Q?Johan_Sj=3DF6berg?=3D <johan.sjoberg at deltamanagement.se> = writes:
Yes, exactly. It is a script from Xymonton that is invoked using SCRIPT. S= o=3D I would like to know if any variable is passed to the script containing t= h=3D e status "disabled"
OK, this turned out to be a slightly larger change than I had anticipated. After testing things a bit, it dawned on me that neither the mail-messages nor the script-based alerts would be able to tell the difference between a genuine recovery (going "green") and a recovery due to the status being disabled.
Which doesn't seem right.
The patch below should solve this. For mail/SMS alerts the subject and message text has been changed from "recovered" to "disabled". For scripts this can be seen from the value of the RECOVERED variable - it will be "1" for a genuine recovery (unchanged from before) and "2" for a recover- by-disable.
The BBCOLORLEVEL setting remains unchanged, i.e. it will NOT be blue. This is because BBCOLORLEVEL holds the value of the color that triggered the alert - not the current color of the status.
Note: When you apply this patch (against 4.3.0-RC1), please run "make clean" and then "make" to build the package. Without the "make clean", some of the library modules will probably not get updated - causing weird results.
Regards, Henrik
Index: lib/loadalerts.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- lib/loadalerts.c (revision 6631) +++ lib/loadalerts.c (working copy) @@ -958,7 +958,7 @@ return result; }
- if (alert->state =3D=3D A_RECOVERED) { + if ((alert->state =3D=3D A_RECOVERED) || (alert->state =3D=3D A_DIS= ABLED)) { /* * Dont do the check until we are checking individual recip= ients (rulecrit is set). * You dont need to have RECOVERED on the top-level rule, i= t's enough if a recipient Index: lib/loadalerts.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- lib/loadalerts.h (revision 6631) +++ lib/loadalerts.h (working copy) @@ -18,7 +18,7 @@ #if defined(LOCALCLIENT) || !defined(CLIENTONLY) #include <pcre.h>
-typedef enum { A_PAGING, A_NORECIP, A_ACKED, A_RECOVERED, A_NOTIFY, A_DEAD= } astate_t; +typedef enum { A_PAGING, A_NORECIP, A_ACKED, A_RECOVERED, A_DISABLED, A_NO= TIFY, A_DEAD } astate_t;
typedef struct activealerts_t { /* Identification of the alert */ Index: xymond/xymond_alert.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- xymond/xymond_alert.c (revision 6631) +++ xymond/xymond_alert.c (working copy) @@ -75,8 +75,8 @@ activealerts_t *ahead =3D NULL;
char *statename[] =3D { - /* A_PAGING, A_NORECIP, A_ACKED, A_RECOVERED, A_NOTIFY, A_DEAD */ - "paging", "norecip", "acked", "recovered", "notify", "dead" + /* A_PAGING, A_NORECIP, A_ACKED, A_RECOVERED, A_DISABLED, A_NOTIFY,= A_DEAD */ + "paging", "norecip", "acked", "recovered", "disabled", "notify", "d= ead" };
char *find_name(RbtHandle tree, char *name) @@ -662,7 +662,7 @@ * Dont update the color here - we want rec= overies to go out * only if the alert color triggered an ale= rt */ - awalk->state =3D A_RECOVERED; + awalk->state =3D (newcolor =3D=3D COL_BLUE)= ? A_DISABLED : A_RECOVERED; }
if (oldalertstatus !=3D newalertstatus) { @@ -865,6 +865,7 @@ break;
case A_RECOVERED: + case A_DISABLED: case A_NOTIFY: anytogo++; break; @@ -895,6 +896,7 @@ break;
case A_RECOVERED: + case A_DISABLED: case A_NOTIFY: send_alert(awalk, notiflogf= d); break; @@ -929,6 +931,7 @@ break;
case A_RECOVERED: + case A_DISABLED: case A_NOTIFY: awalk->state =3D A_DEAD; /* Fall through */ Index: xymond/do_alert.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- xymond/do_alert.c (revision 6631) +++ xymond/do_alert.c (working copy) @@ -225,6 +225,12 @@ alert->hostname, alert->testname, recip->cfid); break;
+ case A_DISABLED: + subjfmt =3D (include_configid ? "Xymon %s:%s disabled [cfid= :%d]" : "Xymon %s:%s disabled"); + snprintf(subj, sizeof(subj)-1, subjfmt, + alert->hostname, alert->testname, recip->cfid); + break; + case A_NORECIP: case A_DEAD: /* Cannot happen */ @@ -310,6 +316,11 @@ alert->hostname, alert->testname); break;
+ case A_DISABLED: + sprintf(info, "%s:%s DISABLED", + alert->hostname, alert->testname); + break; + case A_NOTIFY: sprintf(info, "%s:%s NOTICE", alert->hostname, alert->testname); @@ -365,7 +376,7 @@ int first =3D 1; int alertcount =3D 0; time_t now =3D getcurrenttime(NULL); - char *alerttxt[A_DEAD+1] =3D { "Paging", "Acked", "Recovered", "Not= ify", "Dead" }; + char *alerttxt[A_DEAD+1] =3D { "Paging", "Acked", "Recovered", "Dis= abled", "Notify", "Dead" };
dbgprintf("send_alert %s:%s state %d\n", alert->hostname, alert->te= stname, (int)alert->state); traceprintf("send_alert %s:%s state %s\n", @@ -380,7 +391,7 @@ continue; }
- if (recip->noalerts && ((alert->state =3D=3D A_PAGING) || (= alert->state =3D=3D A_RECOVERED))) { + if (recip->noalerts && ((alert->state =3D=3D A_PAGING) || (= alert->state =3D=3D A_RECOVERED) || (alert->state =3D=3D A_DISABLED))) { traceprintf("Recipient '%s' dropped (NOALERT)\n", r= ecip->recipient); continue; } @@ -408,7 +419,7 @@ } alertcount++; } - else if (alert->state =3D=3D A_RECOVERED) { + else if ((alert->state =3D=3D A_RECOVERED) || (alert->state= =3D=3D A_DISABLED)) { /* RECOVERED messages require that we've sent out a= n alert before */ repeat_t *rpt =3D NULL;
@@ -463,7 +474,7 @@ timestamp, alert->h= ostname, alert->testname, alert->ip, mailreci= p, recip->cfid, (long)now, servicec= ode(alert->testname)); - if (alert->state =3D=3D A_R= ECOVERED) { + if ((alert->state =3D=3D A_= RECOVERED) || (alert->state =3D=3D A_DISABLED)) { fprintf(logfd, " %l= d\n", (long)(now - alert->eventstart)); } else { @@ -561,7 +572,17 @@ putenv(bbcolorlevel);
recovered =3D (char *)malloc(strlen= ("RECOVERED=3D") + 2); - sprintf(recovered, "RECOVERED=3D%d"= , ((alert->state =3D=3D A_RECOVERED) ? 1 : 0)); + switch (alert->state) { + case A_RECOVERED: + strcpy(recovered, "RECOVERE= D=3D1"); + break; + case A_DISABLED: + strcpy(recovered, "RECOVERE= D=3D2"); + break; + default: + strcpy(recovered, "RECOVERE= D=3D0"); + break; + } putenv(recovered);
downsecs =3D (char *)malloc(strlen(= "DOWNSECS=3D") + 20); @@ -572,7 +593,7 @@ sprintf(eventtstamp, "EVENTSTART=3D= %ld", (long)alert->eventstart); putenv(eventtstamp);
- if (alert->state =3D=3D A_RECOVERED= ) { + if ((alert->state =3D=3D A_RECOVERE= D) || (alert->state =3D=3D A_DISABLED)) { downsecsmsg =3D (char *)mal= loc(strlen("DOWNSECSMSG=3DEvent duration :") + 20); sprintf(downsecsmsg, "DOWNS= ECSMSG=3DEvent duration : %ld", (long)(getcurrenttime(NULL) - alert->events= tart)); } @@ -628,7 +649,7 @@ timestamp, alert->h= ostname, alert->testname, alert->ip, scriptre= cip, (long)now, servicecode(alert->= testname)); - if (alert->state =3D=3D A_R= ECOVERED) { + if ((alert->state =3D=3D A_= RECOVERED) || (alert->state =3D=3D A_DISABLED)) { fprintf(logfd, " %l= d\n", (long)(now - alert->eventstart)); } else {
To unsubscribe from the xymon list, send an e-mail to xymon-unsubscribe at xymon.com
This e-mail message and any attached files are confidential and are intende= d solely for the use of the addressee(s) named above. If you are not the in= tended recipient, any review, use, or distribution of this e-mail message a= nd any attached files is strictly prohibited.
This communication may contain material protected by Federal privacy regula= tions, attorney-client work product, or other privileges. If you have recei= ved this confidential communication in error, please notify the sender imme= diately by reply e-mail message and permanently delete the original message= . To reply to our email administrator directly, send an email to: postmas= ter at orlandohealth.com .
If this e-mail message concerns a contract matter, be advised that no emplo= yee or agent is authorized to conclude any binding agreement on behalf of O= rlando Health by e-mail without express written confirmation by an officer = of the corporation. Any views or opinions presented in this e-mail are sole= ly those of the author and do not necessarily represent those of Orlando He= alth.
To unsubscribe from the xymon list, send an e-mail to xymon-unsubscribe at xymon.com
To unsubscribe from the xymon list, send an e-mail to xymon-unsubscribe at xymon.com This e-mail message and any attached files are confidential and are intended solely for the use of the addressee(s) named above. If you are not the intended recipient, any review, use, or distribution of this e-mail message and any attached files is strictly prohibited. This communication may contain material protected by Federal privacy regulations, attorney-client work product, or other privileges. If you have received this confidential communication in error, please notify the sender immediately by reply e-mail message and permanently delete the original message. To reply to our email administrator directly, send an email to: postmaster at orlandohealth.com . If this e-mail message concerns a contract matter, be advised that no employee or agent is authorized to conclude any binding agreement on behalf of Orlando Health by e-mail without express written confirmation by an officer of the corporation. Any views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of Orlando Health.
I apologize for my confusion, but I don't understand what you mean by this. -----Original Message----- From: Henrik Størner [mailto:henrik at hswn.dk] Sent: Thursday, February 17, 2011 3:23 AM To: xymon at xymon.com Subject: Re: [xymon] RE: Alerts variables In <F09A4F6C0E7518488834791F4CD79B118AE82D54DA at EXDB03.orhs.org> "Nordquist, Daniel" <Daniel.Nordquist at orlandohealth.com> writes:
Can we apply this code to 4.2.3?
Already done. Regards, Henrik
-----Original Message----- From: Henrik St=C3=B8rner [mailto:henrik at hswn.dk] Sent: Monday, February 14, 2011 7:40 AM To: xymon at xymon.com Subject: Re: [xymon] RE: Alerts variables
In <B08F3F3D67451844A7A8A029FCC71E4C1941CC1661 at WIN01.ad.deltamanagement.se>= =3D?iso-8859-1?Q?Johan_Sj=3DF6berg?=3D <johan.sjoberg at deltamanagement.se> = writes:
Yes, exactly. It is a script from Xymonton that is invoked using SCRIPT. S= o=3D I would like to know if any variable is passed to the script containing t= h=3D e status "disabled"
OK, this turned out to be a slightly larger change than I had anticipated. After testing things a bit, it dawned on me that neither the mail-messages nor the script-based alerts would be able to tell the difference between a genuine recovery (going "green") and a recovery due to the status being disabled.
Which doesn't seem right.
The patch below should solve this. For mail/SMS alerts the subject and message text has been changed from "recovered" to "disabled". For scripts this can be seen from the value of the RECOVERED variable - it will be "1" for a genuine recovery (unchanged from before) and "2" for a recover- by-disable.
The BBCOLORLEVEL setting remains unchanged, i.e. it will NOT be blue. This is because BBCOLORLEVEL holds the value of the color that triggered the alert - not the current color of the status.
Note: When you apply this patch (against 4.3.0-RC1), please run "make clean" and then "make" to build the package. Without the "make clean", some of the library modules will probably not get updated - causing weird results.
Regards, Henrik
Index: lib/loadalerts.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- lib/loadalerts.c (revision 6631) +++ lib/loadalerts.c (working copy) @@ -958,7 +958,7 @@ return result; }
- if (alert->state =3D=3D A_RECOVERED) { + if ((alert->state =3D=3D A_RECOVERED) || (alert->state =3D=3D A_DIS= ABLED)) { /* * Dont do the check until we are checking individual recip= ients (rulecrit is set). * You dont need to have RECOVERED on the top-level rule, i= t's enough if a recipient Index: lib/loadalerts.h =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- lib/loadalerts.h (revision 6631) +++ lib/loadalerts.h (working copy) @@ -18,7 +18,7 @@ #if defined(LOCALCLIENT) || !defined(CLIENTONLY) #include <pcre.h>
-typedef enum { A_PAGING, A_NORECIP, A_ACKED, A_RECOVERED, A_NOTIFY, A_DEAD= } astate_t; +typedef enum { A_PAGING, A_NORECIP, A_ACKED, A_RECOVERED, A_DISABLED, A_NO= TIFY, A_DEAD } astate_t;
typedef struct activealerts_t { /* Identification of the alert */ Index: xymond/xymond_alert.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- xymond/xymond_alert.c (revision 6631) +++ xymond/xymond_alert.c (working copy) @@ -75,8 +75,8 @@ activealerts_t *ahead =3D NULL;
char *statename[] =3D { - /* A_PAGING, A_NORECIP, A_ACKED, A_RECOVERED, A_NOTIFY, A_DEAD */ - "paging", "norecip", "acked", "recovered", "notify", "dead" + /* A_PAGING, A_NORECIP, A_ACKED, A_RECOVERED, A_DISABLED, A_NOTIFY,= A_DEAD */ + "paging", "norecip", "acked", "recovered", "disabled", "notify", "d= ead" };
char *find_name(RbtHandle tree, char *name) @@ -662,7 +662,7 @@ * Dont update the color here - we want rec= overies to go out * only if the alert color triggered an ale= rt */ - awalk->state =3D A_RECOVERED; + awalk->state =3D (newcolor =3D=3D COL_BLUE)= ? A_DISABLED : A_RECOVERED; }
if (oldalertstatus !=3D newalertstatus) { @@ -865,6 +865,7 @@ break;
case A_RECOVERED: + case A_DISABLED: case A_NOTIFY: anytogo++; break; @@ -895,6 +896,7 @@ break;
case A_RECOVERED: + case A_DISABLED: case A_NOTIFY: send_alert(awalk, notiflogf= d); break; @@ -929,6 +931,7 @@ break;
case A_RECOVERED: + case A_DISABLED: case A_NOTIFY: awalk->state =3D A_DEAD; /* Fall through */ Index: xymond/do_alert.c =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D --- xymond/do_alert.c (revision 6631) +++ xymond/do_alert.c (working copy) @@ -225,6 +225,12 @@ alert->hostname, alert->testname, recip->cfid); break;
+ case A_DISABLED: + subjfmt =3D (include_configid ? "Xymon %s:%s disabled [cfid= :%d]" : "Xymon %s:%s disabled"); + snprintf(subj, sizeof(subj)-1, subjfmt, + alert->hostname, alert->testname, recip->cfid); + break; + case A_NORECIP: case A_DEAD: /* Cannot happen */ @@ -310,6 +316,11 @@ alert->hostname, alert->testname); break;
+ case A_DISABLED: + sprintf(info, "%s:%s DISABLED", + alert->hostname, alert->testname); + break; + case A_NOTIFY: sprintf(info, "%s:%s NOTICE", alert->hostname, alert->testname); @@ -365,7 +376,7 @@ int first =3D 1; int alertcount =3D 0; time_t now =3D getcurrenttime(NULL); - char *alerttxt[A_DEAD+1] =3D { "Paging", "Acked", "Recovered", "Not= ify", "Dead" }; + char *alerttxt[A_DEAD+1] =3D { "Paging", "Acked", "Recovered", "Dis= abled", "Notify", "Dead" };
dbgprintf("send_alert %s:%s state %d\n", alert->hostname, alert->te= stname, (int)alert->state); traceprintf("send_alert %s:%s state %s\n", @@ -380,7 +391,7 @@ continue; }
- if (recip->noalerts && ((alert->state =3D=3D A_PAGING) || (= alert->state =3D=3D A_RECOVERED))) { + if (recip->noalerts && ((alert->state =3D=3D A_PAGING) || (= alert->state =3D=3D A_RECOVERED) || (alert->state =3D=3D A_DISABLED))) { traceprintf("Recipient '%s' dropped (NOALERT)\n", r= ecip->recipient); continue; } @@ -408,7 +419,7 @@ } alertcount++; } - else if (alert->state =3D=3D A_RECOVERED) { + else if ((alert->state =3D=3D A_RECOVERED) || (alert->state= =3D=3D A_DISABLED)) { /* RECOVERED messages require that we've sent out a= n alert before */ repeat_t *rpt =3D NULL;
@@ -463,7 +474,7 @@ timestamp, alert->h= ostname, alert->testname, alert->ip, mailreci= p, recip->cfid, (long)now, servicec= ode(alert->testname)); - if (alert->state =3D=3D A_R= ECOVERED) { + if ((alert->state =3D=3D A_= RECOVERED) || (alert->state =3D=3D A_DISABLED)) { fprintf(logfd, " %l= d\n", (long)(now - alert->eventstart)); } else { @@ -561,7 +572,17 @@ putenv(bbcolorlevel);
recovered =3D (char *)malloc(strlen= ("RECOVERED=3D") + 2); - sprintf(recovered, "RECOVERED=3D%d"= , ((alert->state =3D=3D A_RECOVERED) ? 1 : 0)); + switch (alert->state) { + case A_RECOVERED: + strcpy(recovered, "RECOVERE= D=3D1"); + break; + case A_DISABLED: + strcpy(recovered, "RECOVERE= D=3D2"); + break; + default: + strcpy(recovered, "RECOVERE= D=3D0"); + break; + } putenv(recovered);
downsecs =3D (char *)malloc(strlen(= "DOWNSECS=3D") + 20); @@ -572,7 +593,7 @@ sprintf(eventtstamp, "EVENTSTART=3D= %ld", (long)alert->eventstart); putenv(eventtstamp);
- if (alert->state =3D=3D A_RECOVERED= ) { + if ((alert->state =3D=3D A_RECOVERE= D) || (alert->state =3D=3D A_DISABLED)) { downsecsmsg =3D (char *)mal= loc(strlen("DOWNSECSMSG=3DEvent duration :") + 20); sprintf(downsecsmsg, "DOWNS= ECSMSG=3DEvent duration : %ld", (long)(getcurrenttime(NULL) - alert->events= tart)); } @@ -628,7 +649,7 @@ timestamp, alert->h= ostname, alert->testname, alert->ip, scriptre= cip, (long)now, servicecode(alert->= testname)); - if (alert->state =3D=3D A_R= ECOVERED) { + if ((alert->state =3D=3D A_= RECOVERED) || (alert->state =3D=3D A_DISABLED)) { fprintf(logfd, " %l= d\n", (long)(now - alert->eventstart)); } else {
To unsubscribe from the xymon list, send an e-mail to xymon-unsubscribe at xymon.com
This e-mail message and any attached files are confidential and are intende= d solely for the use of the addressee(s) named above. If you are not the in= tended recipient, any review, use, or distribution of this e-mail message a= nd any attached files is strictly prohibited.
This communication may contain material protected by Federal privacy regula= tions, attorney-client work product, or other privileges. If you have recei= ved this confidential communication in error, please notify the sender imme= diately by reply e-mail message and permanently delete the original message= . To reply to our email administrator directly, send an email to: postmas= ter at orlandohealth.com .
If this e-mail message concerns a contract matter, be advised that no emplo= yee or agent is authorized to conclude any binding agreement on behalf of O= rlando Health by e-mail without express written confirmation by an officer = of the corporation. Any views or opinions presented in this e-mail are sole= ly those of the author and do not necessarily represent those of Orlando He= alth.
To unsubscribe from the xymon list, send an e-mail to xymon-unsubscribe at xymon.com
To unsubscribe from the xymon list, send an e-mail to xymon-unsubscribe at xymon.com This e-mail message and any attached files are confidential and are intended solely for the use of the addressee(s) named above. If you are not the intended recipient, any review, use, or distribution of this e-mail message and any attached files is strictly prohibited. This communication may contain material protected by Federal privacy regulations, attorney-client work product, or other privileges. If you have received this confidential communication in error, please notify the sender immediately by reply e-mail message and permanently delete the original message. To reply to our email administrator directly, send an email to: postmaster at orlandohealth.com . If this e-mail message concerns a contract matter, be advised that no employee or agent is authorized to conclude any binding agreement on behalf of Orlando Health by e-mail without express written confirmation by an officer of the corporation. Any views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of Orlando Health. To unsubscribe from the xymon list, send an e-mail to xymon-unsubscribe at xymon.com This e-mail message and any attached files are confidential and are intended solely for the use of the addressee(s) named above. If you are not the intended recipient, any review, use, or distribution of this e-mail message and any attached files is strictly prohibited. This communication may contain material protected by Federal privacy regulations, attorney-client work product, or other privileges. If you have received this confidential communication in error, please notify the sender immediately by reply e-mail message and permanently delete the original message. To reply to our email administrator directly, send an email to: postmaster at orlandohealth.com . If this e-mail message concerns a contract matter, be advised that no employee or agent is authorized to conclude any binding agreement on behalf of Orlando Health by e-mail without express written confirmation by an officer of the corporation. Any views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of Orlando Health.
Hi Daniel,
Den 21-02-2011 13:37, Nordquist, Daniel skrev:
I apologize for my confusion, but I don't understand what you mean by this.
In<F09A4F6C0E7518488834791F4CD79B118AE82D54DA at EXDB03.orhs.org> "Nordquist, Daniel"<Daniel.Nordquist at orlandohealth.com> writes:
Can we apply this code to 4.2.3? Already done.
sorry - my mistake. I meant "it is already in 4.3.0", but your question was for the older 4.2.3 release.
It won't fit into 4.2.3 without some changes. So you'll have to wait a few more days for a release of this.
Regards, Henrik
Henrik, I hope you're feeling better and recovering nicely from your surgery.
I was wondering if you have in the works a new release with this code for the recovery alert variable?
And, the code that patched the problem for the rbtree bug where the ack cookies are located by scanning the memory instead of the rbtree? Sounds like you discovered that the "delete node" code is buggy from that message thread.
Please let me know if there will be a new release with these code changes or if I should pursue upgrading to 4.3.2 and then applying the patches.
Thanks, Dan
-----Original Message----- From: xymon-bounces at xymon.com [mailto:xymon-bounces at xymon.com] On Behalf Of Henrik Størner Sent: Monday, February 21, 2011 9:22 AM To: xymon at xymon.com Subject: Re: [Xymon] [xymon] RE: Alerts variables
Hi Daniel,
Den 21-02-2011 13:37, Nordquist, Daniel skrev:
I apologize for my confusion, but I don't understand what you mean by this.
In<F09A4F6C0E7518488834791F4CD79B118AE82D54DA at EXDB03.orhs.org> "Nordquist, Daniel"<Daniel.Nordquist at orlandohealth.com> writes:
Can we apply this code to 4.2.3? Already done.
sorry - my mistake. I meant "it is already in 4.3.0", but your question was for the older 4.2.3 release.
It won't fit into 4.2.3 without some changes. So you'll have to wait a few more days for a release of this.
Regards, Henrik
Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon
This e-mail message and any attached files are confidential and are intended solely for the use of the addressee(s) named above. If you are not the intended recipient, any review, use, or distribution of this e-mail message and any attached files is strictly prohibited.
This communication may contain material protected by Federal privacy regulations, attorney-client work product, or other privileges. If you have received this confidential communication in error, please notify the sender immediately by reply e-mail message and permanently delete the original message. To reply to our email administrator directly, send an email to: postmaster at orlandohealth.com .
If this e-mail message concerns a contract matter, be advised that no employee or agent is authorized to conclude any binding agreement on behalf of Orlando Health by e-mail without express written confirmation by an officer of the corporation. Any views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of Orlando Health.
Sorry if I'm being a pest and/or if I'm just not seeing something obvious.
I do not see these two changes listed or documented anywhere in the 4.3.3 release (concerning the alert variable allowing a "blue" status, and the rbtree bug).
Please respond.
Thanks, Dan
-----Original Message----- From: xymon-bounces at xymon.com [mailto:xymon-bounces at xymon.com] On Behalf Of Nordquist, Daniel Sent: Monday, May 16, 2011 1:43 PM To: xymon at xymon.com Subject: Re: [Xymon] [xymon] RE: Alerts variables
Henrik, I hope you're feeling better and recovering nicely from your surgery.
I was wondering if you have in the works a new release with this code for the recovery alert variable?
And, the code that patched the problem for the rbtree bug where the ack cookies are located by scanning the memory instead of the rbtree? Sounds like you discovered that the "delete node" code is buggy from that message thread.
Please let me know if there will be a new release with these code changes or if I should pursue upgrading to 4.3.2 and then applying the patches.
Thanks, Dan
-----Original Message----- From: xymon-bounces at xymon.com [mailto:xymon-bounces at xymon.com] On Behalf Of Henrik Størner Sent: Monday, February 21, 2011 9:22 AM To: xymon at xymon.com Subject: Re: [Xymon] [xymon] RE: Alerts variables
Hi Daniel,
Den 21-02-2011 13:37, Nordquist, Daniel skrev:
I apologize for my confusion, but I don't understand what you mean by this.
In<F09A4F6C0E7518488834791F4CD79B118AE82D54DA at EXDB03.orhs.org> "Nordquist, Daniel"<Daniel.Nordquist at orlandohealth.com> writes:
Can we apply this code to 4.2.3? Already done.
sorry - my mistake. I meant "it is already in 4.3.0", but your question was for the older 4.2.3 release.
It won't fit into 4.2.3 without some changes. So you'll have to wait a few more days for a release of this.
Regards, Henrik
Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon
This e-mail message and any attached files are confidential and are intended solely for the use of the addressee(s) named above. If you are not the intended recipient, any review, use, or distribution of this e-mail message and any attached files is strictly prohibited.
This communication may contain material protected by Federal privacy regulations, attorney-client work product, or other privileges. If you have received this confidential communication in error, please notify the sender immediately by reply e-mail message and permanently delete the original message. To reply to our email administrator directly, send an email to: postmaster at orlandohealth.com .
If this e-mail message concerns a contract matter, be advised that no employee or agent is authorized to conclude any binding agreement on behalf of Orlando Health by e-mail without express written confirmation by an officer of the corporation. Any views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of Orlando Health.
Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon
This e-mail message and any attached files are confidential and are intended solely for the use of the addressee(s) named above. If you are not the intended recipient, any review, use, or distribution of this e-mail message and any attached files is strictly prohibited.
This communication may contain material protected by Federal privacy regulations, attorney-client work product, or other privileges. If you have received this confidential communication in error, please notify the sender immediately by reply e-mail message and permanently delete the original message. To reply to our email administrator directly, send an email to: postmaster at orlandohealth.com .
If this e-mail message concerns a contract matter, be advised that no employee or agent is authorized to conclude any binding agreement on behalf of Orlando Health by e-mail without express written confirmation by an officer of the corporation. Any views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of Orlando Health.
Hi.
This change is in the 4.3.3 release (and also in 4.3.2, I think). I am using it myself. The $RECOVERED variable can be either 1 or 2. I don't know about the "rbtree bug".
/Johan
-----Original Message----- From: xymon-bounces at xymon.com [mailto:xymon-bounces at xymon.com] On Behalf Of Nordquist, Daniel Sent: den 19 maj 2011 17:54 To: xymon at xymon.com Subject: Re: [Xymon] [xymon] RE: Alerts variables
Sorry if I'm being a pest and/or if I'm just not seeing something obvious.
I do not see these two changes listed or documented anywhere in the 4.3.3 release (concerning the alert variable allowing a "blue" status, and the rbtree bug).
Please respond.
Thanks, Dan
-----Original Message----- From: xymon-bounces at xymon.com [mailto:xymon-bounces at xymon.com] On Behalf Of Nordquist, Daniel Sent: Monday, May 16, 2011 1:43 PM To: xymon at xymon.com Subject: Re: [Xymon] [xymon] RE: Alerts variables
Henrik, I hope you're feeling better and recovering nicely from your surgery.
I was wondering if you have in the works a new release with this code for the recovery alert variable?
And, the code that patched the problem for the rbtree bug where the ack cookies are located by scanning the memory instead of the rbtree? Sounds like you discovered that the "delete node" code is buggy from that message thread.
Please let me know if there will be a new release with these code changes or if I should pursue upgrading to 4.3.2 and then applying the patches.
Thanks, Dan
-----Original Message----- From: xymon-bounces at xymon.com [mailto:xymon-bounces at xymon.com] On Behalf Of Henrik Størner Sent: Monday, February 21, 2011 9:22 AM To: xymon at xymon.com Subject: Re: [Xymon] [xymon] RE: Alerts variables
Hi Daniel,
Den 21-02-2011 13:37, Nordquist, Daniel skrev:
I apologize for my confusion, but I don't understand what you mean by this.
In<F09A4F6C0E7518488834791F4CD79B118AE82D54DA at EXDB03.orhs.org> "Nordquist, Daniel"<Daniel.Nordquist at orlandohealth.com> writes:
Can we apply this code to 4.2.3? Already done.
sorry - my mistake. I meant "it is already in 4.3.0", but your question was for the older 4.2.3 release.
It won't fit into 4.2.3 without some changes. So you'll have to wait a few more days for a release of this.
Regards, Henrik
Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon
This e-mail message and any attached files are confidential and are intended solely for the use of the addressee(s) named above. If you are not the intended recipient, any review, use, or distribution of this e-mail message and any attached files is strictly prohibited.
This communication may contain material protected by Federal privacy regulations, attorney-client work product, or other privileges. If you have received this confidential communication in error, please notify the sender immediately by reply e-mail message and permanently delete the original message. To reply to our email administrator directly, send an email to: postmaster at orlandohealth.com .
If this e-mail message concerns a contract matter, be advised that no employee or agent is authorized to conclude any binding agreement on behalf of Orlando Health by e-mail without express written confirmation by an officer of the corporation. Any views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of Orlando Health.
Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon
This e-mail message and any attached files are confidential and are intended solely for the use of the addressee(s) named above. If you are not the intended recipient, any review, use, or distribution of this e-mail message and any attached files is strictly prohibited.
This communication may contain material protected by Federal privacy regulations, attorney-client work product, or other privileges. If you have received this confidential communication in error, please notify the sender immediately by reply e-mail message and permanently delete the original message. To reply to our email administrator directly, send an email to: postmaster at orlandohealth.com .
If this e-mail message concerns a contract matter, be advised that no employee or agent is authorized to conclude any binding agreement on behalf of Orlando Health by e-mail without express written confirmation by an officer of the corporation. Any views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of Orlando Health.
Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon
Sorry if I'm being a pest and/or if I'm just not seeing something obvious.
I do not see these two changes listed or documented anywhere in the 4.3.3 release (concerning the alert variable allowing a "blue" status, and the rbtree bug).
The code for the blue status was added for the 4.3.0 release, and is present in all 4.3.x releases.
I won't update 4.2.x versions.
The ack cookie workaround hasn't been merged yet. I might add this as an interim solution for 4.3.4, but the real solution is probably going to involve replacing the rbtree code currently in Xymon with the libredblack library from the GNU project. That is a bit more drastic, so will need some more time to implement.
Regards, Henrik
Thanks!
-----Original Message----- From: xymon-bounces at xymon.com [mailto:xymon-bounces at xymon.com] On Behalf Of Henrik Størner Sent: Thursday, May 19, 2011 12:02 PM To: xymon at xymon.com Subject: Re: [Xymon] [xymon] RE: Alerts variables
Sorry if I'm being a pest and/or if I'm just not seeing something obvious.
I do not see these two changes listed or documented anywhere in the 4.3.3 release (concerning the alert variable allowing a "blue" status, and the rbtree bug).
The code for the blue status was added for the 4.3.0 release, and is present in all 4.3.x releases.
I won't update 4.2.x versions.
The ack cookie workaround hasn't been merged yet. I might add this as an interim solution for 4.3.4, but the real solution is probably going to involve replacing the rbtree code currently in Xymon with the libredblack library from the GNU project. That is a bit more drastic, so will need some more time to implement.
Regards, Henrik
Xymon mailing list Xymon at xymon.com http://lists.xymon.com/mailman/listinfo/xymon
This e-mail message and any attached files are confidential and are intended solely for the use of the addressee(s) named above. If you are not the intended recipient, any review, use, or distribution of this e-mail message and any attached files is strictly prohibited.
This communication may contain material protected by Federal privacy regulations, attorney-client work product, or other privileges. If you have received this confidential communication in error, please notify the sender immediately by reply e-mail message and permanently delete the original message. To reply to our email administrator directly, send an email to: postmaster at orlandohealth.com .
If this e-mail message concerns a contract matter, be advised that no employee or agent is authorized to conclude any binding agreement on behalf of Orlando Health by e-mail without express written confirmation by an officer of the corporation. Any views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of Orlando Health.
But I think he wants a distinction of a Recovered email, between, the problem is cleared, or the problem was blued out by an admin.
I'd like the distinction as well. Since we have a group of 8 of us, it'd be good to know w/out having to go to the web page. Especially when getting the email on the phone.
Paul Root Lead Internet Systems Eng Qwest Network Services
-----Original Message----- From: Henrik Størner [mailto:henrik at hswn.dk] Sent: Saturday, February 12, 2011 4:09 AM To: xymon at xymon.com Subject: Re: [xymon] RE: Alerts variables
In <F09A4F6C0E7518488834791F4CD79B118AE82D543B at EXDB03.orhs.org> "Nordquist, Daniel" <Daniel.Nordquist at orlandohealth.com> writes:
Anyone know if Xymon sends the color blue or not? Is there another variable that indicates "disabled"?
Eh ... "blue" means "disabled". The purpose of disabling a test is exactly to STOP sending alerts. So you do not get alerts for a blue status.
Regards, Henrik
To unsubscribe from the xymon list, send an e-mail to xymon-unsubscribe at xymon.com
This communication is the property of Qwest 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.
participants (4)
-
Daniel.Nordquist＠orlandohealth.com
-
henrik＠hswn.dk
-
johan.sjoberg＠deltamanagement.se
-
Paul.Root＠qwest.com