The probes in this section monitor various services integral to a functioning network. When applying them, ensure their timed thresholds do not exceed the amount of time allotted to the timeout period. Otherwise, an UNKNOWN status will be returned in all instances of extended latency, thereby nullifying the thresholds.
The Network Services::DNS Lookup probe uses the dig command to see if it can resolve the system or domain name specified in the Host or Address to look up field. It collects the following metric:
Query Time — The time in milliseconds required to execute the dig request.
This is useful in monitoring the status of your DNS servers. If you want to monitor one of your DNS servers, supply a well-known host/domain name, such as a large search engine or corporate Web site.
The Network Services::FTP probe uses network sockets to test FTP port availability. It collects the following metric:
Remote Service Latency — The time it takes in seconds for the FTP server to answer a connection request.
This probe supports authentication. Provide a username and password in the appropriate fields to use this feature.The optional Expect value is the string to be matched against after a successful connection is made to the FTP server. If the expected string is not found, the probe will return a CRITICAL state.
The Network Services::IMAP Mail probe determines if it can connect to the IMAP 4 service on the system. Specifying an optional port will override the default port 143. It collects the following metric:
Remote Service Latency — The time it takes in seconds for the IMAP server to answer a connection request.
The required Expect value is the string to be matched against after a successful connection is made to the IMAP server. If the expected string is not found, the probe will return a CRITICAL state.
The Network Services::Mail Transfer (SMTP) probe determines if it can connect to the SMTP port on the system. Specifying an optional port number will override the default port 25. It collects the following metric:
Remote Service Latency — The time it takes in seconds for the SMTP server to answer a connection request.
The Network Services::Ping probe determines if the RHN Server can ping the monitored system or a specified IP address. It will also check the packet loss and compare the round trip average against the Warning and Critical threshold levels. The required Packets to send value allows you to control how many ICMP ECHO packets are sent to the system. This probe collects the following metrics:
Round-Trip Average — The time it takes in milliseconds for the ICMP ECHO packet to go to and from the monitored system.
Packet Loss — The percent of data lost in transit.
Although optional, the IP Address field can be instrumental in collecting metrics for systems that have multiple IP addresses. For instance, if the system is configured with multiple virtual IP addresses or uses Network Address Translation (NAT) to support internal and external IP addresses, this option may be used to check a secondary IP address, rather than the primary address associated with the hostname.
Note that this probe conducts the ping from an RHN Server and not the monitored system. So populating the IP Address field does not test connectivity between the system and the specified IP address but between the RHN Server and the IP address. Therefore, entering the same IP address for Ping probes on different systems accomplishes precisely the same task. To conduct a ping from a monitored system to an individual IP address, use the Remote Ping probe instead. Refer to Section C.8.7 Network Services::Remote Ping.
The Network Services::POP Mail probe determines if it can connect to the POP3 port on the system. Specifying another port number (which is required) will override the default port 110. This probe collects the following metric:
Remote Service Latency — The time it takes in seconds for the POP server to answer a connection request.
The required Expect value is the string to be matched against after a successful connection is made to the POP server. The probe will look for the string in the first line of the response from the system. The default is +OK. If the expected string is not found, the probe will return a CRITICAL state.
The Network Services::Remote Ping probe determines if the monitored system can ping a specified IP address. It will also monitor the packet loss and compare the round trip average against the Warning and Critical threshold levels. The required Packets to send value allows you to control how many ICMP ECHO packets are sent to the address. This probe collects the following metrics:
Round-Trip Average — The time it takes in milliseconds for the ICMP ECHO packet to go to and from the IP address.
Packet Loss — The percent of data lost in transit.
The IP Address field identifies the precise address to be pinged. Unlike a similar field in the standard Ping probe that is optional, this field is required because the monitored system will be conducting the ping, rather than the RHN Server. Leaving this field blank within the standard Ping probe tells RHN to ping the primary address of the monitored system. Since the Remote Ping probe tests connectivity from the monitored system itself, another IP address must be specified. To conduct pings from the RHN Server to a system or IP address, use the standard Ping probe instead. Refer to Section C.8.5 Network Services::Ping.
Requirements — The Red Hat Network Monitoring Daemon (rhnmd) must be running on the monitored system to execute this probe.
The Network Services::RPCService probe tests the availability of remote procedure call (RPC) programs on a given IP address. It collects the following metric:
Remote Service Latency — The time it takes in seconds for the RPC server to answer a connection request.
RPC server programs (which provide function calls via that RPC network) register themselves in the RPC network by declaring a program ID and a program name. NFS is an example of a service that works via the RPC mechanism.
Client programs that wish to use the resources of RPC server programs do so by asking the machine on which the server program resides to provide access to RPC functions within the RPC program number or program name. These conversations can occur over either TCP or UDP (but are almost always UDP).
This probe lets you test simple program availability. You will need to specify the program name or program number and the protocol over which the conversation will occur (plus the usual timeout).
The Network Services::Secure Web Server (HTTPS) probe determines the availability of the secure Web server and collects the following metric:
Remote Service Latency — The time it takes in seconds for the HTTPS server to answer a connection request.
This probe confirms it can connect to the HTTPS port on the specified host and retrieve the specified URL. If no URL is specified, the probe will fetch the root document. The probe looks for a HTTP/1. message from the system, unless you alter that value. Specifying another port number will override the default port of 443.
This probe supports authentication. Provide a username and password in the appropriate fields to use this feature. Unlike most other probes, this probe will return a CRITICAL status if it cannot contact the system within the timeout period.
The Network Services::SSH probe determines the availability of SSH on the specified port and collects the following metric:
Remote Service Latency — The time it takes in seconds for the SSH server to answer a connection request.
Upon successfully contacting the SSH server and receiving a valid response, the probe will display the protocol and server version information. If the probe receives an invalid response, it will display the message returned from the server and generate a WARNING state.
The Network Services::Web Server (HTTP) probe determines the availability of the Web server and collects the following metric:
Remote Service Latency — The time it takes in seconds for the HTTP server to answer a connection request.
This probe confirms it can connect to the HTTP port on the specified host and retrieve the specified URL. If no URL is specified, the probe will fetch the root document. The probe looks for a HTTP/1. message from the system, unless you alter that value. Specifying another port number will override the default port of 80. Unlike most other probes, this probe will return a CRITICAL status if it cannot contact the system within the timeout period.
This probe supports authentication. Provide a username and password in the appropriate fields to use this feature. Also, the optional Virtual Host field can be used to monitor a separate documentation set located on the same physical machine presented as a standalone server. If your Web server is not configured to use virtual hosts (which is typically the case), you should leave this field blank. If you do have virtual hosts configured, enter the domain name of the first host here. Add as many probes as necessary to monitor all virtual hosts on the machine.