Dynatrace offers a set of out-of-the-box SLOs for some of the primary monitoring domains that you can configure either in the SLO wizard or in the global SLO settings.
For a better understanding of the SLIs needed for these service-level objectives, see the configuration examples below.
Service-level availability objective
The fundamental service-level availability is measured by dividing the number of successful service calls (
builtin:service.errors.server.successCount ) by the total number of service calls (
Example configuration with a filter on a service called ‘couchDb’:
You can also filter for
keyRequest to have specific endpoints in the SLO instead of a whole service with all of its endpoints.
Service-method availability is measured by dividing the number of successful key request service calls (
builtin:service.keyRequest.errors.server.successCount) by the total number of key request service calls (
builtin:service.keyRequest.count.server). It uses the
type("SERVICE_METHOD") AND entityId("SERVICE_METHOD-XXX") SLO filter.
User experience objective
Dynatrace offers expertise in terms of measuring the real user experience of delivered services. Dynatrace metrics such as the Apdex (Application Performance Index) or the User experience score can be used within an SLO definition.
Apdex defines a performance standard to divide your application users into three groups: SATISFIED, TOLERATING, and FRUSTRATED. For example, as an SLO goal for your application, you can specify that you want to have 90% of all your users within the SATISFIED category.
This SLO is calculated by dividing the number of users that are in the SATISFIED category (
builtin:apps.web.actionCount.category:filter(eq(Apdex category,SATISFIED)):splitBy()) by the total number of users that are using a web or mobile application (
Example configuration of an SLO defined for a given web application called 'easyTravel':
Mobile crash-free users objective
One of the most important metrics for measuring the availability and reliability of your mobile app (iOS and Android) deployment is the percentage of
Crash free user rate. Therefore, the built-in metric used is
builtin:apps.other.crashFreeUsersRate.os. This metric measures the percentage of users that open and use a mobile application without experiencing a crash.
Example configuration with a filter set to a selected mobile app called ‘myapp’:
Synthetic availability objective
A synthetic availability SLO represents the percentage of time a synthetic test was in available state or, alternatively, the percentage of successful tests to the number of total tests executed.
To define the time-based synthetic objective, the built-in metric used is
Optionally, to define the time-based availability that excludes maintenance windows, the built-in metric used is
Example configuration with a filter set to a selected synthetic test called ‘my synth test’:
Service performance objective
A service performance SLO represents the percentage of "fast" service calls from the total number of service calls, where "fast" is defined with a custom condition.
This example shows how to define a service custom metric that counts the fast service calls, and how to define your SLO based on that custom metric in Dynatrace.
- Go to any of your service pages, review its typical performance in milliseconds, and then navigate to the multidimensional analysis page.
- On the multidimensional analysis page, select Request count metric and define a condition on any of the service-call properties. In this example, we define a condition on the response time, which should be below 1,300 milliseconds to count as a fast call for this selected service.
- After you've decided on a certain condition, select Create metric. Define your own unique metric identifier for that metric to use this metric for charting, alerting, and your SLO.
For example, a newly created metric
fastcreditcardrequests results in a unique metric ID
- You can chart the total number of service requests for that service in comparison with your fast service requests.
- You can use both metrics within your SLO configuration.
Note: Check the entity-level filter on your selected service (
CreditCardValidation) or you will get the total request
count for all your services.
- The result is the final SLO status shown in the list of SLOs.
A service-method performance SLO represents the percentage of all service calls that are "fast" service-method calls, where "fast" is defined with a custom condition.
Example configuration with a filter for
<YOUR custom success metrics/filter service, endpoint, availability, and latency> /
For additional insights into SLO, check our Dynatrace University tutorial: