Skip to main content

Synthetic Monitoring

Synthetic monitoring allows you to proactively monitor the availability and performance of your services by running automated checks from multiple locations. Unlike traditional monitoring that relies on metrics from your infrastructure, synthetic monitoring tests your services from the outside, simulating real user interactions.

Synthetic Monitors List

Supported Check Types​

Oodle supports several types of synthetic checks:

Check TypeDescription
HTTPMonitor web endpoints for availability, response time, and status codes
DNSVerify DNS resolution and response times
TCPTest TCP connectivity to hosts and ports
SSL CertificateMonitor SSL/TLS certificate expiration and validity
PingCheck host availability using ICMP ping
TracerouteAnalyze network paths and identify routing issues

Creating a Synthetic Monitor​

  1. Navigate to Synthetic Monitors in the sidebar
  2. Click the Create Monitor button (or the + button)
  3. Configure your monitor:
Create Synthetic Monitor

Step 1: Basic Configuration​

  • Name: Enter a descriptive name for your monitor
  • Description: (Optional) Add details about what this monitor checks
  • Request Type: Select the type of check (HTTP, DNS, TCP, etc.)
  • Check Interval: How often the check runs (e.g., 5 minutes)
  • Timeout: Maximum time to wait for a response (e.g., 30 seconds)

Step 2: Request Configuration​

The configuration options vary based on the check type:

HTTP Checks​

  • URL: The endpoint to monitor
  • Method: HTTP method (GET, POST, PUT, DELETE, etc.)
  • Advanced Options:
    • Custom headers
    • Request body
    • Authentication
    • Expected status codes
    • Response validation

SSL Certificate Checks​

  • Hostname: Domain to check certificate for
  • Port: HTTPS port (default: 443)
  • Expiration Warning: Days before expiration to alert

DNS Checks​

  • Hostname: Domain name to resolve
  • Record Type: DNS record type (A, AAAA, CNAME, MX, etc.)
  • Expected Values: (Optional) Validate DNS responses

TCP Checks​

  • Host: Target hostname or IP
  • Port: TCP port to connect to

Ping Checks​

  • Host: Target hostname or IP to ping

Step 3: Alerting Configuration​

Configure how you want to be notified when checks fail:

  • Notification Policy: Select which notification policy to use for routing alerts to your configured notifiers (Slack, PagerDuty, etc.)
  • Labels: Add metadata labels for filtering and organization

Oodle automatically handles alert generation when checks fail - you just need to configure where notifications should be sent.

Step 4: Preview and Save​

Use the Run Check button to test your configuration before saving. This runs an immediate check and shows you the results.

Edit Synthetic Monitor

Click Save to create the monitor.

Viewing Monitor Status​

Synthetic Monitors List

The synthetic monitors list shows:

  • Name: Monitor name with a link to details
  • Type: The check type (HTTP, DNS, SSL, etc.)
  • Status: Current status (Healthy, Failing, No Data)
  • Uptime (24H): Visual representation of uptime over the last 24 hours
  • Duration: Average response time
  • Enabled: Toggle to enable/disable the monitor

Filtering Monitors​

Use the sidebar filters to find specific monitors:

  • Filter by check type (HTTP, DNS, TCP, etc.)
  • Filter by status (Healthy, Failing, No Data)
  • Filter by enabled/disabled state
  • Filter by location

Monitor Details​

Click on any monitor row to open the details drawer, which provides comprehensive information about the monitor without leaving the list view.

Edit Synthetic Monitor

The header displays:

  • Monitor Name and description
  • Status Badges: Enabled/Disabled, Alert status, Current state (Passing/Failing)

Overview Section​

A grid of key metrics including:

  • Type: The check type (HTTP, DNS, SSL, etc.)
  • Target: The URL, hostname, or endpoint being monitored
  • Check Interval: How often the check runs
  • Current Status: Passing or Failing
  • Uptime (24h): Success rate percentage over the last 24 hours
  • Checks (24h): Total number of checks in the last 24 hours
  • Avg Duration: Average response time
  • Alert Status: Whether an alert is currently firing

Check History​

An interactive timeline chart showing check results over time:

  • Green bars indicate successful checks
  • Red bars indicate failed checks
  • Click on a bar to zoom into that time period and see detailed events
  • Adjust the time range using the time picker

Check Events​

A paginated table of individual check executions:

  • Time: When the check ran
  • Status: Pass or Fail badge
  • Duration: Response time in milliseconds
  • Message: Error message for failed checks

You can filter events by status (All, Pass, Fail) and click on any row to see full details including response headers, body, and complete error information.

Actions​

Click the Edit button to open the monitor editor and modify settings.

Private Endpoint Monitoring​

Synthetic Monitors with Agents

By default, synthetic checks run from Oodle's cloud infrastructure and can only reach publicly accessible endpoints. To monitor services inside your private network (e.g. internal APIs, VPC-only hosts, on-prem servers), you can route checks through an Oodle Agent.

How It Works​

  1. Create and deploy an agent inside the network where your private endpoints live
  2. When creating or editing a synthetic monitor, select the agent from the Agent dropdown
  3. Oodle sends the check request to the agent, which executes it locally and returns the result

All check types are supported through agents: HTTP, DNS, TCP, SSL Certificate, Ping, and Traceroute.

Example: Monitoring an Internal API​

To monitor http://api.internal:8080/health that is only reachable from within your Kubernetes cluster:

  1. Deploy an agent named prod-cluster into that cluster (instructions)
  2. Create a new synthetic monitor:
    • Request Type: HTTP
    • URL: http://api.internal:8080/health
    • Agent: prod-cluster
    • Check Interval: 5 minutes
  3. Configure alerting as usual

The check runs from the agent pod inside the cluster, so it can resolve internal DNS names and reach private IPs.

Considerations​

  • The agent must be ACTIVE (connected) for checks to execute. If the agent disconnects, checks routed through it will fail.
  • Check latency includes the round-trip through the WebSocket tunnel. For latency-sensitive thresholds, account for a few milliseconds of overhead.
  • You can use separate agents for different environments (e.g. prod-vpc, staging-vpc) to isolate monitoring.

Best Practices​

Choose Appropriate Intervals​

  • Critical services: 1-5 minute intervals
  • Standard services: 5-15 minute intervals
  • Low-priority services: 15-60 minute intervals

Set Meaningful Timeouts​

Configure timeouts based on expected response times:

  • Fast APIs: 5-10 seconds
  • Web pages: 15-30 seconds
  • Complex operations: 30-60 seconds

Use Multiple Check Types​

Combine different check types for comprehensive monitoring:

  • HTTP checks for API availability
  • SSL certificate checks for expiration warnings
  • DNS checks for resolution verification

Support​

If you have any questions or need assistance, please contact us via our help chat app available on the Support link in the sidebar, or by reaching out to support@oodle.ai.