I think I was wrong. I the two servers are behaving differently because they were configured differently. The server misbehaving was actually configured (analysis.cfg) to see a performance alert.
The server that was not reporting red properly was reporting yellow and the yellow masked the red status.
It seems a yellow status (that I configured in analysis.cfg) will override a red status (ie. service failure).
Can anyone confirm or explain this?
cheers,
Troy
----- Original Message ----- From: "Troy Adams" <user-81e3256385bc@xymon.invalid> To: "Phil Crooker" <user-e8e31cd73303@xymon.invalid> Cc: xymon at xymon.com Sent: Thursday, June 30, 2011 10:18:53 AM GMT -07:00 US/Canada Mountain Subject: Re: [Xymon] httpstatus inconsistency
looks like they will be overwriting each other
They don't overwrite; xymon supports this.
If the above changes don't fix the problem, try turning up the debugging (in tasks.cfg) and see if you can spot what is happening.
Thanks, I'm off to try it.
If you want to try the multi-URL yourself then here is a simple test framework (/var/www/cgi-bin/dbB.pl) that I employ to mess with HTTP status:
#!/usr/bin/perl -w
use CGI qw/:standard/;
print header('text/html',"200 Everything is great");
cheers,
Troy
----- Original Message ----- From: "Phil Crooker" <user-e8e31cd73303@xymon.invalid> To: "Troy Adams" <user-81e3256385bc@xymon.invalid> Cc: xymon at xymon.com Sent: Tuesday, June 28, 2011 5:35:52 PM GMT -07:00 US/Canada Mountain Subject: Re: [Xymon] httpstatus inconsistency
Hi Troy,
Yes I understand you are getting different responses from the different URLs. The problem is first that you have two http tests for the same host. You haven't put your exact config in your question, but in your example: 192.168.0.29 camilla # postgresql \ http://MyUrlA \ httpstatus=dbB;https://MyUrlB;200 \ httpstatus=dbC;https://MyUrlC;200 \ http://MyUrlD
UrlA and UrlD will both show up under the same test name "http" on the web page. To me it looks like they will be overwriting each other at the minimum. I'm fairly new at xymon, but I'd say to overcome this you need to have the second http test attached to another host so they are reported separately. Or you could use a third httpstatus test rather than just http.
The second problem I saw in your example was you don't have a trailing semicolon on your httpstatus lines, there is another field there that needs to be represented:
httpstatus[=COLUMN];URL;okstatusexpr;notokstatusexpr
I tried your example setup on our server and don't have the inconsistent error reporting you complain of, so I think there is some syntactical error in your hosts.cfg.
If the above changes don't fix the problem, try turning up the debugging (in tasks.cfg) and see if you can spot what is happening.
cheers, Phil
On 29/06/2011 at 2:43 AM, in message
<user-595f6438666d@xymon.invalid>, Troy Adams <user-81e3256385bc@xymon.invalid> wrote:
Thanks Phil,
I do indeed have multiple http tests for the same host that go to different URLs on the same host. I know it looks funny at first but the reason for this is by design. You see, the application running behind the apache webserver on this host is programmed to hand out a
different status on each URL that indicates the status of the
database
yet further behind the application.
For example, database dbB, is shown to be up and running if (and only if) the fetch of URL https://MyUrlB returns an HTTP Status of 200. That is to say, if the application get's a database exception then it is to throw a non-200 status.
This hosts.cfg entry does work well but it works one way on one monitoring server and the other way on the other monitoring server:
The strange thing, is that when dbC fails with a non 200.... on monitor3 dbC and http tests show red on monitor5 dbC shows red and http shows green
cheers,
Troy
----- Original Message ----- From: "Phil Crooker" <user-e8e31cd73303@xymon.invalid> To: "Troy Adams" <user-81e3256385bc@xymon.invalid>, xymon at xymon.com Sent: Tuesday, June 28, 2011 1:16:44 AM GMT -07:00 US/Canada Mountain
Subject: Re: [Xymon] httpstatus inconsistency
A rather odd thing I see in your example - you have two http tests
for
the same host. If you want to have both I would think you'd need to rename one of them by doing a separate portocols.cfg entry or putting
it
under a differnet hostname.
It seems to me that you probably have some syntax error in your hosts.cfg file to cause the different results.
cheers, Phil
On 28/06/2011 at 4:03 AM, in message
<user-c1c3f473e924@xymon.invalid>,
Troy Adams <user-81e3256385bc@xymon.invalid> wrote:
I have two servers (monitor5 and monitor3) running Xymon 4.3.2 that
both have
the same hosts.cfg entries for a particular host. The entry uses the
httpstatus test and goes like this:
192.168.0.29 camilla # postgresql \ http://MyUrlA \ httpstatus=dbB;https://MyUrlB;200 \ httpstatus=dbC;https://MyUrlC;200 \ http://MyUrlD
The strange thing, is that when dbC fails with a non 200.... on monitor3 dbC and http tests show red on monitor5 dbC shows red and http shows green
Why do the two monitoring servers behave differently? Any idea where to look?
thanks,
Troy
--
This message from ORIX Australia might contain confidential and/or privileged information. If you are not the intended recipient, any
use,
disclosure or copying of this message (or of any attachments to it)
is
not authorised.
If you have received this message in error, please notify the sender
immediately and delete the message and any attachments from your system. Please inform the sender if you do not wish to receive future
communications by email.
ORIX handles personal information according to a Privacy Policy that
is
consistent with the National Privacy Principles. Please let us know
if
you would like a copy. It is also available at http://www.orix.com.au
.
--
This communication is intended for the use of the recipient to
whom it
is addressed, and may contain confidential, personal, and or
privileged
information. Please contact us immediately if you are not the
intended
recipient of this communication, and do not copy, distribute, or
take
action relying on it. Any communications received in error, or subsequent reply, should be deleted or destroyed. ---