InfoGrab DocsInfoGrab Docs

Stage 그룹을 위한 Observability

요약

Observability는 시스템에 가시성을 부여하여 각 컴포넌트의 상태를 컨텍스트와 함께 파악하고, 성능 튜닝 및 디버깅을 지원하는 것입니다. Stage 그룹에 정보를 제공하기 위해, 우리는 기능 카테고리별로 메트릭을 집계한 뒤 그룹에 맞춤화된 대시보드에 이 정보를 표시합니다.

Observability는 시스템에 가시성을 부여하여 각 컴포넌트의 상태를 컨텍스트와 함께 파악하고, 성능 튜닝 및 디버깅을 지원하는 것입니다. SaaS 플랫폼을 대규모로 운영하려면 풍부하고 세밀한 Observability 플랫폼이 필요합니다.

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

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

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

에러 예산#

에러 예산은 GitLab.com을 모니터링하는 데 사용하는 동일한 서비스 수준 지표(SLI, Service Level Indicators)를 기반으로 계산됩니다. Stage 그룹의 28일 가용성 수치는 GitLab.com에 대해 계산하는 월별 가용성과 비교할 수 있지만, 그룹의 기능으로 범위가 한정됩니다.

에러 예산 사용 방식에 대한 자세한 내용은 Engineering Error Budgets 핸드북 페이지를 참조하세요.

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

공식 예산은 28일에 걸쳐 집계됩니다. Stage 그룹 대시보드에서 확인할 수 있습니다. 에러 예산 상세 대시보드를 사용하면 범위를 커스터마이즈할 수 있습니다.

정보는 두 가지 형식으로 표시됩니다:

  • 가용성: 이 수치는 GitLab.com 전체 가용성 목표인 99.95% 가동 시간과 비교할 수 있습니다.

  • 예산 소비: 그룹이 소유한 기능이 지난 28일 동안 적절히 수행되지 않은 시간.

예산은 컴포넌트별 지표를 기반으로 계산됩니다. 각 컴포넌트는 두 가지 지표를 가질 수 있습니다:

  • Apdex: 적절히 수행된 작업의 비율.

    "적절히 수행"의 임계값은 메트릭 카탈로그에 저장되어 있으며 해당 서비스에 따라 다릅니다. API, Git, 그리고 Web 서비스의 Puma(Rails) 컴포넌트의 경우, rails_request SLI를 선택하지 않으면 그 임계값은 5초입니다.

    이 목표는 이 프로젝트에서 설정 가능하도록 했습니다. 요청 Apdex를 커스터마이즈하려면 Rails 요청 SLIs를 참조하세요. 이 새로운 Apdex 측정은 옵트인하기 전까지는 에러 예산에 포함되지 않습니다.

    Sidekiq job 실행의 경우, 임계값은 job 긴급도에 따라 다릅니다. 현재 긴급도가 높은 job은 10초, 그 외 job은 5분입니다.

    일부 Stage 그룹에는 더 많은 서비스가 있을 수 있습니다. 해당 임계값도 메트릭 카탈로그에 있습니다.

  • 에러율: 오류가 발생한 작업의 비율.

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

[

](/19.1/development/stage_group_observability/img/error_budget_calculation_v17_2.png)

예산 소비 위치 확인#

Stage 그룹 대시보드와 에러 예산 상세 대시보드 모두 에러 예산이 소비된 위치를 확인하는 패널을 표시합니다. Stage 그룹 대시보드는 항상 고정된 28일을 표시합니다. 에러 예산 상세 대시보드는 시간 경과에 따른 SLI를 드릴다운할 수 있습니다.

에러 예산 행 아래의 행은 기본적으로 축소되어 있습니다. 이를 펼치면 지난 28일 동안 가장 많은 위반 작업이 발생한 컴포넌트와 위반 유형을 확인할 수 있습니다.

[

](/19.1/development/stage_group_observability/img/stage_group_dashboards_error_attribution_v14_1.png)

왼쪽의 첫 번째 패널은 컴포넌트별 에러 수를 테이블로 표시합니다. 해당 테이블의 첫 번째 행을 파고들면 예산 소비에 가장 큰 영향을 미칩니다.

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

오른쪽 패널은 에러를 유발하는 엔드포인트 또는 Sidekiq job을 찾아볼 수 있는 Kibana 링크를 제공합니다.

어떤 Rails 엔드포인트가 느린지 판단하기 위해 이러한 패널과 로그를 사용하는 방법은 Error Budget Attribution for Purchase group 동영상을 참조하세요.

테이블에 표시되는 다른 컴포넌트는 메트릭 카탈로그에 정의된 서비스 수준 지표(SLI)에서 가져온 것입니다.

이러한 유형의 실패의 경우, type 칼럼에서 연결된 서비스 대시보드 링크를 따라갈 수 있습니다. 서비스 대시보드에는 예산 소비를 유발하는 SLI 전용 행이 있으며, 로그 링크와 컴포넌트 의미에 대한 설명이 포함되어 있습니다.

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

