Health Checks

What Is a Health Check?

Health Check is the monitoring unit that periodically measures the accessibility and performance status of the services or the data centers that the DNS records point to. The check results are not used one by one; they are combined with the AND / OR / NOT logic on the Health Scenarios screen and determine to which address or data center the DNS records will be routed.

A check sends a request to the target with the determined Period interval and evaluates the answer within the Timeout period. When the number of consecutive successful results reaches the Required Successes threshold, the check passes to the OK status, and when the number of consecutive failed results reaches the Required Failures threshold, it passes to the Error status; in the results between the two thresholds the previous status is preserved.

In GTM two types of check work together: the protocol checks that the user defines (TCP, HTTP, DNS, LDAP, Oracle, etc.) and the Datacenter HC checks that turn the information collected from the remote data centers into a decision. In addition, the automatic checks produced by the system for every data center are monitored in a separate list.

15

Check type

Datacenter HC, TCP/TCPS, UDP, Ping, HTTP/HTTPS, DNS, FTP/FTPS, LDAP/LDAPS, SMTP/SMTPS, Oracle

Data Center

Datacenter HC

It turns the CPU, bandwidth, service count and vService metrics of the remote data center into a decision

Automatic

System checks

The access, internet and maintenance checks are produced by themselves for every data center

Consecutive Threshold

Success / Failure

The status changes with the consecutive success and failure counts; it is preserved in the intermediate results

Scenario

Decision input

The results are combined in the health scenarios; they can be used with reversing (UNLESS)

TLS

Certificate verification

Server certificate verification and mTLS in the HTTPS, TCPS and SMTP(S) checks

How does it work?

1. The check sends a request to the target over the selected vDevice and route table with the Period interval; the Datacenter HC type does not send a request; it evaluates the information packets coming from the remote data center and, although the Period and Timeout fields are not present in the form, it works with a fixed period in the check engine.
2. Every result is recorded as successful or failed; if Expect Negative Result is on, the result is reversed.
3. Consecutive Required Successes successes make the check OK and consecutive Required Failures failures make it Error; in between the previous status is preserved. A newly added check appears as Preparing until its first decision.
4. The status becomes an input to the Health Scenarios conditions; OK and Error are definite results, and the other statuses are considered "unknown" in the scenario and the decision remains at its previous value.

The Automatic Health Check Records

The second table on the list screen, Automatic Health Checks, shows the checks that are produced by the system and cannot be edited:

Check	Its source	Description
Always	fixed	It is always considered OK; it is used as the "always true" condition in the scenarios.
Never	fixed	It is always considered Error.
<name>(local) has internet access	the local data center	The result of the internet access scenario selected on the Remote Devices screen.
<name>(local) is under maintenance	the local data center	OK while the maintenance mode of the local device is on.
WAN access to <name> is successful	every remote data center	OK if the access from the WAN addresses of the data center is provided.
LAN access to <name> is successful	every remote data center	OK if the access from the LAN addresses is provided.
Access to <name> is successful	every remote data center	OK if there is access over WAN or LAN.
<name> has internet access	every remote data center	The internet status that the remote device reports.
<name> is under maintenance	every remote data center	OK while the maintenance mode of the remote device is on.

<name> is the name of the data center on the Remote Devices (Data Centers) screen; for the local device (local) is added to the end of the local data center name. The data center checks inherit the Required Success / Required Failure values of the data center (if they are undefined, 3 / 3) and are produced even if the related address type is not defined; the WAN access … check of a data center for which only a LAN address is defined never becomes OK.

The automatic checks are selected on the Health Scenarios screen in the same form as the user checks and can be used by being reversed with the UNLESS prefix.

The Status Values

The status circle in the list, the preview panel and the scenarios use the values below:

Status	Color	Meaning
OK	green	The last consecutive results met the Required Successes threshold.
Error	red	The last consecutive results met the Required Failures threshold.
Preparing	yellow	The check has been newly added and has not given its first decision yet.
No data	gray	There is no result for the check yet; the check may have been newly added or its result may not be arriving.

In the scenarios only OK and Error produce a definite result; the other statuses leave the condition "unknown" and the scenario preserves its previous decision. The Partially healthy (yellow) and HC disabled (gray) values in the common status dictionary describe the collective status of the Backend Service groups; the result of a single GTM check does not take these two values.

