stage groups를 위한 Observability

Observability는 시스템 내의 각 구성 요소의 상태를 이해하기 위해 맥락과 함께 시스템을 시각화하는 것을 의미하며, 성능 튜닝 및 디버깅을 지원합니다. 규모에 맞게 SaaS 플랫폼을 운영하기 위해서는 풍부하고 자세한 Observability 플랫폼이 필요합니다.

stage groups에 정보를 제공하기 위해 특징 범주별로 지표를 집계한 다음, 해당 정보를 해당 그룹에 맞는 대시보드에 표시합니다. 그룹이 구축한 기능에 대한 지표만 해당 그룹의 대시보드에서 볼 수 있습니다.

필터링된 뷰를 통해 그룹은 집계된 데이터를 볼 때 놓칠 수 있는 버그와 성능 하락을 발견할 수 있습니다.

대시보드에 대한 더 구체적인 정보는 다음과 같습니다:

Error budget

Error budget는 GitLab.com을 모니터링하는 데 사용하는 서비스 수준 지표(SLI)에서 계산됩니다. Stage 그룹의 28일 가용성 숫자는 GitLab.com의 월 가용성과 유사하지만, 기능 범주에 대해 범위가 줄어 있습니다.

Error budget 사용 방법에 대한 자세한 정보는 Engineering Error Budgets 핸드북 페이지에서 확인할 수 있습니다.

기본 설정으로, 두 대시보드의 첫 번째 패널 행에는 stage group의 error budget가 표시됩니다. 이 행은 해당 그룹이 소유한 기능이 우리의 전체 가용성에 기여하는 방식을 보여줍니다.

공식적인 예산은 28일 동안 집계됩니다. 이것은 stage group 대시보드에서 확인할 수 있습니다. error budget 상세 대시보드를 통해 범위를 사용자 정의할 수 있습니다.

우리는 두 가지 형식으로 정보를 표시합니다:

  • 가용성: 이 숫자는 GitLab.com의 전체 가용성 목표인 99.95% 가동 시간과 비교될 수 있습니다.
  • 소비된 예산: 과거 28일 동안 그룹이 소유한 기능의 성능이 적절하지 않았던 시간을 나타냅니다.

예산은 구성 요소별 지표에 따라 계산됩니다. 각 구성 요소는 두 가지 지표를 가질 수 있습니다:

  • Apdex: 적절한 성능을 보인 작업의 비율.

    “적절한 성능”에 대한 임계값은 metrics catalog에 저장되어 있으며, 해당 서비스에 따라 다릅니다. 예를 들어, Puma (Rails) 구성 요소의 경우, API, Git, 및 Web 서비스의 경우, 사용자가 rails_request SLI를 선택하지 않은 경우에는 해당 임계값은 5초입니다.

    이 목표는 이 프로젝트에서 구성할 수 있습니다. Request Apdex를 사용자 정의하려면 Rails request SLIs를 참조하십시오. 이 정보는 opt in되기 전에는 error budget의 일부가 아닙니다.

    Sidekiq 작업 실행의 경우, 임계값은 작업 긴급도에 따라 다릅니다. 현재는 고급 긴급 작업에 대해 10초, 그 외 작업에 대해서는 5분입니다.

    일부 stage 그룹에는 더 많은 서비스가 있을 수 있습니다. 해당 서비스의 임계값에 대한 정보도 metrics catalog에 있습니다.

  • 오류 비율: 발생한 오류의 비율.

비율의 계산은 다음과 같이 이루어집니다:

error budget calculation

예산이 소비된 곳 확인하기

stage group 대시보드와 error budget 상세 대시보드는 error budget가 소비된 위치를 확인할 수 있는 패널을 표시합니다. stage group 대시보드는 항상 일정한 28일을 보여줍니다. error budget 상세 대시보드를 사용하여 SLIs를 시간에 따라 자세히 살펴볼 수 있습니다.

