MONITORS OVERVIEW
The Cloud Networking system supports a very large subset of monitors from something as simple as a ping to something more complex as a DNS record lookup or even an HTTP Post that looks for specific content on the return. Configuring the correct monitor is essential to properly detecting outages for devices. Below is a quick overview of the functionality.
DEFAULT MONITORS
There are four default monitors that are pre-configured for quick use. To utilize one of them, simply choose the desired Type from the drop-down menu and create a name that you can reference later. After creating a default monitor, you can always edit it and adjust the parameters to suit your needs since a default monitor is essentially an advanced monitor with settings already configured.
HTTP – Use HTTP to monitor a web server over port 80. This monitor looks for a good HTTP response code in return. The default response code is 100, but that can be changed.
HTTPS – Use HTTPS to monitor a web server over port 443. This monitor also looks for a good HTTP response code in return. The default response code is 100, but that can be changed.
PING – Sends a standard ICMP echo request to the destination and expects an ICMP echo response.
TCP – Attempts to establish a typical 3-way handshake with the monitor destination and then closes the connection.
ADVANCED MONITORS
There are numerous advanced monitors that you can use to create custom monitoring functionality to granularly detect UP/DOWN status for your devices. HTTP, HTTPS, PING and TCP are reviewed above in the Default Monitors help.
DNS – This monitor sends a DNS query to the server over UDP port 53 that resolves to an IP address (e.g. an A or AAAA record). You must specify the query to make (e.g. www.example.com) as well as one or more IP addresses that are acceptable responses. A maximum of 5 IP addresses can be added to the list and at least one must match.
DNS-TCP – This monitor is identical to the DNS monitor, except it is sent over TCP port 53.
FTP – To monitor FTP, the monitor opens two connections to the FTP server. It first connects to the control port, which is used to transfer commands between a client and an FTP server. After it receives the expected response, it connects to the data port, which is used to transfer files between a client and an FTP server. Only when the FTP server responds as expected on both connections is it marked UP. This monitor requires a User Name and Password.
HTTP-CONTENT – This monitor establishes a 3-way handshake with the destination. When the connection is established, it uses the send parameter to send the HTTP data to the service and expects the HTTP response that the receive parameter specifies (HTTP body part without including HTTP headers). Empty response data matches any response. Expected data may be anywhere in the first 24K bytes of the HTTP body of the response.
HTTP-RESPONSE – The HTTP Response monitor analyzes and probes the responses from the destination IP only when those services receive client requests. This monitor can ONLY be configured to work with HTTP and HTTPS services. It determines that the service to which it is bound is UP by checking its responses to the requests that are sent to it. When no client requests are sent to the service, the response monitor probes the service by using the configured URL.
LDAP – This monitor checks an LDAP service by authenticating and sending a search query to it. If the search is successful, the service is marked UP. If the LDAP server does not locate the entry, it is marked DOWN. You configure the LDAP monitor to define the search that it should perform when sending a query. You can use the Base DN parameter to specify a location in the directory hierarchy where the LDAP server should start the test query. You can use the Attribute parameter to specify an attribute of the target entity.
MYSQL – This monitor checks the MySQL service by sending a search query to it. If the search is successful, the service is marked UP. If it does not receive a response or if the search fails, it is marked down.
NNTP – This monitor checks the NNTP service by connecting to the service and checking for the existence of the newsgroup that you specify. If the newsgroup exists, the search is successful and the service is marked UP. If the NNTP service does not respond or the search fails, the service is marked DOWN.
POP3 – This monitor checks POP3 by opening a connection with a POP3 server. If the POP3 server responds with the correct response codes within the configured time period, it marks the service UP. If the POP3 service does not respond, or responds incorrectly, it marks the service DOWN.
RADIUS – The RADIUS monitor periodically checks the state of the RADIUS service by sending an authentication request. The RADIUS server authenticates the RADIUS monitor and sends a response. By default, the monitor expects to receive a response code of 2, the default Access-Accept response. As long as the monitor receives the appropriate response, it marks the service UP. The Radius Key is also often known as the shared secret.
RTSP – This monitor checks the RTSP service by opening a connection with destination. The type of connection that it opens, and the response that it expects, differs depending upon the network configuration. If the RTSP service responds as expected within the configured time period, it marks the service UP. If the service does not respond, or responds incorrectly, it marks the service DOWN. The RTSP Request is a string that is sent to the server (for example, OPTIONS *). The length of the request must not exceed 163 characters.
SIP-UDP – SIP is the most commonly used protocol for VOIP. Several parameters are required to use this monitor.
Max Forwards: Possible values: 0-255. Default: 1
SIP Method: Possible values: OPTIONS, INVITE, REGISTER. Default: OPTIONS
SIP URI: This is the SIP method string sent to the server. For example “OPTIONS sip:sip.test.”
SIP REG URI: This is the SIP user to be registered.
SNMP – This monitor checks the SNMP agent by sending a query for the enterprise identification ID (OID) that you configure for monitoring. If the query is successful, the service is marked UP. If the SNMP service finds the OID that you specified, the query succeeds and the SNMP monitor marks the service UP. If it does not find the OID, the query fails and the SNMP monitor marks service DOWN.
HINT: You can use an SNMP monitor to detect server load, for example, by sending an OID for CPU, Memory, Connections (etc.) and specifying the acceptable response threshold (maximum value) that the monitor can accept before marking the service DOWN.
SMTP – This monitor checks the SMTP service by opening a connection with it and conducting a series of handshakes to ensure that the server is operating correctly. If the SMTP service completes the handshakes properly, the monitor marks the service UP. If the SMTP service does not respond, or responds incorrectly, it marks the service DOWN.
TCP-CONTENT – This monitor establishes a 3-way handshake with the destination. When the connection is established, it uses the send parameter to send specific data to the service and expects a specific response through the receive parameter.
UDP-CONTENT – When the receive string is specified: If the response matches, the service is marked UP. When the receive string is not specified: The service is marked UP whether or not a response is received. The service is marked DOWN if an “ICMP port unreachable” message is received. For LRTM monitors, when no response is received, the response time is the response time-out for the monitor. When the UDP monitors detect an ICMP port unreachable error, the service is marked DOWN immediately.
STANDARD MONITOR PARAMETERS
Interval – The frequency in minutes of the monitoring test probe.
Response Time-out – The number of seconds the system should wait before considering ‘no response’ as a failure. This must be lower than the interval.
Down Time – This is the amount of time the system will wait to start monitoring again after the state has been changed to DOWN. Consider it a monitoring rest period.
Retries – Number of consecutive failures before the monitor marks the service as down. For example, if you ping a device every minute and retries was set to 3, it would take 3 minutes to mark it as down.
Success Retries – This is the number of consecutive successful probes required to mark server as up.
Failure Retries – Number of consecutive failed probes required to mark server as down.
Enabled – Status of monitor. This enables/disables the monitor from running tests.
Reverse – When this is checked, the result will be treated in reverse. For example, if you wanted to treat a ping reply/ICMP echo reply as DOWN, you could select reverse and ensure that your server only responds to pings when it should not receive traffic or be considered DOWN.
Secure – State of secure monitoring for TCP-based monitors only. An SSL handshake is performed on the established TCP connection when this is checked.
LRTM – When checked, checks, compares and remembers the response time for devices being checked. If you wish to enable this, each server must have a monitor bound to it with “LRTM” enabled, and then your load balancing method must be “LRTM” (if applicable).
Destination IP – (optional) you can specify an IP address to send this monitor to if you do not want it to use the IP of the device that is being monitored.
Destination Port – (optional) you can specify a different port than would be normal for this monitor type. For example, HTTP defaults to using port 80, but you may wish to change it to 8080.
Action – The action is only an option for the HTTP-RESPONSE monitor and allows you to specify how you wish to respond to the result.
Custom Header – This is the custom header string sent with the monitoring probe. For example, if you specifically need to attach “host.domain.com” to the header in order for your web server to respond with content, this is where you specify that.