Documentation - Services

Services specify actual things to monitor. The very purpose of this software. So, you'll probably need to know about them

In the config file, Services are specified as:

	Service NAME {
		data...
	}
Often, there will be no need to specify any data, and you may shorten the specification to just
	Service NAME

NAME specifies the type of test. There are 4 main types of tests:

Both TCP and UDP have a number of application tests built-in. Specifying an application does the same thing as setting the various bits of data to values appropriate for the protocol. But you could just as easily specify them directly.

The currently built-in application tests are:

Common Data that applies to all Services

	Service NAME {
		frequency:	60
		retries:	5
		timeout:	10
	}

These do not need to be specified, they will happily default, or propagate from an enclosing group

Note, specifying that things happen every 60 seconds (for example) does not mean that they will happen at the top of every minute (:00 seconds). Argus is smart and will load balance the tests to prevent the 59 seconds of quiet followed by an intense flurry of network congestion common in some other network monitoring applications. In argus-speak, things have a frequency and a phase, called phi. You cannot set this, but it is visible in the debugging web page.

Data for Prog Tests

	Service Prog {
		# make sure no one deleted root from the passwd file
		command:	cat /etc/passwd
		expect:		^root:
	}

These need to be specified. They will not default, or propagate from anywhere

Data for Ping Tests

	Service Ping {
		hostname:	host1.example.com
	}

This needs to be specified, but will propagate from an enclosing group

hostname the hostname or IP address to ping

Data for 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

Specifying an application (eg. TCP/SMTP) will fill in port, send, expect, and readhow as appropriate for that protocol

See below for details on the special TCP/URL, UDP/Domain, and UDP/SNMP tests

SNMP Tests

	Service UDP/SNMP {
		hostname:	cisco-1.example.com
		community:	qwerty
		oid:		.1.3.6.1.4.1.9.9.13.1.3.1.3.1
		maxvalue:	27
	}

TCP/URL Content Test

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
	}

DNS Authoritativeness Test

The UDP/DNS (and UDP/DNSQ) test that a DNS server is up and running. The UDP/Domain test will test that a server is answering authoritatively for a zone.

	Service UDP/Domain {
		hostname:	ns1.example.com
		zone:		example.com
	}

as a shortcut, an alternative syntax is supported:

	Group "nameserver" {
		hostname:	ns1.example.com
		Service UDP/Domain/example.com
		Service UDP/Domain/example.net
		Service UDP/Domain/example.org
	}

[1] - UDP/DNS sends a 'status-query', UDP/DNSQ sends an 'IN ANY' query. some DNS servers (notably djbdns) do not handle 'status' queries. UDP/DNSQ is available only in versions 3.1 and later.

[2] - UDP/NFS tests NFS version 2. UDP/NFSv3 is NFS version 3. UDP/NFSv3 is available only in versions 3.1 and later.

[3] - This test uses the server-status query, which is not supported by all radius servers.