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.

   Tip

   A common reason for Try now to fail is that there is a non-2xx response code. If that is expected, add a Validation for the correct response code.

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

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

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

9. 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.

10. 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. Click into a test 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, and change the interval if needed to better see trends in the data. 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.

   Tip

   We are not setting a detector on this test yet, to make sure it is running consistently and successfully. If you are testing a highly critical endpoint and want to be alerted on it ASAP (and have tolerance for potential alert noise), jump to Single Test Detectors.

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

Global Variables

Global variables allow us to use stored strings in multiple tests, so we only need to update them in one place.

View the global variable that we’ll use to perform our API test. Click on Global Variables under the cog icon. The global variable named env.encoded_auth will be the one that we’ll use to build the spotify API transaction.

Create new API test

Create a new API test by clicking on the Add new test button and select API test from the dropdown. Name the test using your team name, your initials, and Spotify API e.g. [Daisy] RWC - Spotify API

Authentication Request

Click on + Add requests and enter the request step name e.g. Authenticate with Spotify API.

Expand the Request section, from the drop-down change the request method to POST and enter the following URL:

https://accounts.spotify.com/api/token

In the Payload body section enter the following:

grant_type=client_credentials

Next, add two + Request headers with the following key/value pairings:

• CONTENT-TYPE: application/x-www-form-urlencoded
• AUTHORIZATION: Basic {{env.encoded_auth}}

Expand the Validation section and add the following extraction:

• Extract from Response body JSON $.access_token as access_token

This will parse the JSON payload that is received from the Spotify API, extract the access token and store it as a custom variable.

Search Request

Click on + Add Request to add the next step. Name the step Search for Tracks named “Up around the bend”.

Expand the Request section and change the request method to GET and enter the following URL:

https://api.spotify.com/v1/search?q=Up%20around%20the%20bend&type=track&offset=0&limit=5

Next, add two request headers with the following key/value pairings:

• CONTENT-TYPE: application/json
• AUTHORIZATION: Bearer {{custom.access_token}}
  • This uses the custom variable we created in the previous step!

Expand the Validation section and add the following extraction:

• Extract from Response body JSON $.tracks.items[0].id as track.id

To validate the test before saving, change the location as needed and click Try now. See the docs for more information on the try now feature.

When the validation is successful, click on < Return to test to return to the test configuration page. And then click Save to save the API test.

View results

Wait for a few minutes for the test to provision and run. Once you see the test has run successfully, click on the run to view the results:

Resources

• How to Create an API Test
• API Test Overview