Stage 그룹을 위한 Observability

Observability의 목적은 시스템 내부를 보고 이해하여 각 구성 요소의 상태를 지원하여 성능 튜닝과 디버깅을 하는 것입니다. SaaS 플랫폼을 대규모로 운영하기 위해서는 풍부하고 상세한 observability 플랫폼이 필요합니다.

Stage 그룹에 정보를 제공하기 위해 기능 범주별로 메트릭을 집계한 다음, 해당 정보를 그룹에 맞는 대시보드에 표시합니다. 그룹이 구축한 기능에 대한 메트릭만이 해당 대시보드에서 보입니다.

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

특정 대시보드에 대한 자세한 정보는 다음을 참조하세요:

에러 버젯

에러 버젯은 GitLab.com을 모니터링하는 데 사용하는 서비스 수준 지표 (SLI)에서 계산됩니다. Stage 그룹의 28일 가용성 숫자는 GitLab.com에 대해 계산하는 월별 가용성과 유사하지만, 해당 그룹의 기능에 대해 범위가 지정됩니다.

에러 버젯을 사용하는 방법에 대한 자세한 정보는 Engineering Error Budgets 핸드북 페이지를 참조하세요.

기본적으로 두 대시보드의 첫 번째 패널 행에는 Stage 그룹의 에러 버젯이 표시됩니다. 해당 행에는 해당 그룹이 소유한 기능이 우리의 전체 가용성에 어떻게 기여하는지가 표시됩니다.

공식 버젯은 28일 동안 집계됩니다. 해당 정보는 Stage 그룹 대시보드에서 확인할 수 있으며, 에러 버젯 상세 대시보드는 범위를 사용자 정의할 수 있습니다.

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

버젯은 구성 요소별 지표를 기반으로 계산됩니다. 각 구성 요소는 두 가지 지표를 가질 수 있습니다:

Apdex: 충분히 수행된 작업의 비율
“충분히 수행된” 임계값은 메트릭스 카탈로그에 저장되어 있으며, 해당 서비스에 따라 달라집니다. API의 Puma (Rails) 구성 요소, Git, 및 Web 서비스의 경우, 해당 임계값은 5초이며, rails_request SLI에 가입하지 않은 경우에만 적용됩니다.
이 목표는 이 프로젝트에서 사용자 정의할 수 있습니다. 요청 Apdex를 사용자 정의하려면 Rails request SLIs를 참조하세요. 이 새로운 Apdex 측정 항목은 가입할 때까지 에러 버젯의 일부가 아닙니다.
Sidekiq 작업 실행의 경우, 임계값은 작업 긴급도에 따라 다릅니다. 현재는 고긴급 작업에 대해 10초, 다른 작업에 대해 5분이 적용됩니다.
일부 stage 그룹은 더 많은 서비스를 보유할 수 있습니다. 해당 서비스의 임계값은 메트릭스 카탈로그에도 나와 있습니다.
에러율: 에러가 발생한 작업의 비율

비율의 계산은 다음과 같이 수행됩니다:

\frac {operations\_meeting\_apdex + (total\_operations - operations\_with\_errors)} {total\_apdex\_measurements + total\_operations}

stage 그룹 대시보드 및 오류 예산 상세 대시보드 모두 예산이 소비된 곳을 확인할 수 있는 패널을 보여줍니다. stage 그룹 대시보드는 항상 고정된 28일을 보여줍니다. 반면 오류 예산 상세 대시보드는 시간에 따라 SLI를 자세히 살펴볼 수 있습니다.

오류 예산 줄 아래의 행은 기본적으로 축소되어 있습니다. 펼치면 과거 28일 동안 가장 많은 문제를 일으킨 구성 요소 및 위반 유형을 확인할 수 있습니다.

왼쪽의 첫 번째 패널에는 구성 요소별 오류 수가 나열된 테이블이 표시됩니다. 이 테이블의 첫 번째 행을 자세히 살펴보면 예산이 소비된 영향력이 가장 큽니다.

대체로, 예산을 가장 많이 소비하는 구성 요소는 Sidekiq 또는 Puma입니다. 중앙의 패널에는 다양한 위반 유형의 의미와 로그를 자세히 살펴보는 방법에 대해 설명합니다.

오른쪽의 패널은 오류를 일으키는 엔드포인트나 Sidekiq 작업을 확인할 수 있는 Kibana로의 링크를 제공합니다.

이러한 패널 및 로그를 사용하여 Rails 엔드포인트가 느린지 확인하는 방법에 대해 알아보려면 구매 그룹을 위한 오류 예산 속성 비디오를 참조하세요.

테이블에서 확인할 수 있는 기타 구성 요소는 서비스 수준 지표(SLIs)와 메트릭 카달로그에서 정의된 것입니다.

이러한 종류의 오류에 대해서는 type 열에서 링크된 서비스 대시보드로 이동할 수 있습니다. 서비스 대시보드에는 예산이 소비되는 SLI에 특별히 할당된 행이 있으며 해당 구성 요소의 로그 및 설명을 확인할 수 있는 링크가 있습니다.

예를 들어, web-pages 서비스의 server 구성 요소를 참조하세요:

특정 기능에 맞는 추가 SLI를 추가하려면 애플리케이션 SLI를 사용할 수 있습니다.

자세한 분석을 위해 전용 Kibana 대시보드를 사용할 수 있습니다. 이는 다음의 이미지와 같습니다:

설명:

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

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

답변할 질문: