Re: monitoring servers
hi Henrique de Moraes Holschuh:
On Thu, 15 Dec 2005, Walhalla wrote:
ok - but i think we missunderstood - i need something to check
remote services not services on local machines. services not in that
Hmm, why not use Net SNMP then? It lets you plug basically *anything* you
need locally to inspect stuff, and publish it over SNMP. And *all* good
remote monitoring softwares can do SNMP.
sure - but you have to setup snmp / clients on all machines. and this we
don't want to do on customers-machines! ;)
way if a proc is running - it is enought if the corresponding port is
open/running -> server ist up & running.
That is not good enough a test in my experience, but if that's all you need,
even socat can be used to create a quick script to check for open ports.
And nagios has a TCP connect test you can use very easily, too.
sure - but cfg is tricky ... and i don't want some colleagues to work in
this cfg ;)
I know from experience that if you are monitoring a web server, you NEED to
send it a http request and check for the reply if you want to know whether
the service is really up and how responsive it is. For email, you need a
full roundrip check (send - receive), etc. A TCP connect won't tell you if
the application behind the open port is working (or overloaded and thus not
providing new services, etc).
yep - argus can do this (i you want, you ca have a look at
http://argus.tcp4me.com/docs.html :
websit check ...
The TCP/HTTP tests that the HTTP service is up and running. The TCP/URL
test will test the content of a web page.
Service TCP/URL {
url: http://www.example.com/cgi-bin/shoppingcart.pl
browser: Mozilla/5.0 (compatible; just testing)
expect: cart contains 1 item
}
portcheck ...
TCP and UDP Tests
Service TCP {
hostname: www.example.com
port: 80
send: HEAD / HTTP/1.0\r\n\r\n
expect: HTTP
readhow: toeof
}
Both TCP and UDP have many of the same parameters
* hostname the hostname or IP address to test. This needs to be
specified, but will propagate from an enclosing group
* port the port to test. This needs to be specified.
* send data to send once connected. This needs to be specified. If
nothing is specified, nothing will be sent to the remote server
* expect a regular expression that needs to match the data received from
the remote server. This needs to be specified. If nothing is specified,
success or failure is determined by whether or not we received any data
at all
* readhow This needs to be specified. How much data should we try to
read? toeof indicates read until the remote end closes the connection.
banner indicates we only want to read a banner. once indicates to use
whatever data is returned in the first read(). This parameter only
applies to TCP not UDP
Specifying an application (eg. TCP/SMTP) will fill in port, send,
expect, and readhow as appropriate for that protocol
.....
sure, there might be "better" things, that can do more. but for this we
need, it is perfekt! ;)
jens
Reply to: