[Xymon] httpstatus inconsistency

[Phil Crooker]

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
<2010869917.4926371309279414670.JavaMail.root at amundsen.cs.athabascau.ca>,
Troy
Adams <troy at athabascau.ca> 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" <Phil.Crooker at orix.com.au> 
> To: "Troy Adams" <troy at athabascau.ca>, 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 
>
<1205542418.4630071309197825488.JavaMail.root at amundsen.cs.athabascau.ca>,

> Troy 
> Adams <troy at athabascau.ca> 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.
> ---