[Xymon] [xymon] RE: Alerts variables
Nordquist, Daniel
Daniel.Nordquist at orlandohealth.com
Mon Feb 21 13:37:32 CET 2011
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.
More information about the Xymon
mailing list