The Health Check Types

The Check Type list offers the following 16 types, in the screen order:

Check Type	Description
Datacenter HC	It compares the CPU, the bandwidth, the number of running/stopped services and the vService metrics collected from the remote data center with a threshold; it does not send a request.
TCP	It establishes a TCP connection; with an optional scenario it sends data and checks the answer.
TCPS	It establishes a TCP connection over TLS; it runs the TCP scenario with certificate verification and mTLS support.
UDP	It sends data over UDP and checks the expected answer.
Ping	It measures the accessibility of the target address with ICMP.
HTTP	It sends an HTTP request; it checks the status code and the answer content.
HTTPS	It sends an HTTP request over TLS; it has certificate verification and mTLS support.
DNS	It sends a DNS query; it checks that the answer arrives and, optionally, its content.
FTP	It logs in to the FTP server; it optionally lists a directory.
FTPS	It makes an FTP login over TLS.
LDAP	It connects to the LDAP server; it optionally performs authentication.
LDAPS	It establishes an LDAP connection over TLS.
SMTP	It talks with the SMTP server; it optionally starts encryption with STARTTLS.
SMTPS	It establishes an SMTP connection directly over TLS.
Oracle	It connects to the Oracle database; it optionally runs a command and verifies the result.
Expression (JSONata)	It sends no network request; it evaluates a JSONata expression against the facts of the device running the check and the local time.

Operational Best Practices

• The Period and the Timeout must be adjusted according to the target. The default values are a 1-second period and a 1-second timeout; in the checks made to the remote data centers, the timeout is kept shorter than the period by taking the network delay into account.
• The thresholds must be selected so that they filter the temporary fluctuation. The default 3 consecutive successes / 2 consecutive failures is suitable for most environments; if it is not desired that the status changes on a single packet loss, the Required failures is increased.
• In the HTTP checks the answer content must also be checked. Instead of only the status code, the expected text or a JSONata expression is defined with Content Check Mode; a health endpoint that also reflects the dependencies of the service is preferred.
• In the types with TLS, certificate verification must be turned on. While Verify Server Certificate is off, the HTTPS, TCPS, FTPS, LDAPS and SMTPS checks do not verify the server certificate; when the verification is turned on, the selected CA profile and the client certificate are applied to the check in all of these types.
• A vService based control must be made with Datacenter HC. Next to the CPU/BW control at the data center level, a vService Status check is added for the critical vServices; in this way the failure of a single service is also reflected in the routing decision.
• The scenarios must be reviewed before deleting. The scenarios that refer to the deleted check are not updated by themselves; as long as the reference remains, that condition stays "unknown".
• The check type cannot be changed afterwards. The type is locked in the editing form; if a different type is required, a new check is defined.

How to Add?

A new Health Checks check is added through the TR7 web management interface with the steps below:

1. The Configuration Menu is opened by clicking the TR7 logo at the bottom left.
2. The GTM → Health Checks → Add steps are followed.
3. A unique and descriptive name is entered for the check.
4. Check Type is selected; the target address, the period, the timeout and the type-specific fields are filled in.
5. The check is added by clicking the Add button.

TIP

Reaching the page via quick search

Instead of navigating the menu step by step, the related page is reached directly by using the search bar in the bottom left corner of the screen. The search bar opens with the Alt + T shortcut on Windows and Opt + T on macOS; typing the name of the feature being searched for is then sufficient.

The created check can be used in the condition of one or more health scenarios.

Health Checks Listing Screen

By following the GTM → Health Checks path, the list of all the health checks added on the TR7 device is reached. Check adding, editing and deleting operations are performed through this screen.

Health Checks Listing Form

The table opens with the following columns by default:

Column	Description
Status	The status of the check is shown with a colored circle; when it is hovered over, the status text appears (see The Status Values). In a cluster the circle is divided into two halves; every half shows the result of one device and when it is hovered over, the device name appears. Every device runs the check itself.
Name	The name of the check.
Check Type	The check type (Datacenter HC, TCP, HTTP …). In the automatic check table the Always and Never rows are of the Static type and the data center rows are of the Datacenter HC type.

