With the release of the Service-Level Objectives, Dynatrace has improved how you can establish and ensure your business-critical service-level objectives (SLOs) by allowing you to define tailored service-level indicators (SLIs) that reflect the essential SLIs using all available data points.
Dynatrace offers two Service-Level Objectives application types:
Service-Level Objectives is our latest, Grail-powered application offering enhanced flexibility and customization options.
Service-Level Objectives Classic is the previous application with limited capabilities.
The Service-Level Objectives is integrated with Dynatrace and Grail, providing capabilities for using all data types.
We strongly recommend upgrading your Classic SLOs from Service-Level Objectives Classic to Service-Level Objectives to maximize SLO capabilities and ensure you can use the latest SLO enhancements.
Below is an examples of the new SLO in Dashboards.
Below are a couple of examples of an SLO in Service-Level Objectives.
The table below highlights the new functionality and shows the many reasons you should upgrade. It compares the capabilities of SLOs in Service-Level Objectives Classic and Service-Level Objectives.
The main difference between the SLO and the Classic SLO is that the SLI in the SLO is represented as a single DQL query. The DQL query allows extensive customization possibilities, unlike metric and entity selectors in the Classic SLO.
Using a DQL query allows you to set the SLI to match the indicator, such as
An SLO typically shows specific characteristics you can configure in many possible ways.
The core SLO components are:
Set the following parameters to calculate the values above.
In Service-Level Objectives, the SLI is represented as a DQL (Dynatrace Query Language) query.
It's flexible and uses contextual data to represent the objectives.
Below is an example of a Classic SLO using the classic metric selectors, similar to a DQL query.
An SLO has two major parts: the Custom DQL and the Preview. In Custom DQL you can define your DQL query. In Preview you visualize the SLO.
The SLO DQL query is structured in a certain way to define the SLO and SLI. The SLO DQL example snippet defined in the Critical services or entities tab of the SLO has the following characteristics:
Define the data points.
timeseries {total=sum(dt.service.request.count), failures=sum(dt.service.request.failure_count)},
Specify the entity scope.
by: { dt.entity.service }
Display the information needed by using DQL filters.
| fieldsAdd name = entityName(dt.entity.service)| filter in(name, "astroshop-checkoutservice", "astroshop-cartservice", "astroshop-paymentservice", "astroshop-shippingservice", "astroshop-currencyservice", "astroshop-frontend", "astroshop-recommendationservice")
Calculate the SLI.
| fieldsAdd sli = (((total[] - failures[]) / total[]) * 100)| fields timeframe, interval, dt.entity.service, name, sli
Check in Preview the SLO and SLI statuses.
To upgrade a Classic SLO to SLO
Check your Classic SLO metric expression and identify the representation in Grail. There are different ways in which Dynatrace supports you in finding the related metrics in Grail.
Based on the complexity of the metric expression, you might need to adapt the DQL converter manually.
Upgrade the entity selector to the corresponding DQL statement. For more information, see DQL Best practices.
The following table shows the typical entity selectors for Classic SLOs and their equivalent in DQL.
Entity selector classic
DQL representation
type("SERVICE")
by: {dt.entity.service}
tag("myTag")
| fieldsAdd tags=entityAttr(dt.entity.service, "tags")| filter in(tags, "myTag")
entityId("SERVICE-XY")
| filter in(dt.entity.service, "SERVICE-XY")
entityName.contains/equals/in/startsWith("ENTITY-NAME")
| fieldsAdd name = entityName(dt.entity.service)| filter in/contains/startsWith/endsWith(name, "ENTITY-NAME")
mzId / mzName
Use Segments.
Segments aren’t related to permissions/access control.
ToRelationship / fromRelationship
See the relationship mapping table in Grail: Query monitored entities in Grail.
If you use management zones for permissions and access control, see Grant access to entities with security context.
Improve the SLI.
Although you could upgrade most Classic SLOs, a one-to-one match in Grail, consider enhancing your SLI definition with options not available with classic metric expressions.
Some of your options:
To efficiently manage and run SLOs at scale, use Dynatrace Configuration as Code.
The SLOs come with a dedicated SLO Service Public API supporting selected endpoints for managing and evaluating the latest SLOs.
To access the SLO Service Public API on your tenant
API
. In the search results, see Support resources section and Dynatrace API below it.Dynatrace Configuration as Code via Terraform supports the new SLO API with version 1.78.0.
The latest version of the Dynatrace Terraform provider can be found dynatrace-oss/dynatrace | Terraform Registry
.
Additionally, Dynatrace Configuration as Code via Monaco, supports the new SLO API since v2.22.
While we're investigating an automated upgrade flow, the highly customized nature of SLOs means a manual review process delivers the best results. We recommend using this upgrade opportunity to reassess and improve your SLIs rather than just setting them up as one-to-one copies.
Contact your Dynatrace support team to guide you through optimizing your service-level objectives for maximum business impact.