The port probe is very similar to the ping probe described above. The main difference is that it does not check the IP stack availability but rather a specific TCP port.
The difference here is that using this method a specific service on the remote machine is monitored, for example a mail (SMTP) server. The port probe tries to connect to the service port (25 in our example). If that fails, the service is definitely not running. In this case, an event is generated. A single event is a definite indication of problems, as such there is no need for repetitive failures before initiating action on this (although this can be configured in the rule engine).
Being able to connect to the remote machine and service, TCP port most probably means that the remote service is running. However, more certainty can be gained by actually initiating some communication with the service. The exact application protocol needs to be known to try this test. Thus, this step is optional. If turned on, a single command can be send to the remote service and a single response is expected back and can be compared to a pre-defined response. This does not take care of all possible application protocols, but provides an additional layer of confidence for important services like SMTP. It is up to the user to know the command sequences that a given service can understand and reply with.
As a rule of thumb, the port probe provides superior protection against service failure even without checking the message exchange. So if in doubt, use it without this advanced feature.
Please note that the port probe can probe TCP based services only. Most application services are TCP based, but there are some – mostly system – services out there, that are not. One of the most notable exceptions is DNS, which is operated primarily over UDP. In UDP, there is no notion of a session and as such, it is not possible to probe the session setup, which essentially is what the port probe does. As such, a port probe can unfortunately not be used to check the status of those services. However, the majority of services like application server, databases, mail, web and a large number of others can be used with the port probe.
Port Probe Properties
This is the interval of the port probes. After each probe, the MonitorWare Agent 3.0 port probe process goes "to sleep". This period is specified in milliseconds.
The amount of time (in milliseconds the remote system is expected to answer in. If no response is received within this period, the ping fails and an event is generated. The default value of 1000 milliseconds is a proper value for most well connected networks. If the ping probe runs against a heavily loaded system and/or slow network link, the amount must be adjusted accordingly.
Either the IP address or resolvable host name of the system the ping probe is to be run against. You can either use an IPv4, an IPv6 Address or a Hostname that resolves to an IPv4 or IPv6 Address. This system has been called "remote host" in the description above. Please note that specifying a host name can cause the ping probe to fail if DNS name resolution fails (for example due to a failing DNS server). To avoid this, specify an IP address. Please note that you typically can use 127.0.0.1 (the so-called loop back address) to check a service that is running on a local machine. This ability might be limited by service configuration, because the service must listen to that IP address.
Please provide the IP address or the hostname according to your environment. We have left it empty by intention.
This port is to be probed. Please see your server's reference for the actual value to use. For example, mail servers typically listen to port 25 and web servers to 80.
Generate an event if Port Probe was successful
When checked, an event is generated every time. If unchecked, it is generated only when the port probe fails. The most common option is to leave it unchecked to catch events upon a failed port probe.
Send Message and wait for expected Message
If left unchecked, the port probe checks the TCP session setup to the remote service only. As stated above , a successfully completed session setup most probably means the service is healthy. As an extra measure, some actual message exchange can be enabled. This is done by checking this box.
This message text is sent to the service after the TCP session has been established.
This is the message expected to be received from the service. Reception starts after sending the "Message to Send". Please note that the "Message Expected" is compared against the first message sent from the service on the TCP session. With some protocols, this means the message compared is an initial greeting message and not a response to the "Message to Send".
The Syslog facility to be assigned to events created by this service. Most useful if the message is to forward to a Syslog server.
The Syslog priority to be assigned to events created by this service. Most useful if the message is to forward to a Syslog server.
The Resource ID to be assigned to events created by this service. Most useful if the message is to forward to a Syslog server.
The Syslog tag value to be assigned to events created by this service. Most useful if the message is to forward to a Syslog server.
Name of the rule set to be used for this service. The Rule Set name must be a valid Rule Set.