There is no column hidden by default; these three columns are in the column selector. The table is not sorted by default; when a column header is clicked, descending sorting is applied first, then ascending, and on the third click the sorting is removed. The list updates by itself as the check results arrive.

The items in the toolbar are arranged from left to right in the following order; the last two items (Page Information and Page Size) are located in the information strip below the table.

Columns

Which columns are shown in the table is selected; all three columns are on by default. In the same panel, columns are reordered by dragging and alignment is selected per column; the row height is fitted to the page with the Fit rows to the page button, and the column layout is reset to default with the Reset button. When the width badge next to a manually widened column is clicked, the column returns to the automatic width. The layout is stored per user and is common to the two tables.

Filter

The filter button with the funnel icon (tooltip: Filter) opens and closes the filter strip above the table; the button shows the number of active filters with a badge. There are two cards in the strip: Status and Check Type. In the cards the values seen in the list are listed, with the number of rows that have that value in parentheses next to each of them, and more than one value can be selected together; the selections are displayed as a label in the Title = Value form. The layout of the cards is stored per user and is common to the two tables.

Export

The table is exported as Excel, CSV or PDF by clicking the Export button. In the window that opens, the Filename, Format and Data Source, together with the Columns to be exported, are determined; the remaining fields are displayed according to the format: CSV Separator for CSV, Excel Sheet Name for Excel, and Page Orientation and Page Size for PDF.

Add

By clicking the Add button, the form for creating a new check opens in the Add tab.

Edit

By clicking the Edit button, the editing form of the selected check opens in the Edit tab. The button becomes enabled only when a single check is selected. The editing form is the same as the add form; the Check Type field is locked, the other fields can be changed and the change is saved without asking for confirmation.

Delete

When one or more checks are selected and the Delete button is clicked, the related checks are deleted. Before deleting, the "Are you sure?" confirmation is asked. The button is passive while there is no selection.

WARNING

A check that is in use can also be deleted and the confirmation window does not show whether the check is used in the scenarios; before deleting, the Used in tab on the preview panel must be checked.

The deleted check is removed from the check engine and its status is no longer produced. The health scenarios that refer to the check are not updated by themselves; as long as the reference remains, that condition is considered "unknown" and the scenario preserves its previous decision. The related scenarios must be edited after the deletion. The deletion is written into the user operation record.

Search

Used to search all information in the table.

RegExp Search

Used to search all information in the table with a regular expression (RegExp).

Column Based Search

Used to perform a column-based search on the information in the table; a separate search line opens for every column and next to every box there are the Negate button that reverses the result and its own RegExp key.

Page Information

Under the table, how many records are listed in the Showing N-M of T records form and the number of selected records (N selected, or Nothing selected when there is no selection) take place; while a filter is active, the number of applied filters and the shown/total row count are also written.

Page Size

With the Page Size selector at the bottom right, how many checks at most will be listed on one page is determined (the default is 20, and 100 in the automatic checks table; the options are 5, 10, 20, 50, 100, 200, 500 and All); with the arrow icons next to it, the pages are switched between.

There are two tables on the screen

The upper table lists the checks that the user defines; adding, editing and deleting are done from the toolbar of this table. The lower Automatic Health Checks table shows the checks that the system produces (see The Automatic Health Check Records); its title is written at the left of the toolbar, it has its own filter strip and search box, but the selection box and the Add, Edit and Delete buttons do not take place.

Right-Click Menu

When a row is right-clicked, a menu with the name of the check in its title opens. Both operations in the menu apply only to the right-clicked check; a selection made in the list does not affect the menu.

Operation	What it does
Edit	Opens the editing form of the check in the Edit tab; it is the same as the form opened by the Edit button in the toolbar.
Delete	Deletes the right-clicked check; the same confirmation question as the deletion in the toolbar is displayed.

The menu also opens in the automatic checks table; however, the checks that the system produces cannot be edited or deleted, and on these rows both operations return an error.

Preview of the Selected Check

When a row in the list is clicked, the preview of the check opens on the right of the screen; when the selected row is clicked again, the panel closes. In the title there are a status circle, the name of the check and its subtitle, and at the top right there are two operations.