[

](/19.1/development/stage_group_observability/img/stage_group_dashboards_service_sli_detail_v14_1.png)

특정 기능에 맞춤화된 SLI를 더 추가하려면 Application SLI를 사용할 수 있습니다.

에러 예산을 위한 Kibana 대시보드#

상세한 분석을 위해 전용 Kibana 대시보드를 다음과 같이 사용할 수 있습니다:

[

](/19.1/development/stage_group_observability/img/error_budgets_kibana_dashboard_v15_10.png)

설명:

  • Apdex requests over limit (graph) - 목표 소요 시간을 초과한 요청만 표시합니다.

  • Apdex operations over-limit duration (graph) - 소요 시간 컴포넌트(데이터베이스, Redis, Gitaly, Rails 앱)의 분포를 표시합니다.

  • Apdex requests (파이 차트) - 2xx, 3xx, 4xx, 5xx 요청의 비율을 표시합니다.

  • Slow request component distribution - Apdex 위반의 원인이 되는 컴포넌트를 강조 표시합니다.

  • Apdex operations over limit (테이블) - 각 엔드포인트별 한도 초과 작업 수를 표시합니다.

  • Apdex requests over limit - Apdex 위반의 원인이 되는 개별 요청 목록을 표시합니다.

대시보드 사용#

  • 조사하려는 기능 카테고리를 선택합니다.

Feature Category 섹션으로 스크롤합니다. 기능 이름을 입력합니다.

  • Apply changes를 선택합니다. 선택한 결과에는 해당 기능 카테고리와 관련된 요청만 포함됩니다.

  • 조사할 시간 범위를 선택합니다.

  • 대시보드를 검토하고 실패 유형에 주의를 기울입니다.

답해야 할 질문:

  • 실패 패턴이 스파이크처럼 보입니까? 아니면 지속됩니까?

  • 실패가 특정 컴포넌트(데이터베이스, Redis, ...)와 관련된 것처럼 보입니까?

  • 실패가 특정 엔드포인트에 영향을 미칩니까? 아니면 시스템 전체에 영향을 미칩니까?

  • 실패가 인프라 인시던트로 인해 발생한 것처럼 보입니까?

OpenTelemetry를 위한 GitLab 계측#

GitLab 코드베이스에 OpenTelemetry를 계측하려는 노력이 진행 중입니다.

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

Stage 그룹을 위한 Observability

GitLab v19.1
원문 보기
요약

Observability는 시스템에 가시성을 부여하여 각 컴포넌트의 상태를 컨텍스트와 함께 파악하고, 성능 튜닝 및 디버깅을 지원하는 것입니다. Stage 그룹에 정보를 제공하기 위해, 우리는 기능 카테고리별로 메트릭을 집계한 뒤 그룹에 맞춤화된 대시보드에 이 정보를 표시합니다.

Observability는 시스템에 가시성을 부여하여 각 컴포넌트의 상태를 컨텍스트와 함께 파악하고, 성능 튜닝 및 디버깅을 지원하는 것입니다. SaaS 플랫폼을 대규모로 운영하려면 풍부하고 세밀한 Observability 플랫폼이 필요합니다.

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

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

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

에러 예산#

에러 예산은 GitLab.com을 모니터링하는 데 사용하는 동일한 서비스 수준 지표(SLI, Service Level Indicators)를 기반으로 계산됩니다. Stage 그룹의 28일 가용성 수치는 GitLab.com에 대해 계산하는 월별 가용성과 비교할 수 있지만, 그룹의 기능으로 범위가 한정됩니다.

에러 예산 사용 방식에 대한 자세한 내용은 Engineering Error Budgets 핸드북 페이지를 참조하세요.

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

공식 예산은 28일에 걸쳐 집계됩니다. Stage 그룹 대시보드에서 확인할 수 있습니다. 에러 예산 상세 대시보드를 사용하면 범위를 커스터마이즈할 수 있습니다.

정보는 두 가지 형식으로 표시됩니다:

  • 가용성: 이 수치는 GitLab.com 전체 가용성 목표인 99.95% 가동 시간과 비교할 수 있습니다.

  • 예산 소비: 그룹이 소유한 기능이 지난 28일 동안 적절히 수행되지 않은 시간.

