GitLab 애플리케이션 서비스 수준 지표 (SLI)
루비 코드베이스에서 서비스 수준 지표 (SLIs)를 직접 정의할 수 있습니다. 이를 통해 작업의 정의와 성공 여부를 구현과 가깝게 유지하고 기능을 구축하는 사람들이 이러한 기능이 어떻게 모니터링되어야 하는지 쉽게 정의할 수 있습니다.
기존 SLIs
rails_requestglobal_search_apdexglobal_search_error_rateglobal_search_indexing_apdexsidekiq_execution
새 SLI 정의
SLI는 Gitlab::Metrics::Sli::Apdex 또는 Gitlab::Metrics::Sli::ErrorRate 클래스로 정의할 수 있습니다. SLI를 정의하면 두 개의 Prometheus 카운터가 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에 대한 메트릭을 생성하는 경우 메트릭 카탈로그에서 이를 사용하여 경보가 생성되어야 하며, stage 그룹들의 오류 예산에 포함되어야 합니다.
먼저, Application-SLI library에 새 SLI를 추가하세요. 그 후 다음 정보를 추가하세요:
-
name: 코드에서 정의된 SLI의 이름. 예를 들어received_email. -
significantLabels: 메트릭에 속하는 Prometheus 레이블의 배열. 예:["email_type"]. SLI의 중요 레이블에feature_category가 포함되어 있으면 메트릭은 또한 오류 예산에 피드됩니다. -
featureCategory: SLI가 단일 기능 범주에 적용되는 경우, 이 필드를 통해 정적으로 지정할 수 있습니다. 이를 통해 stage 그룹들의 오류 예산에 SLI가 피드됩니다. -
description: SLI에 대한 Markdown 문자열로 설명합니다. 대시보드와 경보에 표시됩니다. -
kind: 지표의 종류. 예를 들어sliDefinition.apdexKind.
작업이 완료되면 make generate를 실행하여 새 SLI에 대한 레코딩 규칙을 생성하세요. 이 명령은 모든 메트릭 카운터를 포함하도록 부가려 significantLabels를 집계합니다.
이러한 변경 사항이 포함된 merge request를 열고 Scalability team 구성원의 리뷰를 요청하세요.
이러한 변경 사항이 병합되고 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는 지정된 Slack 채널에서 SLI에 대한 경보를 이미 수신할 수 있습니다. 자세한 내용은 경보 라우팅 문서를 참조하세요. 이 프로젝트에서는 기능 카테고리 레이블이있는 SLI에 대한 경보도 라우팅할 수 있도록 확장하고 있습니다.
질문이 있으면 주저하지 말고 Scalability 이슈 트래커에 이슈를 생성하거나 Slack의 #g_scalability에서 찾아주세요.
도움말