Preview of the Selected Check

Operation	What it does
Edit	Opens the editing form of the check in the Edit tab; this operation is not present on the automatic checks.
Log	Opens the GTM event records (the status changes) and the user operations that belong to the check in a window, without leaving the page.

The panel has three tabs; the last one is displayed only if there is a scenario that uses the check:

Details

Lists the status of the check, its last event and the configuration lines according to the type (the table below).

Log

Lists the status changes of the check and the user operations performed on it as a timeline.

Used in

Lists the health scenarios that use the check in their condition; the badge next to the tab name shows the number of usages. When a row is clicked, it is passed to the related scenario.

The rows in the Details tab are as follows, in order; in a cluster the State and Latest Actions rows are shown separately for every device and the other rows in a single column. The rows are visible according to the check type; the scenario steps, the TLS selections, the HTTP header/body and the DNS answer check fields in the form are not listed in the preview.

Row	Description	Visibility condition
State	The status text (OK, Error, Preparing, No data); the color is shown only in the circle in the title.	Always
Latest Actions	The last GTM event that belongs to the check and its date.	Always
Automatic	It is shown with the ✔ mark on the automatic checks.	Only on the automatic checks
Check Type	The check type.	Always
JSONata Expression	The evaluated JSONata expression.	Expression (JSONata)
Address	The target address and port (ip : port).	Other than Datacenter HC and Expression (JSONata)
vDevice	The virtual device on which the check is made.	Other than Datacenter HC and Expression (JSONata)
Route Table	The route table from which the check is made.	Other than Datacenter HC and Expression (JSONata)
Datacenter	The selected data center.	Datacenter HC
Datacenter HC Type	The selected metric.	Datacenter HC
Service Name	The selected vService (name (identifier)).	It is listed in every metric of the Datacenter HC type; the value is present only in the vService metrics
Criteria	The comparison operator and its value.	It is listed in every type other than vService Status; the value is present only in Datacenter HC
Period	The check period (seconds).	Other than Datacenter HC
Timeout	The timeout (seconds).	Other than Datacenter HC
FTP User / FTP Action / FTP Path	The FTP login information; the path only on the check in which a listing is made.	FTP, FTPS
Expected Status Codes / Expected Content Query	The HTTP answer expectations.	HTTP, HTTPS
Query	The queried domain name.	DNS
Path + Query / Method / Virtual Domain (Host/SNI)	The settings of the HTTP request.	HTTP, HTTPS
Required Successes / Required Failures	The consecutive success and failure thresholds.	Always

Check Add Form

A new health check is added on the TR7 device by following the GTM → Health Checks → Add steps. There are no titled sections in the form; the type-specific field groups are separated with untitled, colored-framed boxes. The fields are explained in the screen order: first the common starting fields (Name … Expect Negative Result), then Period / Timeout, then the type-specific box according to the selected type and at the very end Required Successes / Required Failures. In the Datacenter HC type the Address, vDevice, Route Table, Period and Timeout fields are not present; the other common fields take place in this type as well.

INFO

Name Required

The name of the health check is entered. The name identifies the check in the list, in the scenario conditions and in the logs. This screen does not prevent the same name from being used in a second check; giving a distinctive name is recommended.

INFO

Check Type Default: Datacenter HC

The check type is selected: Datacenter HC, TCP, TCPS, UDP, Ping, HTTP, HTTPS, DNS, FTP, FTPS, LDAP, LDAPS, SMTP, SMTPS, Oracle, Expression (JSONata) (in the screen order). According to the selected type, the type-specific fields are added to the form. The type is locked in the editing form; it cannot be changed afterwards.

INFO

Address Required

The address and the port of the target on which the check will be made are entered into separate boxes; an IP or a domain name is accepted as the address. In the Ping type only the address is entered, the port box is not visible. In the Datacenter HC and Expression (JSONata) types this field is not present.

INFO

vDevice

From which virtual device the check will be made is selected; in the list Host Device (the main device) is in the first place and comes selected by default, and afterwards the defined vDevices take place. It is not present in the Datacenter HC and Expression (JSONata) types.

INFO

Route Table Default: the first option

