 | |||||||||||||
| Documentation - ServicesServices 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
If you are just starting out with argus, it is recommended that you
stick to the short form when possible and let argus fill in the
default values. In most cases, you will only say:
Service Ping Service TCP/SMTP Service TCP/IMAP in your config file, and argus will default the rest. 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
}
SNMPv3 Tests[5]
Service UDP/SNMPv3 {
hostname: cisco-1.example.com
oid: .1.3.6.1.4.1.9.9.13.1.3.1.3.1
snmpuser: joe
snmppass: secret
snmpauth: MD5
snmpprivpass: supersecret
snmppriv: DES
contextname: public
contextengine: 80000000123456
authengine: 80000000123456
}
SNMP rate calculations [4]Certain SNMP values are not useful themselves, but may be useful to watch after performing some manipulation. InOctets by itself is not useful, but using it to calculate a rate (or bandwidth use) in Bytes (or Bits) per second and comparing that value to a max or min is useful.
Service UDP/SNMP {
label: Out
hostname: cisco-1.example.com
# OutOctets
oid: .1.3.6.1.2.1.2.2.1.16.2
calc: ave-rate-bits
maxvalue: 20000000 # 20M bits/sec
minvalue: 1000000 # 1M bits/sec
}
This will convert the OutOctets value into a rate (Bytes per second), calculate the moving average, and convert it to Bits per second. If the resulting value falls outside the expected range of 1-20 Mbps, the test will fail.
The calc parameter was known as snmpcalc prior
to version 3.2
TCP/URL Content TestThe 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 TestThe 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
}
RPC tests
RPC testing is available only in versions 3.4 and later
Both TCP and UDP RPC services can be tested. The RPC tests will query the RPC portmapper to learn the service's current port. Service UDP/RPC hostname: ns1.example.com prognum: 100003 version: 2 }
as a shortcut, an alternative syntax is supported:
Group "server" {
hostname: server.example.com
# Service UDP/RPC/program/version
Service UDP/RPC/100003
Service UDP/RPC/100003/2
Service TCP/RPC/mountd
Service TCP/RPC/mountd/2
}
[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. [4] - SNMP rate calculations are available only in versions 3.1.1 and later. [5] - only available in versions 3.3 and later. [6] - only available in versions 3.4 and later. [7] - only available in versions 3.5 and later. | ||||||||||||
| |||||||||||||