서비스 수준 지표(Service Level Indicator, SLI)는 Ruby 코드베이스에서 직접 정의할 수 있습니다. 이렇게 하면 작업과 그 성공 기준의 정의가 구현과 가까운 곳에 있게 되고, 기능을 만드는 사람이 그 기능을 어떻게 모니터링할지 손쉽게 정의할 수 있습니다.

기존 SLI#

1. audit_event_streaming_nats_dispatch
2. global_search_apdex
3. global_search_error_rate
4. global_search_indexing_apdex
5. openbao_client_calls
6. rails_request
7. sidekiq_execution
8. zoekt_tasks

새 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. 이 메트릭은 오류율이므로 오류 수를 전체 수로 나눕니다.

이 예시처럼 두 메트릭은 기본 이름(여기에서는 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: 인수가 참이면 성공 카운터도 함께 증가합니다.

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: 해당 메트릭에 속하는 Prometheus 레이블의 배열입니다. 예를 들면 ["email_type"] 입니다. SLI의 주요 레이블에 feature_category가 포함되면 해당 메트릭은 스테이지 그룹의 오류 예산에도 반영됩니다.
• featureCategory: SLI가 단일 기능 카테고리에 적용된다면, 이 필드로 정적으로 지정해 SLI를 스테이지 그룹의 오류 예산에 반영할 수 있습니다.
• 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 채널로 문의합니다.