- 필수 기능
- 시작하기
- Glossary
- 표준 속성
- Guides
- Agent
- 통합
- 개방형텔레메트리
- 개발자
- API
- Datadog Mobile App
- CoScreen
- Cloudcraft
- 앱 내
- 서비스 관리
- 인프라스트럭처
- 애플리케이션 성능
- APM
- Continuous Profiler
- 스팬 시각화
- 데이터 스트림 모니터링
- 데이터 작업 모니터링
- 디지털 경험
- 소프트웨어 제공
- 보안
- AI Observability
- 로그 관리
- 관리
Time Slice SLOs allow you to measure reliability using a custom definition of uptime. You define uptime as a condition over a metric timeseries. For example, you can create a latency SLO by defining uptime as whenever p95 latency is less than 1 second.
Time Slice SLOs are a convenient alternative to Monitor-based SLOs. You can create an uptime SLO without going through a monitor, so you don’t have to create and maintain both a monitor and an SLO.
You can create a Time Slice SLO through the following ways:
Create a Time Slice SLO by exporting an existing Monitor-based SLO. From a monitor SLO, click Export to Time Slice SLO.
From the Create or Edit SLO page, under Define your SLI, click Import from Monitor and select from the dropdown or search in the monitor selector.
Note: Time Slice SLOs do not support rolling periods. Rolling periods do not transfer from a monitor query to a Time Slice query.
To calculate the uptime percentage for a Time Slice SLOs, Datadog cuts the timeseries into equal-duration intervals, called “slices”. The length of the interval configurable with options of 1 or 5 minutes:
The space and time aggregation are determined by the metric query. For more information on time and space aggregation, see the metrics documentation.
For each slice, there is a single value for the timeseries, and the uptime condition (such as value < 1
) is evaluated for each slice. If the condition is met, the slice is considered uptime:
Otherwise, it is considered downtime:
In the example below, there is a Time Slice SLO configured with 5-minute time slices, and exactly one point in the timeseries violates the uptime condition. In this case, the condition is that the p95 latency is less than or equal to 2.5 seconds. Since the total time period shown is 12 hours (720 minutes), and 715 minutes are considered uptime (720 min total time - 5 min downtime), the uptime percentage is 715/720 * 100 = 99.305%
Time Slice SLOs allow you to track uptime for individual groups, where groups are defined in the “group by” portion of the metric query.
When groups are present, uptime is calculated for each individual group. However, overall uptime works differently. In order to match existing monitor SLO functionality, Time Slice SLOs use the same definition of overall uptime. When all groups have uptime, it is considered overall uptime. Conversely, if any group has downtime, it is considered overall downtime. Overall uptime is always less than the uptime for any individual group.
In the example above, environment “prod” has 5 minutes of downtime over a 12 hour (720 minute) period, resulting in approximately 715/720 * 100 = 99.305% of uptime. Environment “dev” also had 5 minutes of downtime, resulting in the same uptime. This means that overall downtime–when either datacenter prod or dev had downtime–was 10 minutes (since there is no overlap), resulting in approximately (720-10)/720 * 100 = 98.611% uptime.
Time Slice SLOs count correction periods as uptime in all calculations. Since the total time remains constant, the error budget is always a fixed amount of time as well. This is a significant simplification and improvement over how corrections are handled for monitor-based SLOs.
For monitor-based SLOs, corrections are periods that are removed from the calculation. If a one-day-long correction is added to a 7-day SLO, 1 hour of downtime counts as 0.7% instead of 0.6%:
$$ 60/8640 *100 = ~0.7% $$
The effects on error budget can be unusual. Removing time from an uptime SLO causes time dilation, where each minute of downtime represents a larger fraction of the total time.
In Time Slice SLOs, missing data is always treated as uptime. While missing data is treated as uptime, it is gray on the timeline visualization.