From which route table of the selected vDevice the check will be made is selected; the first table of the list comes selected. It is not present in the Datacenter HC and Expression (JSONata) types.

INFO

Expect Negative Result Default: off

When it is turned on, the check result is reversed: when the target cannot be reached or the expected answer does not arrive, the result is considered successful. It is used in the reverse controls such as verifying that a service is closed; it is visible in all the types, including Datacenter HC.

INFO

Period Default: 1

At how many seconds interval the check will be made; a value between 0.5 and 3,600 is entered. It is not present in the Datacenter HC type.

INFO

Timeout Default: 1

The answer waiting period (seconds); when the period expires, the result is considered failed. A value between 0.01 and 3,600 is entered. It is not present in the Datacenter HC type.

INFO

Required Successes Default: 3

The number of consecutive successful results required for the check to pass to the OK status; an integer between 1–10.

INFO

Required Failures Default: 2

The number of consecutive failed results required for the check to pass to the Error status; an integer between 1–10.

The Health Check Type Specific Fields

Below, only the fields specific to that type of every type are explained, in their order in the form. The common fields take place in every type.

The TLS Fields

In the HTTPS, TCPS, FTPS, LDAPS, SMTPS types and in the SMTP type with STARTTLS on, the four fields below take place in the form in this order: in HTTPS at the beginning of the type-specific fields (Virtual domain at the end), in TCPS before the TCP Scenario, and in the FTPS / LDAPS / SMTP(S) types at the end of the type-specific fields. The server certificate verification and the client certificate are applied in the HTTPS, TCPS and SMTP(S) checks; in the FTPS and LDAPS types these fields are visible in the form but are not applied.

INFO

Verify Server Certificate Default: off

When it is turned on, the certificate that the server presents is verified; a certificate that cannot be verified makes the check fail. While it is off, the certificate is not checked.

Virtual Domain (Host/SNI)

The server name (SNI) to be sent in the TLS handshake. In the HTTP family the same field is also used as the Host header and takes place at the end of the list, separately from the TLS fields.

Verification CA Profile

The CA profile to be used for the certificate verification is selected; in the list there are None and the defined certificate authority profiles. The field is visible while Verify Server Certificate is off as well.

Client Certificate to Present (mTLS)

If the server asks for a client certificate, the certificate to be presented is selected; in the list there are None, the client certificates and the certificates.

Datacenter HC

It compares the information collected from the remote data center at every query with a threshold; it does not send a request. This type does not use the Address / vDevice / Route Table / Period / Timeout fields; the evaluation is made as new information arrives from the data center.

Datacenter HC Add Form

INFO

Datacenter Default: the first option

The data center whose metric will be read is selected. In the list first the local data center and then the remote data centers defined on the Remote Devices (Data Centers) screen take place.

INFO

Datacenter HC Type Default: Cpu usage

The metric to be compared is selected; the list is in the screen order.

The data center metrics:

Option	Meaning
Cpu Usage	The processor usage of the data center (%).
BW	The total network traffic of the data center.
Up Services	The number of vServices considered healthy in the data center.
Down Services	The number of vServices considered unhealthy in the data center.

The vService metrics (when they are selected, the Service Name and Service ID fields become visible):

Option	Meaning
vService Status	The status of the selected vService; if it is OK or in a warning status, the check is successful. In this option the Criteria field is not visible.
vService Sessions	The new session rate of the vService.
vService Request per Second	The number of requests per second of the vService.
vService Connections	The number of connections of the vService.
vService CPU Usage	The processor usage of the vService.
vService BW	The bandwidth of the vService.

INFO

Service Name

It is visible in the vService metrics. The vServices that the selected data center reports are listed; the list is empty until the first information packet arrives from the data center. The selection writes the vService identifier into the Service ID box right under it; the two fields show the same value and when one of the two is changed, the other one changes as well.

INFO

Criteria Default: Greater Than

The condition with which the metric will be compared is established with an operator and a numeric value. In the operator list the following options take place, in the screen order:

Option	Meaning
Greater Than	The measured value must be greater than the entered number (the default).
Less Than	The measured value must be less than the entered number.
Equals To	The measured value must be equal to the entered number.
Range	The measured value must stay between the entered lower and upper limits (two values are entered).

