FR EN

Site monitoring

Estimated reading: 13 minutes

Site monitoring allows the SERVERware administrator to configure the monitoring of remote sites by creating a set of tests that will indicate whether the monitored site is available or not. The administrator can add actions that will be executed if the tests fail.

Actions can be configured to trigger only if all tests fail (ALL action types) or if any of the tests fail (ANY action types).

The main function of the site monitor is to monitor the replication site with a series of different tests and to perform actions based on the test results. 

To create and start monitoring the site, select Site monitoring in the Replication menu.

  • Create a site monitor : This will open a new frame to create a new site monitor (create an empty set of tests to run and actions to trigger).
  • Edit : Edit the existing site monitor (the site monitor must be stopped before editing).
  • Remove : Delete the existing site monitor (the site monitor must be stopped before deleting it).
  • Start : Start the site monitoring actions.
  • Stop : Stop the site monitor actions.

When the button Create a site monitor is clicked, the site monitor edit view will open.

Here, you can add various tests to your new site monitor.

  • Name : enter the name of the new site monitor. Make sure to set the name in a few words explaining which site you are monitoring or similar for a better overview.
  • Interval : Select the period from the predefined drop-down list. This is the period during which all tests of this monitor will be repeated. 
  • Add a test : This will open a pop-up window with the test design settings.
  • ICMP test settings: the ICMP test is the set of standard ICMP commands and additional success conditions.
FieldDescription
DestinationThis will be the destination of our ICMP test, set the IP address or the partition name as the destination.
Number of packets Specifies the number of echo requests, or pings, to send.
Test timeout(s) Indicates the maximum duration of the test length. Past this delay, the test will stop.
Packet delay (ms) The delay between pings refers to the time in milliseconds between each successive PING to the target address. Setting this value very low will send a constant stream of pings to the destination IP address.
TTL Indicates the number of hops allowed to the specified address. With a setting of 10, your PING test could pass through up to 10 different routers on the way to the remote address before being rejected by the network.
Packet size (B) Indicates the number of bytes of data to send. The default value is 64, a combined packet size of 56 bytes with the 8 bytes of ICMP header data.
Maximum loss (%) Indicates the maximum acceptable amount of “packet loss” in percentages (%).
Maximum average latency (ms) Indicates the maximum acceptable amount of average latency in milliseconds. If the latency is higher than the entered value, the test will fail.
End timeWhen enabled, it will ignore the Test Timeout Expiration field.
Invert result When enabled, the test results will be inverted: A failed test will pass and vice versa.
Dry runWhen you press it, you will run the dry run test and display the results. (for a successful test, the GREEN information bar will be displayed, and a failed test will be a RED information bar).
CancelWill cancel all changes and close the dialog.
UpdateWill update the test configuration and close the dialog.

Example of a successful test:

Example of a failed test:

  • HTTP test settings 

The HTTP test uses the GET, HEAD, POST, PUT, DELETE standards, the set of requests, and additional success conditions.

The HTTP (Hypertext Transfer Protocol) is designed to enable communications between clients and servers. HTTP works as a request-response protocol between a client and a server. Example: A client (our test) sends an HTTP request to the server; then the server returns a response. The response contains status information about the request and may also contain the requested content.

FieldDescription
URL This will be the destination of our HTTP test, http:// or https:// are mandatory in the destination address.
Request type
  • The HTTP GET method requests a representation of the specified resource. Requests using GET should only be used to request data (they should not include data).
  • The HTTP HEAD method requests the headers of the requested URL.
  • The HTTP POST method sends data to the server. The type of the request body is indicated by the Content-Type header.
  • The HTTP PUT request method creates a new resource or replaces a representation of the target resource with the request payload.
  • The HTTP DELETE request method deletes the specified resource.
Test timeout(s) Indicates the maximum duration of the test length. Past this delay, the test will stop.
Check SSL You can check the SSL certificate on your destination to make sure it is correctly installed, valid, trusted and does not give any error to any of your users.
Headers

HTTP headers allow the test server to pass additional information with an HTTP request or response. An HTTP header consists of its Name and Value.

Arguments

HTTP arguments allow the test server to pass specific arguments with an HTTP request or response. An HTTP argument consists of its Name and Value.

Body

The body is used to manually add a body to your request, based on your needs.

JSON example:
{
id: 2,
name: Small,
cpu_share: 512,
cpu_limit: 2,
mem_limit: 1024,
storage: 10,
io_limit: 20971520,
iops_limit: 200,
vps_count: 0,
enabled: true,
_state: enabled
}

Response codeHTTP response status codes indicate whether a specific HTTP request has been successfully completed. The test will fail if the requested code is not returned from the destination. Responses are grouped into five classes: Informational responses (100-199), Successful responses (200-299), Redirects (300-399), Client errors (400-499), Server errors (500 to 599).
More details on response codes: here
RegEx reply

The regular expression is used to parse the response code.

Example:
in the test above, if the test response contains SERVERware, the test will succeed.
More details on the use of regular expressions: here

