GitLab 응용 프로그램 서비스 수준 지표 (SLI)
- GitLab 14.4에서 도입됨
Ruby 코드베이스에서 직접 서비스 수준 지표(SLIs)를 정의할 수 있습니다. 이를 통해 운영의 정의를 구현과 밀접하게 유지할 수 있으며, 기능을 개발하는 사람들이 이러한 기능을 어떻게 모니터링해야 하는지 쉽게 정의할 수 있습니다.
기존 SLI
rails_requestglobal_search_apdexglobal_search_error_rateglobal_search_indexing_apdexsidekiq_execution
새 SLI 정의하기
SLI는 Gitlab::Metrics::Sli::Apdex 또는 Gitlab::Metrics::Sli::ErrorRate 클래스로 정의할 수 있습니다. SLI를 정의하면 두 개의 프로메테우스 카운터가 Rails 애플리케이션에서 생성됩니다. 두 카운터 모두 대략적으로 동일한 방식으로 작동하며 총 작업 횟수를 포함합니다. Apdex는 성공률을 사용하여 성공 비율을 계산하고, ErrorRate는 오류 비율을 사용하여 오류 비율을 계산합니다.
다음 지표가 정의됩니다:
-
Gitlab::Metrics::Sli::Apdex.new('foo')는 다음과 같이 정의됩니다:-
gitlab_sli_foo_apdex_total은 메트릭값의 총 수입니다. -
gitlab_sli_foo_apdex_success_total은 성공적인 메트릭값의 수입니다.
-
-
Gitlab::Metrics::Sli::ErrorRate.new('foo')는 다음과 같이 정의됩니다:-
gitlab_sli_foo_total은 메트릭값의 총 수입니다. -
gitlab_sli_foo_error_total은 오류 메트릭값의 수입니다. 이 지표는 오류 비율이므로 오류는 총 수로 나누어집니다.
-
이 예에서 보여진 것처럼, 이러한 지표들은 같은 작업을 참조할 때 동일한 기본 이름(foo 예시)을 공유할 수 있습니다.
성공한 작업의 성능을 메트릭하기 위해 Apdex를 사용해야 합니다. 실패한 요청의 성능을 메트릭할 필요가 없습니다. 왜냐하면 해당 성능은 ‘ErrorRate’로 추적되어야 하기 때문입니다. 예를 들어, 요청이 지정된 지연 임계값 내에서 실행되고 있는지 메트릭할 수 있습니다.
ErrorRate는 실패한 작업의 비율을 메트릭하는 데 사용해야 합니다. 예를 들어, 실패한 요청이 500 이상의 HTTP 상태를 반환하는지를 메트릭할 수 있습니다.
첫 번째 스크래핑 전에는 모든 가능한 레이블 조합으로 SLI를 초기화하는 것이 중요합니다. 이렇게 함으로써 이러한 카운터를 계산에 사용할 때 혼란스러운 결과를 피할 수 있습니다.
SLI를 초기화하려면 다음과 같이 .initialize_sli 클래스 메서드를 사용하면 됩니다.
Gitlab::Metrics::Sli::Apdex.initialize_sli(:received_email, [
{
feature_category: :team_planning,
email_type: :create_issue
},
{
feature_category: :service_desk,
email_type: :service_desk
},
{
feature_category: :code_review_workflow,
email_type: :create_merge_request
}
])
메트릭은 처음 스크래핑되기 전에 초기화되어야 합니다. 현재 이 작업은 on_master_start 라이프사이클 이벤트 동안 수행됩니다. 이는 지연된 애플리케이션 준비 상태로 돌아가는 메트릭 초기화가 반환되는 오버헤드가 이해되고 수용 가능한지 확인해야 함을 의미합니다.
SLI의 작업 추적
새로 정의된 SLI에서 작업을 추적하는 것은 다음과 같이 수행할 수 있습니다:
Gitlab::Metrics::Sli::Apdex[:received_email].increment(
labels: {
feature_category: :service_desk,
email_type: :service_desk
},
success: issue_created?
)
이 SLI에서 #increment를 호출하면 총 프로메테우스 카운터가 증가합니다.
gitlab_sli:received_email_apdex:total{ feature_category='service_desk', email_type='service_desk' }
전달된 success: 인수가 참이면 성공 카운터도 증가합니다:
gitlab_sli:received_email_apdex:success_total{ feature_category='service_desk', email_type='service_desk' }
오류율 SLI의 경우, 해당 인수는 error:로 불립니다:
Gitlab::Metrics::Sli::ErrorRate[:merge].increment(
labels: {
merge_type: :fast_forward
},
error: !merge_success?
)
SLI를 서비스 모니터링 및 경고에 사용하기
응용 프로그램이 새로운 SLI에 대한 메트릭을 생성하면, 해당 메트릭은 메트릭 카탈로그에서 소비되어 경고를 유발해야 하며, 무려 관련 기능 카테고리 및 GitLab.com의 전반적 가용성에 대한 오류 예산에 포함되어야 합니다.
먼저 새 SLI를 Application-SLI 라이브러리에 추가하십시오. 그 후 다음 정보를 추가하십시오:
-
name: 코드에서 정의된 SLI의 이름입니다. 예:received_email. -
significantLabels: 메트릭에 속하는 프로메테우스 레이블의 배열입니다. 예:["email_type"]. SLI의 중요한 레이블이feature_category를 포함하는 경우, 메트릭은 또한 단계 그룹의 오류 예산으로 전달되어야 합니다. -
featureCategory: SLI가 단일 기능 카테고리에 적용되는 경우, 이 필드를 통해 정적으로 지정할 수 있습니다. 이를 통해 SLI를 단계 그룹의 오류 예산으로 전달할 수 있습니다. -
description: SLI를 설명하는 마크다운 문자열입니다. 대시보드 및 경고에 표시됩니다. -
kind: 지표의 종류입니다. 예:sliDefinition.apdexKind.
작업이 완료되면, 새로운 SLI에 대한 녹음 규칙을 생성하기 위해 make generate를 실행하십시오. 이 명령은 모든 서비스에 대해 이러한 메트릭을 생성하여 significantLabels로 집계합니다.
이러한 변경 사항이 포함된 합병 요청을 열고 Scalability 팀 구성원으로부터 리뷰를 요청하십시오.
이러한 변경 사항이 Merge되고 Thanos에서 집계된다면 새로 집계된 메트릭의 성공 비율을 확인하기 위해 Thanos를 쿼리하십시오. 예를 들어:
sum by (environment, stage, type)(application_sli_aggregation:rails_request:apdex:success:rate_1h)
/
sum by (environment, stage, type)(application_sli_aggregation:rails_request:apdex:weight:score_1h)
이를 통해 설정해야 할 적절한 SLO를 안내받을 수 있는 성공 비율을 확인할 수 있습니다.
그런 다음 해당 SLI를 적절한 서비스 카탈로그 파일에 추가하십시오. 예: web 서비스:
rails_requests:
sliLibrary.get('rails_request_apdex')
.generateServiceLevelIndicator({ job: 'gitlab-rails' })
추가 선택기를 전달하거나 SLI의 속성을 재정의하기 위한 추가 선택기 및 오버라이드 프로퍼티를 보려면 서비스 모니터링 문서를 참조하십시오.
정적으로 정의된 기능 카테고리를 가진 SLI는 이미 지정된 슬랙 채널에서 SLI에 대한 경고를 받을 수 있습니다. 자세한 내용은 알림 라우팅 문서를 참조하십시오. 이 프로젝트에서는 소스 메트릭에 feature_category 레이블이 있는 SLI에 대한 경고도 라우팅할 수 있도록 확장하고 있습니다.
질문이 있으면 꺼림칙하게 확장성 이슈 추적기에 이슈를 생성하거나 Slack의 #g_scalability에서 찾아와 주십시오.
도움말