Only a number can be entered into the value field; when a value that is not a number is entered, the Value must be a number warning is given. In the vService Status metric this field is not displayed at all.

TCP

It establishes a TCP connection; with an optional scenario it performs content verification. The connection must be established within the Timeout period and every scenario step must meet its expectation.

TCP HC Add Form

INFO

TCP Scenario Default: off

When the TCP Scenario switch is turned on, the steps to be executed in order after the connection are defined; every step is added as a card and its type is selected from the TCP Action (N) field:

• Send Text: text is sent over the connection: the content is written into the Text to Send box and the format is selected with Data Format (Text, Hexadecimal, Base64; the default is Text). In the Hexadecimal and Base64 formats the data are transmitted as they are. In an HTTP-like protocol the request line is written in the first line, the headers in the following lines and an empty line is left at the end.
• Expect Text: the text in the Text to Expect box is expected to appear in the answer.
• Expect Regex: the regular expression in the Regex to Expect box is expected to match the answer.
• Wait(ms): it is waited for as long as the Wait Time(ms) (at least 1).

A new step is added with the plus icon; the new step opens with the Send Text type. The steps are executed in the order in which they are defined.

TCPS

TCPS HC Add Form

It establishes a TCP connection over TLS. Its fields are the same as TCP; the TLS fields (Verify Server Certificate, Virtual Domain (Host/SNI), Verification CA Profile, Client Certificate to Present (mTLS)) come before the TCP Scenario field.

UDP

It sends data over UDP and checks the answer.

UDP HC Add Form

INFO

UDP Scenario Default: off

When the UDP Scenario switch is turned on, the steps to be executed in order are defined; the type of every step is selected from the UDP Action (N) field:

• Send Data: the data in the Data to Send box are sent in the format selected with Data Format (Text, Hexadecimal, Base64).
• Wait(ms): it is waited for as long as the Wait Time (ms) (at least 1).
• Expect Text: the text in the Text to Expect box is expected to appear in the answer.
• Expect Regex: the regular expression in the Regex to Expect box is expected to match the answer.

The new step opens with the Send Data type; the steps are executed in the order in which they are defined.

Ping

It measures the accessibility of the target address with ICMP. It does not contain a type-specific field; in the Address field only the address is entered, the port box is not visible.

Ping HC Add Form

HTTP

It sends an HTTP request; the status code and, optionally, the answer content are checked.

HTTP HC Add Form

INFO

Path + Query

The path and the query string on which the request will be made are entered; when it is left empty, the request is made to the root path (/).

INFO

Method Default: GET

The HTTP method is selected. The list is in alphabetical order and contains 39 methods together with the WebDAV methods; GET, HEAD, POST, PUT, DELETE, OPTIONS and PATCH are among them.

INFO

HTTP Version Default: HTTP/1.1

The protocol version of the request: HTTP/1.1 or HTTP/2.

INFO

HTTP Headers Default: Automatic

The headers to be sent with the request. While Automatic is selected, the headers are created automatically; when Choose is selected, the HTTP Header Name / HTTP Header Value pairs are added to the table.

INFO

HTTP Body Default: Disabled

It is opened with the Enabled / Disabled switch; the body to be sent with the request is entered.

INFO

Expected Status Codes Default: 200

The HTTP status codes expected for the check to be considered successful are determined with a multiple selection; if the answer code is not one of the selected ones, the check fails.

INFO

Content Check Mode Default: Basic (string match)

It makes it possible for the answer to be evaluated according to its content in addition to the status code:

Option	Meaning
Basic (string match)	The text written in the Expected Content Query field is searched for in the answer body; if it is not found, the check is considered failed. When the field is left empty, no content check is made (the default).
JSONata Expression	The expression in the JSONata Query field is evaluated on the status code, the body and the headers; when its result is true, the check is considered successful (e.g. status = 200 and body.status = "UP").

According to the selection, only the related query field is visible.

INFO

Virtual Domain (Host/SNI)

The domain name to be sent in the Host header of the request; in the HTTPS type it is also used as the server name (SNI) in the TLS handshake. It is entered in order to reach the correct service on the targets that host more than one virtual server at the same address.

HTTPS

