Temperstack Synthetics

Synthetics refers to synthetic monitoring, which is a proactive way to monitor the performance and availability of applications, websites, or APIs by simulating user interactions. Unlike traditional monitoring (which relies on real users interacting with the system), synthetics involve creating artificial requests or transactions that test key functionalities without waiting for real users to encounter issues.

Key Components of Synthetic Monitoring

1. Simulated User Behavior: Synthetic monitors emulate typical user actions such as loading a webpage, logging in, searching, or making a transaction. This helps ensure that key functionalities of the system are working correctly.

2. Scheduled Monitoring: These tests can be run at regular intervals from different global locations to check for uptime, performance issues, or problems with specific features.

3. Different Types of Synthetic Monitoring: - Ping Monitoring: Simple availability checks (like what we discussed earlier). - API Monitoring: Sends requests to APIs and checks their response times and data to ensure they’re functioning. - Transaction Monitoring: Simulates a multi-step user interaction (e.g., logging in, adding an item to a cart, checking out). - Browser Monitoring: Uses full browser simulations to test how long pages take to load, including all assets like CSS, JavaScript, and images.

4. Performance Metrics: Synthetic monitoring tracks various performance metrics such as: - Response time (how long it takes for the system to respond), - Page load time, - Availability, and - Error rates (how often requests fail or return errors).

Use Cases

• Availability checks: Ensure that your application is available 24/7, even during off-peak times.

• Performance benchmarking: Identify slow-loading pages or endpoints before they impact real users.

• Testing changes: Before deploying new features or updates, synthetic monitoring can simulate interactions to detect possible issues.

Features of Temperstack Synthetics

Endpoint Monitoring

Temperstack Synthetics 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

1. Alarm Settings

   1. Alarm on: This setting determines whether the alarm is enabled or not. If set to 'Y' (Yes), the alarm will be triggered when the conditions are met.

   2. Failures out of: This setting specifies the number of failed checks (out of a given number of checks) that will trigger the alarm.

   For example, if this is set to 'X', it means the alarm will be triggered if there are X failures out of the last X checks.

   1. Checks: This setting determines the total number of checks that will be 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.