Module synthetic 

Synthetic monitoring (DW-071, DP-10 / #238).

Built-in probes per route that measure latency and uptime, feeding results into analytics and webhooks. This is the proactive/synthetic side of SLO tracking – it pairs with DW-052 (SLO & error-budget export, M2), which derives SLO/burn-rate metrics from real traffic. Synthetic monitoring lets an SLO be tracked even on routes with little real traffic.

Design (section 6-Traffic Intelligence)

“The gateway measures the SLOs it exports.” Each route can have a synthetic probe configured: a periodic HTTP request to the route’s URL (or a custom URL) that records latency, status code, and success/failure. The results feed into the analytics store (as access records tagged as synthetic) and the event bus (for webhook delivery on probe failures).

Probe lifecycle

1. At config publish time, the probe configuration is compiled into a ProbeSpec per route.
2. A background task (ProbeScheduler) runs each probe on its configured interval via the async HTTP executor (run_probe).
3. Each probe result (ProbeResult) is:
   • Fed into ProbeRunner::process_result for state tracking.
   • Emitted as an event on state transitions (alert/recovery).
   • Recorded in the analytics store (as a synthetic access record).

Alerting

When a probe fails, an event is emitted on the event bus. If a webhook is configured for the probe_failed event kind, the webhook deliverer sends a notification. The alert fires on the first failure that crosses the threshold (edge-triggered); subsequent consecutive failures do not re-fire until the probe recovers.

Body assertions (DP-10, #238)

Probes can assert on the response body:

• body_contains: the body must contain a substring.
• body_jsonpath: a JSONPath expression that must resolve to a non-null value (simple dot-notation, e.g. $.status).

Multi-step journeys (DP-10, #238)

A probe can be a multi-step journey: a sequence of requests where each step can extract values (e.g. a session token) and pass them to subsequent steps via header templates. The journey fails if any step fails.

Probe-from header (DP-10, #238)

A probe can set the X-Dwara-Probe-From header to identify the region/agent executing the probe, enabling multi-region synthetic monitoring where agents in different geographies probe the same route and report their origin.

Structs

ProbeResult

The result of a single probe run.

ProbeRunner

A probe runner: holds probe specs and their current states, and processes results to drive edge-triggered alerting.

ProbeScheduler

A probe scheduler: spawns a background task per probe that runs the probe on its configured interval and feeds results into a ProbeRunner. State transitions (alert/recovery) are emitted as events.

ProbeSpec

A synthetic probe specification for a route.

ProbeStep

One step in a multi-step probe journey (DP-10, #238).

Enums

ProbeOutcome

The outcome of processing a probe result.

Functions

check_body_assertions

Check a response body against the probe’s body assertions. Returns Ok(()) if all assertions pass, or Err(message) on the first failure.

failure_result

Create a probe result from a failed HTTP response (or error).

run_probe

Execute a single probe spec as an HTTP request and return the result. This is the core executor: it sends the request, measures latency, checks the status code, and runs body assertions.

success_result

Create a probe result from a successful HTTP response.