It sends an HTTP request over TLS. At the beginning of the type-specific fields the TLS fields (Verify Server Certificate, Verification CA Profile, Client Certificate to Present (mTLS); in this order) take place; afterwards all the fields of the HTTP type come in the same order. Virtual Domain (Host/SNI) is at the end of the list.

HTTPS HC Add Form

DNS

It sends a query to the DNS server; it checks that the answer arrives and, optionally, its content.

DNS HC Add Form

INFO

Query Required

The domain name to be queried is entered; the server answering within the Timeout is required for the check to be considered successful.

INFO

Reverse DNS (PTR) Default: off

When it is turned on, the query is made as a reverse DNS (PTR) query; the DNS Record Type field is not displayed at all.

INFO

DNS Record Type Default: A

The record type to be queried: A, AAAA, CAA, CNAME, MX, NAPTR, NS, PTR, SOA, SRV, TXT. It is not visible while Reverse DNS (PTR) is on.

INFO

Answer Check Mode Default: None

Whether the answer content will be checked or not is selected:

Option	Meaning
None	The content is not checked; the answer arriving is enough (the default).
Text Match (contains)	The text in the Expected Answer Text field is searched for in the answer.
Regex Match	The answer is compared with the regular expression in the Expected Answer Regex field.

According to the selection, one of the fields below is visible.

Expected Answer Text

It is required when Text Match (contains) is selected; the text expected to appear in the answer.

Expected Answer Regex

It is required when Regex Match is selected; the regular expression expected to match the answer.

FTP

It logs in to the FTP server; it optionally lists a directory.

FTP HC Add Form

INFO

FTP User Required

The user name for the login.

INFO

FTP Password Required

The password for the login.

INFO

FTP Action Default: onlyLogin

The scope of the check is selected; the options are written on the screen as onlyLogin and loginAndList:

Option	Meaning
onlyLogin	Only a login is made; if the login is successful, the check is successful (the default).
loginAndList	A login is made and the directory in the FTP Path field is listed; both operations must be successful.

FTP Path

It is visible when loginAndList is selected; the directory to be listed.

FTPS

It makes an FTP login over TLS. Its fields are the same as FTP; at the end the TLS fields come. In this type the server certificate verification and the client certificate are not applied; the TLS fields are visible in the form but do not affect the check.

FTPS HC Add Form

LDAP

It connects to the LDAP server; it checks the binding (bind) operation with optional authentication.

LDAP HC Add Form

INFO

LDAP Authentication Default: off

When it is turned on, the connection is made with authentication and the two fields below become visible; while it is off, it is connected anonymously.

LDAP Username

Required; the user name that will connect.

LDAP Password

Required; the password of the user.

LDAPS

It establishes an LDAP connection over TLS. Its fields are the same as LDAP; at the end the TLS fields come. In this type the server certificate verification and the client certificate are not applied; the TLS fields are visible in the form but do not affect the check.

LDAPS HC Add Form

SMTP

SMTP HC Add Form

It talks with the SMTP server; when a positive answer is received from the server, the check is successful.

INFO

EHLO Hostname

The machine name to be sent in the greeting command; while the field is empty, the tr7-hc placeholder is displayed in the box.

INFO

Use STARTTLS Default: off

When it is turned on, the connection is encrypted with STARTTLS and the TLS fields become visible in the form.

SMTPS

SMTPS HC Add Form

It establishes an SMTP connection directly over TLS. The EHLO Hostname field and the TLS fields are present; the Use STARTTLS option is not visible in this type.

Oracle

It connects to the Oracle database; it optionally runs a command and verifies its result.

Oracle HC Add Form

INFO

User Required

The user name that will connect to the database.

INFO

Password Required

The password of the user.

INFO

Connection String Required

The connection string of the database.

INFO

Oracle Scenario Default: off

When the Oracle Scenario switch is turned on, the steps to be executed in order after the connection are defined; the type of every step is selected from the Oracle Action (N) field:

• Execute Command: the query in the Command box is run; the text in the Expected Text field is expected to be found in the result and at least as many rows as the Expected Number of Rows are expected to return.
• Wait(ms): it is waited for as long as the Wait Time(ms).

The steps are executed in the order in which they are defined.

Expression (JSONata)