Invert result When enabled, the test results will be inverted: A failed test will pass and vice versa.
Launch Beta-test buttonWhen you press it, you will run the Beta-test and display the results. (for a successful test, the GREEN information bar will be displayed, and a failed test will be a RED information bar).
Cancel buttonWill cancel all changes and close the dialog.
UpdateWill update the test configuration and close the dialog.
  • TCP test settings

The Transmission Control Protocol (TCP) is a transport protocol that runs on top of the Internet Protocol (IP). Together, these two protocols often form what is called the TCP/IP protocol stack. TCP is a protocol that enables reliable process-to-process communication in a multi-network environment. Unlike IP, which does not guarantee the delivery of packets in the correct order or their actual arrival, TCP detects these problems, retransmits lost data, eliminates duplicate data, and reorders data in the correct order. 

As a result, TCP ensures reliable, ordered, and error-free data delivery between applications that communicate over an IP network.

TCP test example:

FieldDescription
AddressThis will be the destination IP address for our TCP test.
PortSpecifies the target port.
Test timeout(s) Indicates the maximum duration of the test length. Past this delay, the test will stop.
Invert result When on, it will invert the test results. A failed test will pass and vice versa.
Test the payloadThe payload of a TCP or UDP packet is the data part of the packet.
Response size (B) Expected size in bytes of the response payload. If the response payload returns the correct response size, the test success condition is met.
RegEx replyThe regular expression is used to parse the response code. More details on the use of regular expressions: here
ReplyWhen enabled, the success condition parameters will be used in the test.
Dry run buttonWhen you press it, you will run the dry run test and display the results. (for a successful test, the GREEN information bar will be displayed, and a failed test will be a RED information bar).
Cancel buttonWill cancel all changes and close the dialog box.
Add/UpdateWill add/update the test configuration and close the dialog box.

  • UDP test settings

The UDP (User Datagram Protocol) is a connectionless transport layer protocol (layer 4) belonging to the Internet protocol family. UDP mainly serves as an interface between IP and higher-layer processes. UDP protocol ports make it possible to distinguish between multiple applications running on a single device. 

Unlike TCP, UDP adds no reliability, flow control, or error recovery features to IP. Due to its simplicity, UDP headers are shorter and consume less network bandwidth than those of TCP. 

UDP is useful in situations where the reliability mechanisms of TCP are not needed, for example when the application layer handles error correction and flow control. UDP is the transport protocol for many well-known application protocols, including the Network File System (NFS), the Simple Network Management Protocol (SNMP), the Domain Name System (DNS) and the Trivial File Transfer Protocol (TFTP).

UDP test example :

FieldDescription
Address:This will be the destination IP address for our TCP test.
Port:Specifies the target port.
Test timeout(s):Indicates the maximum duration of the test length. Past this delay, the test will stop.
Invert result:When enabled, the test results will be inverted: A failed test will pass and vice versa.
Test the payload:The payload of a UDP packet is the data part of the packet.
Response size (B):Expected size in bytes of the response payload. If the response payload returns the correct response size, the test success condition is met.
RegExp reply:The regular expression is used to parse the response code. More details on the use of regular expressions: here
Select the answer port:When enabled, the success condition parameters (response port) will be used in the test.
Dry run buttonWhen you press it, you will run the dry run test and display the results. (for a successful test, the GREEN information bar will be displayed, and a failed test will be a RED information bar).
Cancel buttonWill cancel all changes and close the dialog box.
Add/UpdateWill add/update the test configuration and close the dialog box.

  • MMonit integration

M/Monit uses Monit as an agent and can manage and monitor all your hosts and services. The SERVERware 4.3.x version comes with M/Monit integrated, which can be used to monitor SERVERware systems.

A new option MMonit is added to the drop-down list Add a site test to facilitate the configuration of SERVERware site monitoring with the third-party monitoring tool MMONIT.

In the field Site monitoring name, enter the desired name for the monitor (in the example, we will use MMONIT). Set the schedule time (corresponding to the time at which the test will be triggered) and press Save and apply.

Then, add a new site test (in the drop-down list, select MMonit).

A pop-up window will appear:

Fill in the fields as follows:

  • URL: http://<MMONIT IP>:8080/api/1/reports/events/list
  • Request type: GET (according to the MMonit API documentation)
  • Test timeout in seconds: ten (the test will wait for a response for a maximum of 10 seconds)
  • Arguments: z_csrf_protection with the value disabled
  • Status with the value 1 (to filter failure events according to the MMonit API documentation)
  • Authentication: Enter the MMonit username and password (those of the GUI)
  • Success conditions: Response code: 200 (default),
  • RegExp reply (to search for the previously defined hostname in MMonit)

You can now test your configuration by pressing the button Dry Run. The result should be Test successfuli (make sure your MMonit is not already experiencing failures). Press Updater to save the test in the list of tests.

Create actions to trigger if the conditions are met:

  • The button Add action allows you to add an action to the action list, with the selected trigger option:
  • Trigger if : Two conditions available (ALL and ANY) and an action (Alarm).
  • ALL : Triggers the alarm only when all tests fail for this site.
  • ANY : Triggers an alarm when any of the tests fail for this site.

Alarm : Select the action to trigger when the conditions are met. The alarm will be displayed on the dashboard, and an email notification will be sent to the administrator.

Share

Site monitoring

Or copy the link below

CONTENT