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

관측성은 성능 조정 및 디버깅을 지원하기 위해 시스템의 각 구성 요소의 상태를 보고 이해할 수 있는 가시성을 제공하는 것입니다. SaaS 플랫폼을 대규모로 운영하기 위해서는 풍부하고 상세한 관측 플랫폼이 필요합니다.

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

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

대시보드에 대한 보다 구체적인 정보는 다음을 참조하세요:

오류 예산

오류 예산은 우리가 GitLab.com을 모니터링하는 데 사용하는 동일한 서비스 수준 지표(SLI)에서 계산됩니다. 스테이지 그룹의 28일 가용성 수치는 GitLab.com에 대해 우리가 계산하는 월간 가용성과 유사하지만, 그룹의 기능에 한정됩니다.

오류 예산을 사용하는 방법에 대한 자세한 정보는 엔지니어링 오류 예산 핸드북 페이지를 참조하세요.

기본적으로 두 대시보드의 첫 번째 패널 행은 스테이지 그룹의 오류 예산을 표시합니다. 이 행은 그룹이 소유하는 기능이 우리의 전체 가용성에 어떻게 기여하는지를 보여줍니다.

공식 예산은 28일 동안 집계됩니다. 이는 스테이지 그룹 대시보드에서 확인할 수 있습니다. 오류 예산 세부정보 대시보드는 범위를 사용자 정의할 수 있도록 허용합니다.

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

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

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

단계 그룹 대시보드와 오류 예산 세부 대시보드는 오류 예산이 어디에 사용되었는지를 확인할 수 있는 패널을 보여줍니다. 단계 그룹 대시보드는 항상 고정된 28일을 표시합니다. 오류 예산 세부 대시보드는 SLIs를 시간에 따라 세부적으로 분석할 수 있습니다.

오류 예산 줄 아래의 행은 기본적으로 축소되어 있습니다. 이를 확장하면 지난 28일 동안 가장 많은 위반 작업을 한 컴포넌트와 위반 유형이 표시됩니다.

왼쪽의 첫 번째 패널은 각 컴포넌트당 오류 수가 포함된 표를 보여줍니다. 해당 표의 첫 번째 행을 자세히 살펴보는 것이 지출된 예산에 가장 큰 영향을 미칩니다.

일반적으로 예산을 가장 많이 사용하는 컴포넌트는 Sidekiq 또는 Puma입니다. 중간 패널은 다양한 위반 유형이 무엇을 의미하는지와 로그에서 더 깊이 파고드는 방법을 설명합니다.

오른쪽 패널은 오류를 유발하는 엔드포인트 또는 Sidekiq 작업을 보여줄 Kibana 링크를 제공합니다.

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

표에 표시된 다른 컴포넌트는 서비스 수준 지표 (SLIs)로, 메트릭 카탈로그에서 정의됩니다.

이러한 유형의 실패에 대해서는 type 열에서 연결된 서비스 대시보드 링크를 따라가면 됩니다. 서비스 대시보드에는 예산을 사용하게 하는 SLI에 대한 특정 행이 포함되어 있으며, 로그에 대한 링크와 컴포넌트의 의미에 대한 설명이 포함되어 있습니다.

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

특정 기능에 맞춘 SLIs를 추가하려면 응용 프로그램 SLI를 사용할 수 있습니다.

자세한 분석을 위해 특화된 Kibana 대시보드를 사용할 수 있습니다, 다음과 같은:

설명:

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

답변할 질문들:

GitLab 코드베이스를 OpenTelemetry에 맞게 계측하기 위한 지속적인 노력이 있습니다.

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