SLO 생성¶
새 SLO를 생성하면 서비스에 대한 측정 방식, 평가 주기, 목표를 선택할 수 있고, 달성률이 낮아질 때 알림을 받을 수 있습니다. 생성 전에 SLO 구성 관리 권한이 있어야 합니다. 모니터 유형을 선택하는 경우 먼저 해당 모니터를 생성하고, 메트릭 유형을 선택하는 경우 먼저 업무 수량 메트릭을 현재 워크스페이스에 수집해야 합니다.
모니터링 > SLO로 이동하여 SLO 생성을 클릭합니다.
SLO 구성¶
- SLI 유형을 선택합니다. 모니터 유형은 SLI 모니터 연결, 메트릭 유형은 총계 및 성공 수 쿼리 구성을 수행합니다.
- 평가 주기, 탐지 빈도, 달성률의 목표 및 최소 목표를 설정합니다.
- 필요에 따라 태그를 추가하고 알림 정책을 연결한 뒤 저장합니다.
평가 주기 및 탐지 빈도¶
평가 주기는 각 평가가 다루는 시간 범위를 결정하며 최근 7일 또는 30일을 지원합니다. 탐지 빈도는 SLO가 재계산되고 탐지되는 간격을 결정하며 5분 또는 10분을 지원합니다. 예를 들어 30일과 5분을 선택하면 5분마다 지난 30일간의 서비스 성과를 평가합니다. 소스 모니터는 각자의 탐지 빈도에 따라 계속 실행됩니다.
달성률: 목표 및 최소 목표¶
목표와 최소 목표는 동일한 실제 달성률에 대해 설정하는 두 개의 임계값이며, 동일한 평가 주기를 사용합니다.
- 목표: 서비스가 달성해야 하는 신뢰성 수준입니다. 예를 들어 목표가 99.9%인 경우 모니터 유형은 정상 가동 시간 비율이 99.9%에 도달해야 하고, 메트릭 유형은 총계 대비 성공 수 비율이 99.9%에 도달해야 합니다. 모니터 유형의 초기 오류 예산도 이 목표를 기준으로 계산됩니다.
- 최소 목표: 서비스가 허용하는 달성률 하한입니다. 이 하한보다 낮으면 긴급 이벤트가 생성되며, 더 심각한 서비스 품질 저하를 식별하는 데 사용됩니다.
구성은 0 < 최소 목표 < 목표 < 100 조건을 충족해야 합니다. 예를 들어 목표가 99.9%, 최소 목표가 99.5%인 경우:
| 실제 달성률 | 탐지 결과 |
|---|---|
| ≥ 99.9% | 목표에 도달했습니다. |
| ≥ 99.5% 및 < 99.9% | 경고 이벤트가 생성됩니다. |
| < 99.5% | 긴급 이벤트가 생성됩니다. |
SLO는 자체 달성률에 따라 이벤트를 생성합니다. 알림을 보내야 하는 경우 알림 정책을 연결하고, 정책에서 해당 이벤트 등급의 알림 대상을 구성합니다. 알림 시간, 반복 알림 등의 동작은 정책에 따라 수행됩니다.
이름, SLI 유형, 목표, 최소 목표는 저장 후 고정됩니다. 나머지 구성의 편집 방법은 SLO 관리를 참조합니다.
태그¶
페이지 왼쪽 상단에서 태그 추가를 통해 전역 태그를 연결하면 업무, 팀 등으로 SLO를 분류하고 필터링할 수 있습니다. 이러한 태그는 해당 SLO에서 이후 생성되는 탐지 이벤트의 df_label 필드에 기록되며, 이벤트 필터링 및 데이터 연동에 사용할 수 있습니다.
태그는 SLO 및 해당 이벤트를 식별하는 데 사용됩니다. 아래의 그룹 차원은 소스 모니터 이벤트의 필드 값에 따라 달성률을 각각 계산하는 데 사용됩니다.
모니터 유형: SLI 연결¶
SLI(서비스 수준 지표)는 서비스 품질을 측정하는 지표입니다. 모니터 유형에서 SLI 구성 항목에는 기존 모니터 하나 이상을 선택하며, 시스템은 이러한 모니터에 해당하는 정상 가동 시간 비율로 서비스 품질을 측정합니다.
동일한 평가 대상을 대표할 수 있는 모니터를 선택해야 합니다. 예를 들어 결제 서비스를 평가할 때 “결제 인터페이스 응답 지연”과 “결제 요청 오류율 과다” 두 모니터를 연결할 수 있습니다. 어떤 모니터에서든 이상이 발생하면 해당 이상 시간대가 SLO에 집계됩니다. 같은 시간대의 여러 이상은 합산하여 계산됩니다. 감점, 달성률, 오류 예산의 관계는 모니터 유형 계산 방식을 참조합니다.
그룹 차원¶
그룹 차원은 어떤 업무 객체를 기준으로 각각 평가할지 결정합니다. project(프로젝트), env(환경), service(서비스)를 지원하며 하나 이상의 필드를 선택할 수 있습니다.
| 구성 방식 | 통계 결과 및 사용 사례 |
|---|---|
| 비워 둠 | 연결된 SLI를 하나의 전체로 간주하여 이상 시간대를 합친 뒤 하나의 달성률을 계산합니다. 전체 서비스 또는 업무의 전반적인 성과를 평가할 때 적합합니다. |
service 선택 |
서비스별로 각각 계산합니다. 예를 들어 payment-api와 order-api 각각 달성률을 가지며, 특정 서비스의 이상은 해당 서비스 결과에 집계됩니다. |
env, service 선택 |
실제 필드 값 조합에 따라 각각 계산합니다. 예를 들어 prod + payment-api, staging + payment-api와 같이 동일 서비스를 환경별로 각각 평가할 때 적합합니다. |
그룹화 전에 소스 모니터가 생성한 이상 이벤트에 선택한 필드와 해당 값이 포함되어 있는지 확인해야 합니다. 예를 들어 모니터의 탐지 차원을 통해 env, service를 전달합니다. 시스템은 이러한 필드를 기준으로 이상을 분류하며, 선택한 필드 중 하나라도 누락된 이벤트는 무시되어 통계의 완전성에 영향을 미칩니다. 정상 그룹 보완에는 애플리케이션 성능 모니터링(APM)의 최근 분산 추적 데이터가 사용되므로, 해당 업무 차원이 분산 추적과 함께 보고되어야 합니다.
SLO 상세 또는 SLO 차트에서 각 그룹 차원의 특정 값을 선택하면 해당 조합의 결과를 확인할 수 있습니다. 각 조합은 이상 시간을 독립적으로 누적합니다. 프로젝트 전체를 평가해야 하는 경우 project로만 그룹화된 SLO를 생성해야 합니다. 그룹 구성을 변경하면 다음 탐지 주기부터 적용되며, 이력 데이터는 기존 그룹대로 유지됩니다.
메트릭 유형: 총계 및 성공 수 구성¶
총계와 성공 수에 각각 쿼리를 구성합니다. 그래픽 메트릭 쿼리, DQL, PromQL을 지원합니다. 두 쿼리는 동일한 업무 범위, 측정 단위, 평가 주기를 포함해야 합니다. 성공 수는 총계 중 성공 조건을 충족하는 수량이므로 총계 > 0, 0 ≤ 성공 수 ≤ 총계 조건을 충족해야 합니다.
각 쿼리는 각 시계열을 하나의 주기 수량 값으로 집계해야 합니다. 여러 시계열이 반환되면 시스템은 해당 수량을 더합니다. 서로 다른 업무 범위를 독립적으로 평가해야 하는 경우 각각 SLO를 생성해야 합니다.
DQL 예시: 결제 요청 성공률¶
메저먼트 payment_requests에서 request_count는 각 수집 간격 동안 새로 발생한 요청 수를 기록하고, service는 서비스를, result는 요청 결과를 식별한다고 가정합니다. payment-api의 요청 성공률을 평가하려면 다음과 같이 구성할 수 있습니다.
총계:
성공 수:
메저먼트, 필드, 태그를 실제 수집 내용으로 교체합니다. 시간 범위는 SLO의 평가 주기에 따라 제어됩니다. 최근 30일간 총계가 100,000이고 성공 수가 99,950이면 달성률은 99,950 ÷ 100,000 × 100% = 99.95%입니다.
PromQL 예시: 누적 카운터¶
PromQL은 즉시 쿼리 방식으로 실행되므로 표현식 안에서 주기 통계를 수행해야 합니다. 예를 들어 payment_requests_total이 요청 수를 계속 누적한다고 할 때, 평가 주기가 30일이면 increase를 사용해 해당 주기의 증가량을 계산할 수 있습니다.
총계:
성공 수:
메트릭 이름과 태그를 실제 수집 내용으로 교체합니다. 평가 주기를 변경할 때 두 표현식의 시간 범위도 함께 조정합니다. 예를 들어 [30d]를 [7d]로 변경합니다.
총계와 성공 수에는 주기 내의 업무 수량을 사용해야 합니다. 소요 시간, 백분위수, 이미 계산된 성공률은 다른 탐지 방식에 적합합니다.
생성 후에는 탐지가 유효한 결과를 생성할 때까지 기다려야 합니다. 데이터 없음, 총계 0, 쿼리 실패가 발생하면 SLO 상세의 설명에 따라 데이터를 확인할 수 있습니다.