예산은 컴포넌트별 지표를 기반으로 계산됩니다. 각 컴포넌트는 두 가지 지표를 가질 수 있습니다:

  • Apdex: 적절히 수행된 작업의 비율.

    "적절히 수행"의 임계값은 메트릭 카탈로그에 저장되어 있으며 해당 서비스에 따라 다릅니다. API, Git, 그리고 Web 서비스의 Puma(Rails) 컴포넌트의 경우, rails_request SLI를 선택하지 않으면 그 임계값은 5초입니다.

    이 목표는 이 프로젝트에서 설정 가능하도록 했습니다. 요청 Apdex를 커스터마이즈하려면 Rails 요청 SLIs를 참조하세요. 이 새로운 Apdex 측정은 옵트인하기 전까지는 에러 예산에 포함되지 않습니다.

    Sidekiq job 실행의 경우, 임계값은 job 긴급도에 따라 다릅니다. 현재 긴급도가 높은 job은 10초, 그 외 job은 5분입니다.

    일부 Stage 그룹에는 더 많은 서비스가 있을 수 있습니다. 해당 임계값도 메트릭 카탈로그에 있습니다.

  • 에러율: 오류가 발생한 작업의 비율.

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

[

](/19.1/development/stage_group_observability/img/error_budget_calculation_v17_2.png)

예산 소비 위치 확인#

Stage 그룹 대시보드와 에러 예산 상세 대시보드 모두 에러 예산이 소비된 위치를 확인하는 패널을 표시합니다. Stage 그룹 대시보드는 항상 고정된 28일을 표시합니다. 에러 예산 상세 대시보드는 시간 경과에 따른 SLI를 드릴다운할 수 있습니다.

에러 예산 행 아래의 행은 기본적으로 축소되어 있습니다. 이를 펼치면 지난 28일 동안 가장 많은 위반 작업이 발생한 컴포넌트와 위반 유형을 확인할 수 있습니다.

[

](/19.1/development/stage_group_observability/img/stage_group_dashboards_error_attribution_v14_1.png)

왼쪽의 첫 번째 패널은 컴포넌트별 에러 수를 테이블로 표시합니다. 해당 테이블의 첫 번째 행을 파고들면 예산 소비에 가장 큰 영향을 미칩니다.

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

오른쪽 패널은 에러를 유발하는 엔드포인트 또는 Sidekiq job을 찾아볼 수 있는 Kibana 링크를 제공합니다.

어떤 Rails 엔드포인트가 느린지 판단하기 위해 이러한 패널과 로그를 사용하는 방법은 Error Budget Attribution for Purchase group 동영상을 참조하세요.

테이블에 표시되는 다른 컴포넌트는 메트릭 카탈로그에 정의된 서비스 수준 지표(SLI)에서 가져온 것입니다.

이러한 유형의 실패의 경우, type 칼럼에서 연결된 서비스 대시보드 링크를 따라갈 수 있습니다. 서비스 대시보드에는 예산 소비를 유발하는 SLI 전용 행이 있으며, 로그 링크와 컴포넌트 의미에 대한 설명이 포함되어 있습니다.

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

[

](/19.1/development/stage_group_observability/img/stage_group_dashboards_service_sli_detail_v14_1.png)

특정 기능에 맞춤화된 SLI를 더 추가하려면 Application SLI를 사용할 수 있습니다.

에러 예산을 위한 Kibana 대시보드#

상세한 분석을 위해 전용 Kibana 대시보드를 다음과 같이 사용할 수 있습니다:

[

](/19.1/development/stage_group_observability/img/error_budgets_kibana_dashboard_v15_10.png)

설명:

  • Apdex requests over limit (graph) - 목표 소요 시간을 초과한 요청만 표시합니다.

  • Apdex operations over-limit duration (graph) - 소요 시간 컴포넌트(데이터베이스, Redis, Gitaly, Rails 앱)의 분포를 표시합니다.

  • Apdex requests (파이 차트) - 2xx, 3xx, 4xx, 5xx 요청의 비율을 표시합니다.

  • Slow request component distribution - Apdex 위반의 원인이 되는 컴포넌트를 강조 표시합니다.

  • Apdex operations over limit (테이블) - 각 엔드포인트별 한도 초과 작업 수를 표시합니다.

  • Apdex requests over limit - Apdex 위반의 원인이 되는 개별 요청 목록을 표시합니다.

대시보드 사용#

  • 조사하려는 기능 카테고리를 선택합니다.

Feature Category 섹션으로 스크롤합니다. 기능 이름을 입력합니다.

  • Apply changes를 선택합니다. 선택한 결과에는 해당 기능 카테고리와 관련된 요청만 포함됩니다.

  • 조사할 시간 범위를 선택합니다.

  • 대시보드를 검토하고 실패 유형에 주의를 기울입니다.

답해야 할 질문:

  • 실패 패턴이 스파이크처럼 보입니까? 아니면 지속됩니까?

  • 실패가 특정 컴포넌트(데이터베이스, Redis, ...)와 관련된 것처럼 보입니까?

  • 실패가 특정 엔드포인트에 영향을 미칩니까? 아니면 시스템 전체에 영향을 미칩니까?

  • 실패가 인프라 인시던트로 인해 발생한 것처럼 보입니까?

OpenTelemetry를 위한 GitLab 계측#

GitLab 코드베이스에 OpenTelemetry를 계측하려는 노력이 진행 중입니다.

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