It sends no network request to a target. A JSONata expression is evaluated against the facts of the TR7 device running the check (e.g. the device number within the cluster, the device name) and the device's local time. If the result of the expression is a true (truthy) value the check is considered successful, if it is a false (falsy) value it is considered failed; 0, empty text and false count as failure. A broken expression also makes the check fail.

Since there is no target, the Address, vDevice and Route Table fields are not displayed in the form for this type; the check runs on the host device. In a cluster setup each TR7 device evaluates the expression with its own facts; if the expression reads device facts, different results may be seen on the two devices. Its typical use is to tie records to the cluster device or to the time through a Health Scenario; for example the expression device.clusterId = 1 succeeds in a cluster only on the first device; on a device where no cluster was ever set up there is no device number, so this expression fails.

Expression (JSONata) HC Add Form

INFO

JSONata Expression Required

The JSONata expression to be evaluated is entered; the empty field shows the device.clusterId = 1 example. While the field is empty, the "Required field" warning is displayed below it. For an expression with a syntax error, the "JSONata syntax error: <detail>" warning is displayed below the field and the Add button stays disabled. The JSONATA button on the right of the field opens a separate window that helps with writing the expression.

The check is evaluated once every Period; the Expect Negative Result, Required Successes and Required Failures fields are applied as in the other types. In the preview panel of the check, the expression itself is displayed in the JSONata Expression row.

INFO

Add

The check is added by clicking the Add button; while there is an erroneous field in the form, the button is passive. The adding does not ask for confirmation; the record returns immediately and the Add tab closes. The check is conveyed to the check engine of the selected vDevice (of the host device in the Expression (JSONata) type) and appears as Preparing until its first decision; the operation is written into the user operation record ("<name>" health check is created).

Operating Mechanism

INFO

• Where does it work? The protocol checks are made in the check engine of the selected vDevice and from the selected route table. The Datacenter HC checks work on the main device and do not send a request; they are re-evaluated with the information packet that arrives from the remote data center at every query, and for this reason the Period and Timeout fields are not present in this type.
• The periods. Period and Timeout are in terms of seconds; a request that times out produces a failed result.
• The decision rule. The last results are kept in order: if all of the last Required Successes results are successful, the status becomes OK, and if all of the last Required Failures results are failed, it becomes Error; otherwise the previous status is preserved. Expect Negative Result reverses the results before this evaluation.
• The start. A new check appears as Preparing until its first decision; when the connection with the check engine is cut, the statuses become No data. Always and Never are not affected by this interruption.
• Its effect on the scenarios. OK is considered true and Error false; the other statuses are "unknown". In an AND condition one definite false and in an OR condition one definite true makes the decision; otherwise an unknown member leaves the scenario decision suspended. In a check reversed with UNLESS, only the definite results are reversed.
• The cluster. Every device runs the checks itself and keeps its own result; the status circle in the list is divided into two halves and the preview title shows the result of the two devices with a separate circle per device.

Scope and Limits

INFO

• The screen requires a GTM license and full GTM authorization. The GTM tab is visible with the display authorization; this screen opens only on the users who have full authorization in the GTM area, and if there is no GTM module in the license, the Not covered by your license card is displayed.
• The name uniqueness is not enforced. A second check that carries the same name can be saved.
• The type cannot be changed. The check type is selected only while adding.
• The automatic checks cannot be managed. They are only monitored; their names and thresholds come from the data center definition.
• The deletion does not clean the dependencies. The scenarios that refer to the deleted check must be updated manually.
• The logs. The status changes of the check and the user operations performed on it are monitored in the Log window on the preview panel and on the GTM Logs screen.

Usage Location

The health checks do not produce a decision on their own; they are selected in the condition builder of the scenarios on the Health Scenarios screen.

The place where it is used	What it does
The Health Check condition of the scenario	The results of the checks are combined with and / or and UNLESS and the basic status of the scenario is calculated.
The Activation Check and Deactivation Check conditions of the scenario	In the With Trigger mode, the gate conditions that verify the result of the trigger actions are also selected from the same builder.

With the Add button of the selector in the builder, a new check can be defined in the same window and added to the condition. In which scenarios a check is used is seen from the Used in tab on the preview panel.