error budget 행 아래의 행은 기본적으로 접혀 있습니다. 확장하면 지난 28일 동안 가장 많은 문제를 일으킨 구성 요소와 위반 유형을 보여줍니다.

Error attribution

왼쪽의 첫 번째 패널은 구성 요소별 오류 횟수가 나와 있는 테이블을 보여줍니다. 해당 테이블의 첫 번째 행을 자세히 살펴보면 예산이 많이 소비된 영향을 미칠 수 있습니다.

일반적으로, 예산을 가장 많이 소비하는 구성 요소는 Sidekiq 또는 Puma입니다. 가운데 패널은 다른 위반 유형의 의미와 로그를 자세히 살펴보는 방법을 설명합니다.

오른쪽의 패널은 발생하는 오류의 원인이 되는 엔드포인트나 Sidekiq 작업을 확인할 수 있는 Kibana로의 링크를 제공합니다.

이 패널과 로그를 사용하여 Rails 엔드포인트의 속도가 느린지 확인하는 방법에 대한 정보는 Purchase 그룹을 위한 Error Budget Attribution 비디오를 참조하십시오.

테이블에 표시된 다른 구성 요소는 service-level indicators (SLIs)와 관련이 있으며, 해당 metrics catalog에 정의되어 있습니다.

해당 유형의 오류의 경우, type 열에서 연결된 서비스 대시보드로 이동할 수 있습니다. 서비스 대시보드에는 예산을 소비하는 SLI에 대한 특별한 행이 포함되어 있으며, 해당 구성 요소의 로그와 설명을 확인할 수 있는 링크가 제공됩니다.

예를 들어, web-pages 서비스의 server 구성 요소를 참조하십시오.

web-pages-server-component SLI

특정 기능에 맞는 더 많은 SLIs를 추가하기 위해 Application SLI를 사용할 수 있습니다.

오류 예산을 위한 키바나 대시보드

자세한 분석을 위해 전용 Kibana 대시보드를 사용할 수 있습니다:

Kibana 대시보드

설명:

  • Apdex 요청 한도 초과 (그래프) - 목표 지속 기간을 초과한 요청만 표시합니다.
  • Apdex 작업 별 초과 지속 시간 (그래프) - 지속 기간 구성요소 (데이터베이스, 레디스, Gitaly 및 Rails 앱)의 분포를 표시합니다.
  • Apdex 요청 (원형 차트) - 2xx, 3xx, 4xx, 및 5xx 요청의 백분율을 표시합니다.
  • 느린 요청 구성요소 분포 - Apdex 위반을 담당하는 구성요소를 강조 표시합니다.
  • Apdex 한도 초과 작업 (테이블) - 각 엔드포인트당 한도를 초과한 작업 수를 표시합니다.
  • Apdex 요청 한도 초과 - Apdex 위반을 일으키는 개별 요청 목록을 표시합니다.

대시보드 사용 방법

  1. 조사하고자 하는 기능 카테고리를 선택합니다.
    1. 기능 카테고리 섹션으로 이동합니다. 기능 이름을 입력합니다.
    2. 변경 사항 적용을 선택합니다. 선택한 결과에는 해당 기능 카테고리와 관련된 요청만 포함됩니다.
  2. 조사를 위한 시간 범위를 선택합니다.
  3. 대시보드를 검토하고 실패 유형에 주의를 기울입니다.

답변할 질문:

  1. 실패 패턴이 급증과 같은 모습을 보이나요? 아니면 계속되나요?
  2. 실패가 특정 구성요소와 연관성이 있나요? (데이터베이스, 레디스, …)
  3. 실패가 특정 엔드포인트에 영향을 주나요? 아니면 시스템 전반에 영향을 주나요?
  4. 실패가 인프라 문제로 인해 발생한 것으로 보이나요?

오픈텔레메트리를 위한 GitLab 계측

GitLab 코드베이스에 대한 오픈텔레메트리 계측이 진행 중입니다.

이 노력에 대한 구체적인 정보는 오픈텔레메트리를 위한 GitLab 계측을 참조하세요.