스테이지 그룹을 위한 관측성

관측성은 시스템 내의 각 구성요소의 상태를 이해하고 파악하기 위해 가시성을 제공하는 것으로, 성능 튜닝과 디버깅을 지원합니다. SaaS 플랫폼을 대규모로 운영하기 위해서는 풍부하고 상세한 관측성 플랫폼이 필요합니다.

스테이지 그룹에 정보를 제공하기 위해 기능 카테고리 별로 메트릭을 집계한 다음, 해당 정보를 그룹에 맞는 대시보드에 표시합니다. 그룹이 구축한 기능에 대한 메트릭만이 그들의 대시보드에서 볼 수 있습니다.

필터된 보기로 그룹은 집계된 데이터를 확인할 때 놓칠 수 있는 버그 및 성능 하락을 발견할 수 있습니다.

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

에러 버젯

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

에러 버젯 사용에 대한 더 많은 정보는 공학 에러 버젯 핸드북 페이지를 참조하세요.

기본적으로 양 대시보드의 첫 번째 패널 행에는 스테이지 그룹의 에러 버젯이 표시됩니다. 해당 행은 그룹이 소유한 기능이 전체 가용성에 기여하는 방식을 보여줍니다.

공식적인 버젯은 28일 동안 집계됩니다. 이를 스테이지 그룹 대시보드에서 볼 수 있으며, 에러 버젯 세부 정보 대시보드는 범위를 사용자 정의할 수 있습니다.

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

버젯은 컴포넌트 당 지표를 기반으로 계산됩니다. 각 컴포넌트에는 두 가지 지표가 있습니다:

Apdex: 적절하게 작동한 작업의 비율.
“적절하게 작동하는” 임계값은 메트릭스 카탈로그에 저장되어 있으며, 해당 서비스에 따라 달라집니다. 예를 들어, API의 Puma (Rails) 컴포넌트, Git, 그리고 Web 서비스의 경우, rails_request SLI에 가입하지 않았을 때의 임계값은 5초입니다.
우리는 이 목표를 설정 가능하게 만들었습니다(https://gitlab.com/groups/gitlab-com/gl-infra/-/epics/525). Apdex 요청을 사용자 정의하려면 Rails request SLIs을 참조하십시오. 이 새로운 Apdex 메트릭은 가입하면 에러 버젯의 일부가 됩니다.
Sidekiq 작업 실행의 경우, 임계값은 작업 긴급도에 따라 달라집니다. 현재 고급 긴급 작업의 경우 현재 10초, 그 외의 작업의 경우 5분입니다.
어떤 스테이지 그룹들은 더 많은 서비스를 보유할 수 있습니다. 해당 서비스의 임계값 또한 메트릭 카탈로그에 있습니다.
에러율: 에러를 발생한 작업의 비율.

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

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

스테이지 그룹 대시보드와 에러 버젯 세부 정보 대시보드 모두 에러 버젯이 사용된 위치를 볼 수 있는 패널을 표시합니다. 스테이지 그룹 대시보드는 항상 고정된 28일을 보여줍니다. 에러 버젯 세부 정보 대시보드에서는 시간에 따라 SLI로 들어갈 수 있습니다.

에러 버젯 행 아래의 행은 기본적으로 축소되어 있습니다. 이를 확장하면 과거 28일 동안 가장 많은 문제를 일으킨 컴포넌트 및 위반 유형이 표시됩니다.

왼쪽의 첫 번째 패널은 각 컴포넌트당 에러 수를 보여주는 표를 표시합니다. 해당 표에서 첫 번째 행을 자세히 살펴보면 버젯을 가장 많이 지출한 영향을 미친 것을 확인할 수 있습니다.

보통, 가장 많은 버젯을 사용하는 컴포넌트는 Sidekiq 또는 Puma입니다. 중앙의 패널에서는 다양한 위반 유형이 의미하는 것과 로그를 자세히 파악하는 방법에 대해 설명합니다.

오른쪽 패널은 어떤 엔드포인트나 Sidekiq 작업이 에러를 일으키는지를 나타내는 Kibana로의 링크를 제공합니다.

이러한 패널과 로그를 사용하여 Rails 엔드포인트가 느린 지 확인하는 방법은 Purchase 그룹의 에러 버젯 속성 동영상을 참조하세요.

표에 표시된 다른 컴포넌트는 서비스 수준 지표 (SLI)과 관련된 메트릭 카탈로그에서 가져옵니다.

해당 유형의 오류의 경우 type 열에서 링크를 따라 해당 서비스 대시보드로 이동할 수 있습니다. 해당 서비스 대시보드에는 버젯을 지출한 SLI에 대한 행이 포함되어 있으며, 로그 및 컴포넌트의 내용을 설명하는 링크가 제공됩니다.

예를 들어, web-pages 서비스의 server 컴포넌트를 참조하세요:

특정 기능에 맞게 추가 SLI를 추가하려면 Application SLI을 사용할 수 있습니다.

자세한 분석을 위해 특수화된 키바나 대시보드를 사용할 수 있습니다.

설명:

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

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

답해야 할 질문:

GitLab 코드베이스를 OpenTelemetry에 대한 계측을 위한 노력이 진행 중입니다.

이 노력에 대한 더 구체적인 정보는 OpenTelemetry를 위한 GitLab 계측를 참조하세요.