GitLab Application Service Level Indicators (SLIs)
Ruby 코드베이스에 Service Level Indicators (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 counter가 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 life-cycle event 동안 발생합니다. 즉, 메트릭 초기화가 반환되기 전까지 애플리케이션 정상 작동이 지연되므로, 이 추가 비용이 이해되고 허용되는지 확인하십시오.
SLI의 작업 추적
새로 정의된 SLI에서 작업을 추적하는 것은 다음과 같이 수행할 수 있습니다.
Gitlab::Metrics::Sli::Apdex[:received_email].increment(
labels: {
feature_category: :service_desk,
email_type: :service_desk
},
success: issue_created?
)
이 SLI에 대해 #increment를 호출하면 총 Prometheus 카운터가 증가합니다.
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의 전반적인 가용성에 포함됩니다.
먼저 Application-SLI library에 새 SLI를 추가하십시오.
-
name: 코드에서 정의된 SLI의 이름. 예:received_email. -
significantLabels: 메트릭에 속하는 Prometheus 라벨의 배열. 예:["email_type"]. SLI의 중요 라벨에feature_category가 포함된다면 메트릭 역시 단계 그룹의 오류 예산에 공급됩니다. -
featureCategory: SLI가 단일 기능 범주에 적용되면 이 필드를 통해 해당 SLI에 대해 정적으로 지정할 수 있습니다. -
description: SLI에 대한 설명을 하는 마크다운 문자열. 대시보드와 경보에서 표시됩니다. -
kind: 지표의 종류. 예:sliDefinition.apdexKind.
작성을 마치면 make generate를 실행하여 새 SLI에 대한 녹화 규칙을 생성하십시오. 이 명령은 모든 서비스에 대해 significantLabels를 통합하여 집계된 이 메트릭을 생성합니다.
이러한 변경 사항이 있는 병합 요청을 열고, 확장성 팀 구성원으로부터 검토를 요청하십시오.
이러한 변경 내용이 병합되면, Mimir에서 집계된 메트릭의 성공 비율을 조회하기 위해 Mimir에 쿼리를 수행하십시오. 예:
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 service:
rails_requests:
sliLibrary.get('rails_request_apdex')
.generateServiceLevelIndicator({ job: 'gitlab-rails' })
추가 선택자를 전달하고 SLI의 속성을 재정의하려면 서비스 모니터링 설명서를 참조하십시오.
정적으로 정의된 기능 범주를 갖는 SLI에 대해서는 특정 Slack 채널에서 SLI에 대한 경보를 이미 받을 수 있습니다. 자세한 정보는 경보 라우팅 설명서를 참조하십시오. 우리는 이를 확장하여 소스 메트릭의 feature_category 라벨이 있는 SLI에 대한 경보를 라우팅할 수 있습니다. 자세한 내용은 이 프로젝트에서 확인할 수 있습니다.
질문이 있으면 언제든지 확장성 이슈 트래커에서 이슈를 생성하거나 #g_scalability Slack에서 저희를 찾아오세요.
도움말