Create SLO¶
By creating an SLO, you can select the measurement method, evaluation period, and target for a service, and receive alerts when the success rate drops. Before creating, you need the SLO Configuration Management permission. When choosing the monitor type, first create the corresponding monitor; when choosing the metric type, first collect business count metrics into the current workspace.
Go to Monitoring > SLO and click Create SLO.
Configure SLO¶
- Select the SLI type: the Monitor type associates SLI monitors; the Metric type configures total and success queries.
- Set the evaluation period, detection frequency, and the target and minimum target in Success Rate.
- Add tags and associate an Alert Policy as needed, then save.
Evaluation Period and Detection Frequency¶
The evaluation period determines the time range covered by each evaluation round, supporting the most recent 7 or 30 days; the detection frequency determines how often the SLO is recalculated and evaluated, supporting 5 or 10 minutes. For example, selecting 30 days and 5 minutes means evaluating the service performance of the previous 30 days every 5 minutes. The source monitors continue to run at their own detection frequencies.
Success Rate: Target and Minimum Target¶
Target and Minimum Target are two thresholds set for the same actual success rate and share the same evaluation period:
- Target: The reliability level you expect the service to achieve. For example, if the target is 99.9%, the monitor type requires the uptime percentage to reach 99.9%; the metric type requires the proportion of successful counts to total counts to reach 99.9%. The initial error budget for the monitor type is also calculated from this target.
- Minimum Target: The acceptable lower bound of the success rate for the service. When the rate falls below this bound, a critical event is generated to identify more severe service quality degradation.
The configuration must satisfy 0 < minimum target < target < 100. For example, if the target is 99.9% and the minimum target is 99.5%:
| Actual Success Rate | Detection Result |
|---|---|
| ≥ 99.9% | Target met. |
| ≥ 99.5% and < 99.9% | Warning event generated. |
| < 99.5% | Critical event generated. |
The SLO generates events based on its own success rate. To send notifications, associate an alert policy and configure notification targets for the corresponding event levels in the policy; behaviors such as notification time and repeated notifications are executed according to the policy.
Name, SLI type, target, and minimum target are fixed after saving. For editing instructions on other configurations, see Manage SLO.
Tags¶
At the top left of the page, use Add Tags to associate global labels, making it easier to categorize and filter SLOs by business, team, and so on. These tags are written to the df_label field of detection events subsequently generated by this SLO, and can be used for event filtering and data correlation.
Tags identify the SLO and its events; the grouping dimensions below are used to calculate success rates separately by field values in the source monitor events.
Monitor Type: Associate SLI¶
An SLI (Service Level Indicator) is a metric that measures service quality. Under the monitor type, one or more existing monitors are selected in the SLI configuration item, and the system measures service quality based on the uptime percentage corresponding to these monitors.
You should select monitors that represent the same evaluation object. For example, when evaluating a payment service, you can associate monitors such as "Payment API response too slow" and "Payment request error rate too high". When any monitor generates an anomaly, the corresponding anomalous period is counted into the SLO; multiple anomalies in the same period are merged and calculated together. For the relationship between deductions, success rate, and error budget, see Calculation instructions for monitor type.
Grouping Dimensions¶
Grouping dimensions determine which business objects are evaluated separately. The supported fields are project (project), env (environment), and service (service); you can select one or more fields.
| Configuration Method | Statistical Results and Applicable Scenarios |
|---|---|
| Leave blank | Treats the associated SLIs as a whole, merges anomalous periods, and calculates one success rate, suitable for evaluating the overall performance of the entire service or business. |
Select service |
Calculates each service separately. For example, payment-api and order-api each have their own success rate, and anomalies of a service are counted in that service's results. |
Select env, service |
Calculates by actual combinations of field values, for example prod + payment-api, staging + payment-api, suitable for evaluating the same service in different environments separately. |
Before grouping, make sure the anomaly events generated by the source monitors contain the selected fields and their values, for example, by passing env and service through the monitor's detection dimensions. The system classifies anomalies by these fields. Events missing any selected field are ignored, which affects statistical completeness. Normal grouping completion uses recent trace data from Application Performance Monitoring (APM); make sure the corresponding business dimensions have been reported with the traces.
In SLO Details or SLO Chart, select specific values for each grouping dimension to view the results of the corresponding combination. Each combination accumulates anomalous duration independently; if you need to evaluate the project as a whole, create an SLO grouped only by project. After modifying the grouping configuration, the change takes effect from the next detection cycle, and historical data remains grouped by the original configuration.
Metric Type: Configure Total and Success Count¶
Configure queries in Total and Success Count. Graphical metric queries, DQL, and PromQL are supported. The two queries must cover the same business scope, unit of measurement, and evaluation period. The success count is the number of items in the total that meet the success conditions and must satisfy total > 0 and 0 ≤ success count ≤ total.
Each query should aggregate each time series into one quantity value for the period. When multiple time series are returned, the system adds their quantities together; if you need to evaluate different business scopes independently, create separate SLOs.
DQL Example: Payment Request Success Rate¶
Assume that in the measurement payment_requests, request_count records the number of new requests within each collection interval, service identifies the service, and result identifies the request result. To evaluate the request success rate of payment-api, you can configure:
Total:
Success Count:
Replace the measurement, fields, and tags with your actual collected content. The time range is controlled by the SLO evaluation period. If the total count for the last 30 days is 100,000 and the success count is 99,950, the success rate is 99,950 ÷ 100,000 × 100% = 99.95%.
PromQL Example: Cumulative Counter¶
PromQL is executed as an instant query, so period statistics must be completed in the expression. For example, if payment_requests_total continuously accumulates the request count, you can use increase to calculate the increment within a 30-day evaluation period:
Total:
Success Count:
Replace the metric name and labels with your actual collected content. When changing the evaluation period, adjust the time range in both expressions accordingly, for example, change [30d] to [7d].
Total and success count should use business quantities within the period; latency, percentiles, and pre-calculated success rates are suitable for other detection methods.
After creation, wait for detection to generate valid results. If there is no data, the total is 0, or the query fails, check the data according to the instructions in SLO Details.