HTTP test accessible local only 🔗 link

Hi there,

Figured I could use a little bit of collective wisdom here:

I have an HTTP service that is only accessible from the local machine (either connected to by a local app or a web browser that is launched from the server). I’d like to test that it is available. I don’t need any more specialized functionality than I would have from the HTTP test (maybe I’d set up an HTTP POST to actually log in).

Is there a way to somehow cause the client to do this, without writing an external script, or some other way to do what I’m talking about that I might not have considered?

Thanks!

--
____ *Note: UMDNJ is now Rutgers-Biomedical and Health Sciences*
|| \\UTGERS      |---------------------*O*---------------------
||_// Biomedical | Ryan Novosielski - Senior Technologist
|| \\ and Health | user-46c89e614701@xymon.invalid - 973/972.0922 (2x0922)
||  \\  Sciences | OIRT/High Perf & Res Comp - MSB C630, Newark
     `'

On Fri, January 29, 2016 10:34 am, Novosielski, Ryan wrote:

the server). I’d like to test that it is available. I don’t need any
more specialized functionality than I would have from the HTTP test (maybe
I’d set up an HTTP POST to actually log in).

Is there a way to somehow cause the client to do this, without writing an
external script, or some other way to do what I’m talking about that I
might not have considered?

The client itself is purposefully dumb, so there's not too much one could
do without writing a script that actually performs an HTTP interaction.

However, if the port is static you could use the PORT criteria in
analysis.cfg(5) to ensure that something is up and "listen"ing on the
system, which might be better than nothing. On a normal install, that
could be done without any local config.

To really exercise it, especially as a POST service, I'd suggest a
wget/curl script as a client extension that simply reports a status
message back. Sometimes simplest is easiest.


HTH,
-jc

I was afraid of that, but I figured it was worth a shot as people get up to some pretty crafty stuff in here. :) I’m actually not sure if the port is listening or not when this particular service gets into the bad state (it /is/ a static port), but that’s a thing to consider/somewhat easier than bothering with a script. Thanks again!

--
____ *Note: UMDNJ is now Rutgers-Biomedical and Health Sciences*
|| \\UTGERS      |---------------------*O*---------------------
||_// Biomedical | Ryan Novosielski - Senior Technologist
|| \\ and Health | user-46c89e614701@xymon.invalid - 973/972.0922 (2x0922)
||  \\  Sciences | OIRT/High Perf & Res Comp - MSB C630, Newark
     `'

Am Freitag, 29. Januar 2016, 13:34:47 schrieb Novosielski, Ryan:

Hi,

another way would be to use the real Xymonnet HTTP Check like you would use it on a monitoring satelite (Xymonnet Server). This might be a bit overkill, but I would expect it to give back better results than a self writen script. At least selfwriten within the time you need to configure. 
The monitoring of the port state as mentioned by J.C. might be easier and more straight forward way. And I would prefer it, if it fit's the needs.


The xymonnet is part of the server package. On the "client" running the server package you'll need to deactivate all sections but 
| # "xymonnet" runs the xymonnet tool to perform the network based tests | #     - i.e. http, smtp, ssh, dns and
| # all of the various network protocols we need to test.
| [xymonnet]
|         ENVFILE /usr/lib/xymon/server/etc/xymonserver.cfg
| #        NEEDS xymond
| #        CMD xymonnet --report --ping --checkresponse
|            CMD xymonnet --noping --checkresponse=red
|         LOGFILE $XYMONSERVERLOGS/xymonnet.log
|         INTERVAL 5m

And remove/comment out the NEEDS line, since this works only if Xymonnet and Xymondisplay are on the same host.

See man xymonnet(1) for usefull options. I think --noping would be what you'll want. The --checkresponse has only an effect if you are checking also Ports configured in protocols.cfg.  The --report is for the xymonnet-Column, this selfmonitoring might work, since it will report it xymonnet-Column for the "client", but choose yourself if you need this.

I'm running this with =red since it was a common wish from our server admins to alert if the Ports don't return the expected helo.

You'll also need to disable
| #directory /usr/lib/xymon/server/etc/tasks.d
| #include /var/run/xymon/xymonlaunch-include.cfg
 too, since some additional stuff might come in this way.

After this is done you can set XYMONSERVERIP in the xymonservers.cfg on the client to the IP of the real server.

Now you'll be able to configure your HTTP check in the hosts.cfg on the "client" as you are used to do on the "server". But be aware you should *only* configure the "client" *itself* in *it's* hosts.cfg.

For real Xymonnet Servers there is a "NET:<XymonNetIdentifier>" tag available, but this would be real overkill in this case.


Might be I've forgotten something. But this should be it. ;-)

Kind regards,
	Lars

-- 
man-da.de GmbH, AS8365                          Phone: +XX XXXX XX-XXXXX
Mornewegstraße 30                               Fax: +XX XXXX XX-XXXXX
D-64293 Darmstadt                               e-mail: user-0f90394071da@xymon.invalid
Geschäftsführer Marcus Stögbauer                AG Darmstadt, HRB 94 84