Creating a test

1. Open Synthetics

2. Click the Add new test button on the right side of the screen, then select Uptime and HTTP test.

3. Name your test with your team name (provided by your workshop instructor), your initials, and any other details you’d like to include, like geographic region.

4. For now let’s test a GET request. Fill in the URL field. You can use one of your own, or one of ours like https://online-boutique-eu.splunko11y.com, https://online-boutique-us.splunko11y.com, or https://www.splunk.com.

5. Click Try now to validate that the endpoint is accessible before the selected location before saving the test. Try now does not count against your subscription usage, so this is a good practice to make sure you’re not wasting real test runs on a misconfigured test.

1. Add any additional validations needed, for example: response code, response header, and response size.

2. Add and remove any locations you’d like. Keep in mind where you expect your endpoint to be available.

3. Change the frequency to test your more critical endpoints more often, up to one minute.

4. Make sure “Round-robin” is on so the test will run from one location at a time, rather than from all locations at once.

   • If an endpoint is highly critical, think about if it is worth it to have all locations tested at the same time every single minute. If you have automations built in with a webhook from a detector, or if you have strict SLAs you need to track, this could be worth it to have as much coverage as possible. But if you are doing more manual investigation, or if this is a less critical endpoint, you could be wasting test runs that are executing while an issue is being investigated.
   • Remember that your license is based on the number of test runs per month. Turning Round-robin off will multiply the number of test runs by the number of locations you have selected.

5. When you are ready for the test to start running, make sure “Active” is on, then scroll down and click Submit to save the test configuration.

Now the test will start running with your saved configuration. Take a water break, then we’ll look at the results!

Understanding results

1. From the Synthetics landing page, click into a test to see its summary view and play with the Performance KPIs chart filters to see how you can slice and dice your data. This is a good place to get started understanding trends. Later, we will see what custom charts look like, so you can tailor dashboards to the KPIs you care about most.

   Workshop Question: Using the Performance KPIs chart

   What metrics are available? Is your data consistent across time and locations? Do certain locations run slower than others? Are there any spikes or failures?

2. Click into a recent run either in the chart or in the table below.

3. If there are failures, look at the response to see if you need to add a response code assertion (302 is a common one), if there is some authorization needed, or different request headers added. Here we have information about this particular test run including if it succeeded or failed, the location, timestamp, and duration in addition to the other Uptime test metrics. Click through to see the response, request, and connection info as well. If you need to edit the test for it to run successfully, click the test name in the top left breadcrumb on this run result page, then click Edit test on the top right of the test overview page. Remember to scroll down and click Submit to save your changes after editing the test configuration.

4. In addition to the test running successfully, there are other metrics to measure the health of your endpoints. For example, Time to First Byte(TTFB) is a great indicator of performance, and you can optimize TTFB to improve end user experience.

5. Go back to the test overview page and change the Performance KPIs chart to display First Byte time. Once the test has run for a long enough time, expanding the time frame will draw the data points as lines to better see trends and anomalies, like in the example below.

In the example above, we can see that TTFB varies consistently between locations. Knowing this, we can keep location in mind when reporting on metrics. We could also improve the experience, for example by serving users in those locations an endpoint hosted closer to them, which should reduce network latency. We can also see some slight variations in the results over time, but overall we already have a good idea of our baseline for this endpoint’s KPIs. When we have a baseline, we can alert on worsening metrics as well as visualize improvements.

Once you have your Uptime test running successfully, let’s move on to the next test type.