Service level objectives (public preview)

Select Entity

Select the entity to measure for your SLO. You can define and measure performance targets for the following entity types:

• Application: Measure the performance of calls in an application perspective.
• Website: Measure the performance of beacons and traces in a website.
• Synthetic Tests: Measure the performance of the results of one or more synthetic tests.

Set Scope

Set the scope within the entity to measure.

Applications

• Select the Boundary

  • Inbound Calls: Include calls initiated from outside the application and the destination service is part of the selected application perspective.
  • All Calls: Include both inbound calls from outside the application and calls that occur within the application perspective.

• Select Hidden Calls

  • Include Internal Calls: Calls that represents work that is done inside a service. These can be created from intermediate spans that are sent through custom tracing.
  • Include Synthetic Calls: Calls with a synthetic endpoint as the destination, such as calls to health-check endpoints.

• Select Service and Endpoint

  • Service & Endpoint
  • Select a specific Service in your application or use the default of All Services to include the entire application perspective.
  • Select an Endpoint from the specified service or use the default of All Endpoints to apply to the entire service.
  • Custom
  • Specify custom filters using the available tags to define the scope of the measured calls for the application. These filters can be combined to create composite queries as needed.

Websites

• Select the Beacon to monitor:
  • Choose a beacon to monitor from: HTTP requests, Website Page Loads, or Website Custom Events.
• Select Custom Filter (optional):
  • Specify the custom events filter to further the limit the scope of the selected beacon type. These filters can be combined to create composite queries as needed.

Set Indicator

Define the Service Level Indictor (SLI) to measure for the entity.

You can select a Blueprint to define the type of Indicator, choosing from: Latency, Availability, Traffic, and Custom. The indicator is used to specify the metric and measurement type that are used to calculate the SLO status and error budget.

• Latency: Measures how quickly the calls, beacons, or test results complete respond to a specified threshold. There are two types of measurements for the Latency blueprint:
  • Time-based: The response time for all calls, beacons, or test results are aggregated into one-minute buckets. Error budget is measured in minutes and is a static value derived from the SLO target and the duration of the SLO tiime window. If the aggregated result for each minute is less than the specified threshold, it is deemed to be a a bad minute and the error budget is reduced. You can also specify the type of aggregation that is used from the following options:
  • Mean
  • Min
  • Max
  • Percentile (25, 50, 75, 90, 95, 98, 99)
  • Event-based: The response time for each call, beacon, or test result is compared to the specified threshold and determined to be a good or bad event. Error budget is measured in calls, beacons, or results and is derived from the SLO target and the total number of events during the SLO time window. Since the total number of events is changing over the duration of the SLO time window, the total error budget is a dynamic value.
• Availability: Measures the success rate of calls, beacons, or test results over the designated time period. There are two types of measurements for the Availability blueprint:
  • Time-based: The success rate for all calls, beacons, or test results are aggregated into one-minute buckets. Error budget is measured in minutes and is a static value derived from the SLO target and the duration of the SLO time window. If the aggregated result for each minute is less than the specified threshold, it is deemed to be a bad minute and the error budget is reduced. Currently only mean aggregation is supported for Availability blueprints.
  • Event-based: The overall success rate for the calls, beacons, or test results is calculated over the SLO time period. Error budget is measured in calls, beacons, or results and is derived from the SLO target and the total number of events during the SLO time window. Since the total number of events is changing over the duration of the SLO time window, the total error budget is a dynamic value.
• Traffic: Measures the load (calls, beacons, or test results) a system encounters over time. This is a time-based measurement where the number of calls or results per minute is compared to a specified threshold. If the threshold is exceeded, it is deemed to be a bad minute and the error budget is reduced. You can also specify the type of calls or results to count:
  • All calls or results: Counts all calls or tests results. This can be used to measure the overall system traffic for the specified entities.
  • Erroneous calls or results: Counts only erroneous calls or failed tests results. This can be used to focus the measurement only on erroneous traffic.
• Custom: Use custom filters to specify the definition of good and bad calls. The Custom blueprint is only available for Application and Website entity types. You can define the following filters for a Custom blueprint:
  • Good calls: Specify the filter for good calls. These filters can be combined to create composite queries as needed. If only good calls are defined, calls that do not match the good calls filter are assumed to be bad calls.
  • Bad calls: Optionally specify filters for bad calls. If the bad calls filter is defined, calls that do not match the good or bad calls filter are ignored.

Set Objective

Define the overall Service Level Objective target value and details for the SLO time window.

• SLO Target: Specify the target percentage that your entity should be meeting when it is performing correctly.

The maximum precision that is currently supported is four nines (99.99%).

• Time Window: Specify the type of time window for the SLO.
  • Fixed: A time window with a distinct start time and duration. For example, you can configure a fixed one-week window that starts on 2020-01-01. The time window will be automatically reset to the next week (2020-01-08) when the week is completed.
  • Rolling: A dynamic time window with a fixed window size, where the end is defined by the global time picker’s end date and time selection. For example, the rolling time window enables the ability to always see the last week.
• Length: Duration of the SLO time window, specified in days or weeks.

The maximum length of an SLO that is supported is 4 weeks.

• Start: For Fixed time windows, the day and time to initiate the SLO calculation.

After entering values for SLO Target and Time window, the error budget is displayed.

• For time-based blueprints, this is a true error budget in minutes as determined by the time window length and the SLO target.
• For event-based blueprints, this is an estimated error budget based on the calls or beacons encountered over the prior SLO time period, along with the specified time window length and SLO target.

Set Details

1. Specify the SLO name.
2. Optionally, specify a set of tags that can be used to categorize or sort the SLO.

Preview

A preview chart appears that represents the summary of your SLO. If no preview is displayed, click Highlight missing configuration to locate the missing information. The preview data is based on the previous seven days. In some cases, the preview shows sample data.

To create the SLO configuration, click Save.