GitLab 애플리케이션 서비스 수준 지표(SLI)

요약

Ruby 코드베이스에서 직접 서비스 수준 지표(Service Level Indicators, SLI)를 정의할 수 있습니다. global_search_error_rate global_search_indexing_apdex

Ruby 코드베이스에서 직접 서비스 수준 지표(Service Level Indicators, SLI)를 정의할 수 있습니다. 이를 통해 작업과 그 성공 여부의 정의를 구현 코드와 가깝게 유지할 수 있으며, 기능을 개발하는 사람들이 해당 기능을 어떻게 모니터링해야 하는지 쉽게 정의할 수 있습니다.

기존 SLI#

rails_request
global_search_apdex
global_search_error_rate
global_search_indexing_apdex
sidekiq_execution
zoekt_tasks

새 SLI 정의하기#

SLI 구현은 labkit-ruby에 Labkit::ApplicationSli로 존재합니다. 자세한 내용은 Labkit::ApplicationSli README를 참조하십시오. GitLab-Rails에서는 Gitlab::Metrics::Sli가 하위 호환 별칭이므로 기존 코드는 계속 동작합니다.

SLI는 Gitlab::Metrics::Sli::Apdex 또는 Gitlab::Metrics::Sli::ErrorRate 클래스를 사용하여 정의할 수 있습니다. SLI를 정의하면 Rails 애플리케이션에서 두 개의 Prometheus 카운터가 발행됩니다. 두 카운터는 대체로 같은 방식으로 동작하며 총 작업 수를 포함합니다. 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 — 오류 측정 횟수. 이 메트릭은 오류율이므로 오류 수를 총 횟수로 나눕니다.

예시에서 보듯이, 두 SLI는 기본 이름을 공유할 수 있습니다(이 예시에서는 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를 호출하면 총 Prometheus 카운터가 증가합니다:

gitlab_sli:received_email_apdex:total{ feature_category='service_desk', email_type='service_desk' }

success: 인수로 전달된 값이 참(truthy)이면 성공 카운터도 증가합니다:

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 그룹 및 GitLab.com 전체 가용성의 오류 예산에 포함되어야 합니다.

먼저 새 SLI를 Application-SLI 라이브러리에 추가합니다. 그런 다음 다음 정보를 추가합니다:

name: 코드에 정의된 SLI 이름. 예를 들어 received_email.
significantLabels: 메트릭에 속하는 Prometheus 레이블의 배열. 예를 들어: ["email_type"]. SLI의 중요 레이블에 feature_category가 포함되면, 해당 메트릭은 Stage 그룹의 오류 예산에도 반영됩니다.
featureCategory: SLI가 단일 기능 카테고리에 적용되는 경우, 이 필드를 통해 정적으로 지정하여 SLI를 Stage 그룹의 오류 예산에 반영할 수 있습니다.
description: SLI를 설명하는 Markdown 문자열. 대시보드 및 알림에 표시됩니다.
kind: 지표의 종류. 예를 들어 sliDefinition.apdexKind.

완료되면 make generate를 실행하여 새 SLI에 대한 기록 규칙을 생성합니다. 이 명령은 significantLabels에 걸쳐 집계된 모든 서비스에 대한 기록을 생성합니다.

이 변경 사항으로 머지 리퀘스트를 열고 Scalability 팀원의 리뷰를 요청합니다.

변경 사항이 머지되고 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)

이를 통해 성공 비율을 확인할 수 있으며, 이 SLI를 서비스에 추가할 때 적절한 SLO를 설정하는 데 도움이 됩니다.

그런 다음 해당 서비스 카탈로그 파일에 SLI를 추가합니다. 예를 들어 web 서비스:

rails_requests:
  sliLibrary.get('rails_request_apdex')
    .generateServiceLevelIndicator({ job: 'gitlab-rails' })

SLI에 추가 셀렉터를 전달하고 속성을 재정의하려면 서비스 모니터링 문서를 참조하십시오.

정적으로 정의된 기능 카테고리가 있는 SLI는 지정된 Slack 채널에서 SLI에 대한 알림을 이미 받을 수 있습니다. 자세한 내용은 알림 라우팅 문서를 참조하십시오. 이 프로젝트에서는 소스 메트릭의 feature_category 레이블이 있는 SLI에 대한 알림도 라우팅될 수 있도록 이를 확장하고 있습니다.

문의 사항이 있으면 주저하지 말고 Scalability 이슈 트래커에 이슈를 생성하거나 Slack의 #g_scalability에서 저희를 찾아주십시오.