Real time Availability Monitoring

Temperstack offer Realtime availability monitoring (ping monitoring) along with response time trends This can be used to raise alerts on API end point availability.

Features of Temperstack Availability Monitoring

Endpoint Monitoring

Temperstack availability monitoring allows you to set up ping monitoring for various endpoints. This helps you keep track of your services' availability and performance.

Headers and Parameters

You can customize the requests used for ping monitoring by modifying headers and parameters. A key point to note is that the default User-Agent in headers is "TempetstackPing", but this can be changed in the headers section if needed.

Authentication

Authentication is an optional feature that allows you to modify requests with authentication payloads. This authentication information will be added to the request header, and will be overridden if the request header already contains an authentication payload. Temperstack Synthetics supports several authentication methods:

1. Basic Authentication

2. Bearer Token Authentication

3. API Token Authentication

4. JWT Authentication (dynamic)

For static authentication methods (Basic, Bearer Token, API Token), the provided values are used consistently for each ping monitor request. JWT authentication is unique in that it dynamically generates a JSON Web Token for each request, incorporating user-provided details along with standard claims like "iat" (issued at), "exp" (expiration), and "nbf" (not before).

Adding a New Endpoint

To add a new endpoint for monitoring, follow these steps:

1. Log in to the Temperstack dashboard

1. Navigate to Resources - Temperstack Synthetics

1. Click on "Add New"

1. Enter the Endpoint name

1. Select the request method from the dropdown menu:

   • GET: Retrieve data

   • POST: Submit data to be processed

   • PUT: Update existing resource

   • DELETE: Remove a resource

   • PATCH: Partially modify a resource

   • HEAD: Similar to GET but retrieves headers only

   • OPTIONS: Describe communication options for the target resource

1. Map the endpoint to a service

1. Enter the Endpoint URL

1. Specify the expected response code

1. Set the check interval in minutes

1. Define the request timeout in seconds

1. Choose the authentication method from the dropdown

1. Add request parameters (key-value pairs)

1. Add request headers (key-value pairs)

1. Specify any required response body text/JSON

User interface for specifying the expected response body in JSON format.

There are three available methods for checking the results of the response body of a request:

• Complete JSON Match

• Partial JSON Match

• Regex Match

To explain the following examples, let’s consider a sample endpoint that returns the following JSON upon execution:

{
  "api_version": "v22.02",
  "runtime": 123.456,
  "latest_run": {
    "state": "FAIL",
    "timestamp": 1738059006,
    "invoked_by_system": true
  }
}

Complete JSON Match

In this method, the response body of the ping request is compared directly with the provided input JSON. For the ping to be considered successful, the response must match exactly.

If the response body field is left blank, the request is automatically considered successful, and no response body matching is performed.

Enter the complete JSON response here to validate exact matches.

Partial JSON Match

This method allows partial matching of the response body. It looks for exact matches of primitive types (numbers, booleans, strings, null) and recursively checks objects and lists in the JSON structure.

Let’s assume you want to validate the sample endpoint but ignore dynamically generated fields that are not relevant to the status of the endpoint, such as "runtime" or "timestamp".

Use this section to enter the specific fields you want to validate.

Since the "state" in "latest_run" from the response (FAIL) does not match the expected input (SUCCESS), this ping will be marked as a failure.

Regex Match

This method provides the most flexibility by parsing the response body using Python's re regex engine. The regex pattern determines whether the response is considered successful.

For example, suppose the "state" field in "latest_run" can have multiple valid values, such as ["INITIALIZING", "RUNNING", "SUCCESS", "FAIL"]. To allow all acceptable states except "FAIL"

Specify Regex patterns that will be validated using request JSON

This regex pattern allows the monitoring system to accept responses where the "state" is "INITIALIZING", "RUNNING", or "SUCCESS". If the "state" is "FAIL", the ping will be marked as a failure.

You can also use the Test Regex button to validate your regex before submitting it, along with a sample input. Note: The sample input is not stored.

1. Request Body for HTTP Methods

When using POST, PUT, or PATCH HTTP methods, you can include a request body with your request. The request body allows you to send additional data as part of your HTTP request.

Request Body Configuration Interface taken as a JSON

1. Alarm Settings

   Alarm on Y Failures out of X checks: This setting specifies the number of failed checks (out of a total of 5 checks) required to trigger the alarm. For example, the alarm will be triggered if there are 3 failures out of the last 5 checks. It also determines the total number of checks considered for the alarm trigger condition.

The explanation provided an example - if the setting is '2/3', it means the alarm will be raised only when at least 2 pings were down in the last 3 checks.

This allows the user to configure the alarm settings more flexibly, rather than simply triggering an alarm on the first failure. It helps to avoid false alarms caused by temporary or intermittent failures, and only raise the alarm when there is a more sustained issue with the monitored endpoint.

The goal is to strike a balance between detecting real problems early, while avoiding unnecessary alerts for transient failures that may not require immediate intervention.

1. Click "Save Changes"

Managing Endpoints

• To disable an endpoint temporarily, click the toggle button under "Actions" for the desired endpoint and turn off the toggle.

• Bulk service mapping is available by selecting multiple endpoints and clicking the "Map to Service" button in the top right corner.

• Response Time by Endpoint

  • Line graph showing response times for different service endpoints over time.

  • Includes options to view historical data (e.g., last 3 hours , 6 hours, 24 hours, 3 days, 7 days, 30 days).

  • Displays key statistics like uptime percentage and average response time.