Integrate Splunk Synthetics with Cisco ThousandEyes

Set up the Splunk ThousandEyes integration from Splunk Observability Cloud to connect a Splunk organization to one or more ThousandEyes account groups.

Create, view, and manage ThousandEyes tests from Splunk Observability. These tests monitor the application or endpoint and collect network path data from ThousandEyes, so SRE, application, and network operations teams can investigate the same test result from the same operational context.

Use the integration to answer questions such as:

  • Is this synthetic failure caused by the application, the endpoint, DNS, or the network path?

  • Is packet loss, latency, or a routing change contributing to a degraded user experience?

  • Which ThousandEyes alert or path detail should I hand off to the network team?

  • Can I alert, chart, and dashboard ThousandEyes network metrics in Splunk Observability Cloud?

Set up the integration

To set up the integration, follow the steps in Integrate Cisco ThousandEyes with Splunk Observability Cloud.

Supported test types

ThousandEyes test type Description

HTTP Server test

Monitor HTTP endpoint availability, response code, response timing, and network path health

Create a ThousandEyes test when you want ThousandEyes network insights. This test will simultaneously appear in ThousandEyes with a splunk_managed tag added to it. New ThousandEyes tests will use ThousandEyes entitlements.

HTTP server test metrics

When you create or import ThousandEyes tests, Splunk Observability Cloud ingests the following OpenTelemetry network metrics from ThousandEyes tests:
Metric Layer Description

http.server.request.availability

HTTP

0% on error, 100% otherwise

http.client.request.duration

HTTP

Time to First Byte (seconds)

http.server.throughput

HTTP

Download throughput (bytes/sec)
http.server.throughput HTTP DNS Time/Resolution (ms)

network.latency

Network

Max round-trip latency (seconds)

network.loss

Network

Packet loss (%)

network.jitter

Network

Latency variation (ms)

ThousandEyes metrics

Metric Definition

Loss

The percentage of probe packets dropped on the network path between the test agent and the destination server. If protocol on the network and app layers are the same, packet loss % can indicate slow page loads and failed API calls.

Latency

The round-trip time for data to travel from the test agent to the destination server and back. Latency represents the network's round-trip delay, which is the portion of your application's total response time spent waiting on the network rather than server processing.

DNS

The time it took to translate the destination hostname into an IP address. Slow DNS adds delay to the first step of page load. DNS failure means nothing else can proceed.

Jitter

The mean deviation of latency. The mean deviation represents how far, on average, all measurements are from the mean of the data.

Each network metric is compared to the P75 over the last 7 days, the 75th percentile of a metric aggregated across a rolling 7-day window. Comparing the latest run with this value shows whether it performed worse than most recent runs.

Example:

  • 7-day P75 packet loss: 3%

  • Current run packet loss: 4.5%

This means the current run's packet loss was higher than the packet-loss value seen in roughly 75% of runs over the last seven days. Because higher packet loss indicates worse performance, this run is performing worse than the recent baseline and may warrant investigation.

It does not necessarily mean the run failed, only that its result was unusually high relative to the past seven days.