NS1 monitors collect health and performance data from a specified device or endpoint and then send the data back to the NS1 platform. You can connect a monitor to one or more answers within DNS records to automatically update the corresponding answer as conditions change. If configured, the record's Filter Chain configuration will reference certain answer metadata fields to make traffic routing decisions.
For example, you can attach a monitor to the Up/Down metadata field within the corresponding DNS answers, and then create a Filter Chain that uses the "Up" filter, ensuring only available endpoints are returned to requesting clients. The attached monitor ensures automatic failover to available endpoints since the answer's metadata is always updated based on the latest data collected.
There are four different types of monitoring probes you can configure on the NS1 platform: DNS, HTTP/S, PING (ICMP), and TCP. This article explains the configuration process for an HTTP or HTTPS monitoring job, including how to connect the monitor to a corresponding DNS answer.
HTTP/HTTPS monitoring is used to check website availability. The monitoring system connects via HTTP/HTTPS to a server and waits for a response. Then the monitor assesses the connection health based on specified criteria — including the HTTP headers and body in the response.
Follow the instructions below to create a new HTTP/S monitoring job (also referred to as a probe) in the NS1 portal.
-
In the NS1 portal, navigate to the Monitors page.
-
Click the "add" icon (+) to create a new HTTP or HTTPS monitoring job (probe).
-
Click the drop-down in the upper left corner and select HTTP from the list.
-
Enter a name for the HTTP/S monitor.
-
(Optional) If desired, toggle the switch next to Monitor paused to deactivate the monitor. By default, this option is disabled, meaning the monitor will be active once the monitoring job is saved.
-
(Optional) If desired, toggle the switch next to Notifications on to disable notifications for this monitoring job. By default, this option is enabled, meaning notifications will be active once the monitoring job is saved. Note that notifications are sent according to the attached notifier lists which you can configure after creating this monitoring job.
-
Under Monitoring regions, select one or more locations from which monitoring will be executed.
-
Under Policy, select the policy to use to determine whether the monitored endpoint is "down" (as in, unavailable). Choose one of the following:
-
Quorum - If tests conducted from a majority of monitoring regions do not meet the "up" conditions, then the monitored host is marked as down.
-
All - If tests from all monitoring regions do not meet the "up" conditions, then the monitored host is marked as down. In other words, only tests from one of the monitoring regions must meet the "up" conditions in order for the host to be marked as up.
-
One - If a test from one of the monitoring regions does not meet the "up" conditions, then the monitored host is marked as down. In other words, tests from all of the monitoring regions must meet the "up" conditions for the host to be marked as up.
-
-
Under Frequency, enter the amount of time in seconds between each monitoring test conducted in each region. The minimum setting is 60 (as in, 60 seconds).
-
Under Up conditions, click Add condition to define the condition(s) the monitored host must meet in order to be considered "up."
Click the first drop-down and select the metric to validate during the test: HTTP response body or HTTP status code.
Then, choose the comparison operator (=, <, >, etc), and the value to compare. Note if you select HTTP Response Body, the only comparison option is “contains.”
Note
You can add multiple "up" conditions, just note that all conditions must be met in order for a test run to consider the host "up."
Warning
The response body in an HTTP/S monitor cannot exceed 100k characters.
-
(Optional) Select the checkbox next to Rapid recheck to automatically conduct a second verification test before changing the status of a host. Enabling this option can help prevent false positives.
-
Under HTTP settings, enter the URL to monitor.
Note
To test using HTTPS, start the URL with HTTPS:// As the default is HTTP. The hostname in the URL is used to determine the IP address of the host to test. If you want to test against a specific virtual hosting server, specify that hostname in the URL. For example, if testing a server hosted on AWS, use something like myserver.us-east-1.elb.amazonaws.com/healthcheck.php.
-
Under Virtual host, enter a string which will be included as the HOST request header as part of the HTTP transaction. For example, if Virtual host = www.example.com, then Host:www.example.com will be included in the HTTP request header. The virtual host is also used to support testing hosts that utilize server name indication (SNI). The monitor adds the virtual host to the TLS handshake process so that it receives the correct SSL certificate, enabling the rest of the TLS handshake to proceed as normal.
-
Enter the desired HTTP method for this monitoring probe. The default request method is GET.
-
Under User agent, enter a nominal description for this monitoring job to include in the User-Agent request header. The default is "NS1 HTTP Monitoring Job."
-
Under Authorization header, enter the authorization request header to use during the HTTP transaction such as a bearer token or API key.
-
(Optional) Select the checkbox next to Follow HTTP redirects:
-
If enabled, the monitor will attempt to connect to the URL and, if the website responds with an HTTP redirect (e.g., 30x response code), the monitor will try to connect to the new URL to which it is redirected. The monitor status reflects that of the new URL.
-
If disabled, the monitor will not follow redirects, and the monitor status will always reflect the original URL configured.
-
-
Under Connection timeout, enter the amount of time (in seconds) the NS1 monitoring probe will spend trying to establish a connection with a host ("host:port"). If there is no response or if the host rejects the connection within this period of time, the monitoring job will be marked as "down" or unavailable. The default is 5 (as in, 5 seconds).
-
Under Idle timeout, enter the amount of time in seconds used only to read the response body after the connection is established and the HTTP request is sent. The default is 3 (as in, 3 seconds).
-
(Optional) Select the checkbox to Add TLS verify on this monitor to enforce TLS certification verification. NS1 recommends keeping this option disabled if the monitor is failing due to a certificate error, such as an expired certificate for which you do not want this to be used as a failure condition.
-
(Optional) Select the checkbox next to Connect over IPv6 to ensure the monitor connects exclusively over IPv6. If selected, you must enter a fully qualified domain name (FQDN) or IPv6 address in the URL field.
-
Once complete, click Save probe.
After creating a new monitoring job, you can connect it to the corresponding DNS answer(s) via each answer's up/down metadata field. This connection ensures the answer metadata is always updated with the latest health status of the monitored endpoint.
Note
After connecting a monitor to each answer in the DNS record, you can configure a Filter Chain that includes the "Up" filter. With each incoming query, the Up filter references the Up/Down metadata field for each answer and eliminates any "down" answers from the list of available answers that will be returned to the requesting client. You can use the Up filter in conjunction with others to define custom traffic steering policies. Most Filter Chains should include the Up filter as the first filter in the chain, meaning NS1 will eliminate "down" answers before passing the list to the next filter for processing.
For example, you can use the Up filter followed by the Select First N filter to configure automatic failover in which the NS1 platform will eliminate "down" answers, and then return only the first answer in the list. You can add a geographic filter in between the two filters to rearrange the list based on geographic proximity to the requester before passing to the Select first N filter.
Follow the instructions below to connect a monitor to an answer's metadata within a DNS record.
-
Under DNS > Zones, navigate to the record upon which you want to attach the monitor. Then click into the record to view associated answers.
-
In the NS1 portal, navigate to DNS > Zones.
-
Click the name of the zone containing the relevant DNS record, and then click the name of the record to drill into record details.
-
Click the menu icon next to the relevant DNS answer and select Edit answer metadata.
-
In the Answer metadata & feeds modal, click select the Up/down setting. By default, you are presented with a manual option to change the status of the endpoint, but you can ignore this.
-
Click the "Feed" icon
next to the Up/down setting to view a list of available monitors and third-party data feeds that can be connected to this answer.
-
Select the desired monitor from the list.
-
Click Ok. Now, a label appears under the relevant answer indicating the "up" setting is now connected to the DNS answer.
-
Click Save record to save these changes.
Repeat this process to connect monitors or data sources to all DNS answers in the record. Then, you can Create a Filter Chain that includes the Up filter so that unavailable answers are eliminated from the answer pool before NS1 responds to the requesting client.