The probes in this section monitor various services integral to a functioning network. When applying them, ensure that their timed thresholds do not exceed the amount of time allotted to the timeout period. Otherwise, an UNKNOWN status is 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. 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 returns 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 returns 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 overrides 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 also checks the packet loss and compares 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 travel 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. 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. A port number must be specified; specifying another port number overrides 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 looks 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 returns a CRITICAL state.
The Network Services::Remote Ping probe determines if the monitored system can ping a specified IP address. It also monitors the packet loss and compares 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 travel 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 the similar, optional field in the standard Ping probe, this field is required. The monitored system directs the ping to a third address, rather than to the RHN Server. Since the Remote Ping probe tests connectivity from the monitored system, 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 allows you to test simple program availability. You must specify the program name or number, the protocol over which the conversation occurs, and the usual timeout period.
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 that it can connect to the HTTPS port on the specified host and retrieve the specified URL. If no URL is specified, the probe fetches the root document. The probe looks for a HTTP/1. message from the system unless you alter that value. Specifying another port number overrides 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 returns 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 displays the protocol and server version information. If the probe receives an invalid response, it displays the message returned from the server and generates 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.