This page contains information related to upcoming products, features, and functionality. It is important to note that the information presented is for informational purposes only. Please do not rely on this information for purchasing or planning purposes. As with all projects, the items mentioned on this page are subject to change or delay. The development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.
Status Authors Coach DRIs Owning Stage Created
proposed @mappelman @hbenson @nicholasklick devops monitor 2023-06-20

분산 추적 기능

요약

GitLab은 이미 분산 추적을 기능으로 제공하고 있습니다. 따라서 이 제안은 해당 기능을 GA로 전환하기 위해 필요한 의도된 변경에 초점을 맞춥니다. 모티베이션 섹션에서 더 자세히 다루는 전략적 방향 업데이트에 따라, 우리는 GitLab UI에 대한 네이티브 추적용 UI를 구축하는 것을 선호하여 GitLab Observability UI(GOUI)의 사용을 중단합니다.

본 제안은 GA에 출시될 범위와 기술적 접근 방식을 다루며, 새로운 UI, API 변경 및 새로운 방향을 지원하기 위한 백엔드 변경을 포함합니다.

분산 추적은 프리미엄 기능으로 GA될 것이며, 초기에는 프리미엄 및 얼티밋 사용자에게만 제공됩니다.

동기

2021년 12월 GitLab은 OpsTrace를 인수하고 Observability 기능을 DevOps 플랫폼에 통합하는 작업을 시작했습니다. 그 당시 목표는 GitLab과 독립적으로 실행할 수 있는 Observability 분산 시스템을 만들고 이를 DevSecOps 플랫폼에 효과적으로 통합하는 것이었습니다. 이전 전략에 대한 자세한 내용은 내부 전용-Argus FAQ에서 확인할 수 있습니다.

2021년 12월 이후 세계와 GitLab에서 많은 변화가 있었습니다. GitLab은 Observability를 GitLab UI 내에서 원천적으로 구축해 사용자 경험을 일원화하고 기능을 파편화하지 않는 것이 옳다고 믿고 있습니다. 따라서 우리는 2021년 12월 Grafana의 포크로 시작된 GitLab Observability UI를 사용 중단합니다.

GitLab Observability 아키텍처와 기능 중 상당 부분은 Grafana의 포크를 기반으로 개발되었습니다. 따라서 본 제안은 다음과 같은 고수준 목표를 달성하는 데 일조하여 우리의 방향을 맞추기 위한 일련의 제안 중 하나입니다.

Observability 그룹 목표

다음은 맥락을 이해하기 위해 포함된 그룹 수준의 목표입니다. 아래 목표는 본 설계에 완전히 포함되지 않습니다. 본 설계는 분산 추적에 중점을 두고 있습니다. 로깅, 메트릭, 자동 모니터 등에 대한 자세한 설계 문서가 작성될 것입니다.

타임라인: 2024년 12월 이전에 다음이 완료됨

목표:

  • 완전한(GA) Observability 플랫폼(Metrics, Logs, Traces) 출시 - 트레이싱, 메트릭 및 로깅에 대한 기본 설정(온 바이 디폴트) 추가. GitLab.com 및 자체 관리 사용자를 위한 서비스에 대한 GA 출시. 사용자는 오픈 소스 추적기를 사용하여 마이크로서비스 또는 분산 시스템을 추적할 수 있어야 합니다. 또한 사용자는 샘플링에 대한 합리적인 기본값을 설정하거나 테일 기반 샘플링과 같은 고급 기술을 사용해야 합니다.

  • 맞춤형 트리아지 워크플로우 - 사용자는 메트릭, 로그, 스팬/추적 간의 연결점을 찾아야 합니다. 모든 유형의 텔레메트리 데이터의 발견, 쿼리 및 연결을 디자인함으로써 사용자가 중요한 경보와 사건을 빠르게 해결할 수 있도록 도와야 합니다.

  • 자동 모니터 - 개발자가 새 프로젝트를 시작할 때 자동으로 애플리케이션에 기기를 설치하고, 경보를 설정하고, GitLab 경보 관리에 연결하며, 일정을 생성하고, 중요한 경보를 위한 사건을 생성합니다.

목표

GitLab.com SaaS의 일환으로 일반적으로 사용 가능한 분산 추적 기능을 출시하되 가치 있는 최소한의 기능 집합이며, 반복적으로 발전시킬 수 있어야 합니다.

구체적인 목표:

  • GitLab Observability Backend에 구현된 HTTPS 쓰기 API - 이 API는 GitLab으로 보낸 스팬을 수신하며, OTLP(OpenTelemetry Protocol)을 사용하여 분산 추적을 수집하고 전송할 수 있어야 합니다. 사용자는 OpenTelemetry SDK 또는 OpenTelemetry Collector를 사용하여 분산 추적을 수집하고 전송할 수 있어야 합니다.
  • ID, 서비스, 속성 또는 시간별로 추적을 나열하고 필터링/검색할 수 있는 UI
  • 추적 및 해당 스팬의 상세 보기를 보여주는 UI
  • 상위 네임스페이스 당 합리적인 수신 및 저장 한도 적용 (모든 GitLab 티어)

타임라인

그룹 목표를 달성하기 위해 분산 추적의 GitLab 점진적 출시를 위해 다음과 같은 타임라인을 준수해야 합니다.

  • 추적 실험 출시: 16.2
  • 추적 베타 출시: 16.3
  • 추적 GA 출시: 16.4

제안

제안된 아키텍처 대부분은 이미 존재하고 GitLab.com에서 운영 중입니다. 분산 추적은 이미 꽤 오랫동안 내부 베타로 사용 중이며, GA로의 졸업은 UX 요건에 막혀 있습니다. 이러한 UX 요건으로 인해 새로운 UI 전략이 나왔습니다.

다음 다이어그램은 GitLab Observability Backend의 아키텍처와 GitLab UI를 포함한 클라이언트 간의 상호 작용을 보여줍니다.

주요 구성 요소

  • Gatekeeper: 모든 들어오는 요청에 대한 인증, 권한 부여 및 요청률 제한을 담당합니다. NGINX-Ingress가 게이트키퍼와 직접 상호 작용합니다.
  • Ingress: 모든 들어오는 요청을 처리하는 데 NGINX-Ingress를 사용합니다.
  • ClickHouse: 모든 Observability 데이터의 백업 저장소로 ClickHouse를 사용합니다.
  • 쿼리 서비스: 쿼리에 대한 응답으로 ClickHouse에서 데이터를 검색하는 수평적으로 확장 가능한 서비스
  • GitLab UI: GitLab.com에서 호스팅되는 UI
  • Redis: GitLab API 응답을 위한 HA Redis 클러스터

데이터 수집

각 최상위 GitLab 네임스페이스마다 하나의 데이터 수집 파이프라인이 배포됩니다. 현재는 _관측성을 활성화하는 GitLab 그룹 당 하나의 파이프라인이 배포_되고 있으며, 이 아키텍처는 멀티테넌트 그라파나 인스턴스의 존재 없이는 불필요하게 비싸고 복잡합니다. 이 멀티테넌트 수집 시스템에는 다음과 같은 이점이 있습니다:

  • 요금 한도 이상으로 각 사용자당 리소스 한도를 메모리, CPU가 할당된 것 이상으로 지켜줄 수 있습니다.
  • 더 많은 OTEL Collector 인스턴스를 추가하여 각 사용자 파이프라인의 수평 확장을 세밀하게 제어할 수 있습니다.
  • GitLab 구독 티어에 따라 사용자 테넌트를 관리할 수 있습니다. 예를 들어, 할당량, 처리량, 콜드 스토리지, 다른 데이터베이스로의 분할
  • 오픈텔레메트리 컬렉터와 같은 외부 구성 요소를 활용하여 파이프라인에서 복잡성을 줄이고 보안을 강화할 수 있으며, 이 컬렉터 내의 데이터는 단일 사용자/고객에 속합니다.

파이프라인은 프로젝트 설정에서 관측성을 활성화한 사용자에게만 배포되며, 사용자는 프로젝트에 오류 추적을 활성화할 수 있는 방식과 동일하게 관측성을 활성화할 수 있습니다. 사용자 네임스페이스의 어떤 프로젝트에 관측성이 활성화되면 파이프라인이 배포됩니다. 이 배포는 우리의 쿠버네티스 스케줄러-오퍼레이터와 테넌트-오퍼레이터에 의해 자동화됩니다. 현재 프로비저닝은 iframe을 통해 관리되지만, 좋은 방법은 RESTful API를 사용하여 프로비저닝하는 것입니다. GitLab UI에는 사용자가 “관측성 활성화”를 가능하게 하는 프로젝트 설정의 섹션이 있을 것입니다. 오늘날과 같이 오류 추적을 가능하게 하는 방식과 동일합니다.

오픈텔레메트리 컬렉터는 수신기, 프로세서 및 익스포터의 커뮤니티 개발이 우수하기 때문에 핵심 파이프라인 구현으로 사용됩니다. 커뮤니티에서 ClickHouse용 익스포터가 나와 있으며, 우리는 이를 활용할 것이며 현재 이 익스포터는 오픈텔레메트리 추적, 메트릭 및 로그를 지원합니다. 이것은 추적 뿐만 아니라 메트릭 및 로그도 수집하는 작업으로의 노력을 가속화할 것입니다.

제한 사항

각 수집 파이프라인마다 기존 CPU 및 메모리 한도 외에도 다음과 같은 한도 및 할당량이 적용됩니다:

  • 최상위 네임스페이스 당 초당 추적 데이터 총 수집률은 100KB (이것을 1MB로 증가할 가능성 있음)
  • 30일 데이터 보유
  • 미정의 GB 총 저장소

상기 모든 한도는 변경될 수 있으며, 최상위 네임스페이스 구성에 의해 구동되므로 스크립트 및 미래 기능이 이들을 사용자 또는 구독 티어마다 동적으로 구축할 수 있도록 만들 수 있습니다. 이 구성은 테넌트-오퍼레이터 사용자 정의 리소스의 일부가 될 것입니다.

수집률 한도는 내부 레디스 클러스터를 활용하여 간단하고 성능이 우수한 Cloudflare와 같은 슬라이딩 윈도우 한도를 적용할 것입니다. 이 코드는 이미 레디스 연결이 Gatekeeper에 의해 관리되므로 이 코드는 Gatekeeper에 존재할 것입니다.

데이터 보유 및 총 저장소 한도는 테넌트-오퍼레이터의 제어 루프에 의해 적용될 것입니다. 이 제어 루프는 주기적으로 ClickHouse를 쿼리하고 할당량을 더 이상 초과하지 않도록 오래된 일별 데이터를 계속해서 삭제할 것입니다. 이를 효율적으로 수행하기 위해서는 ClickHouse 테이블이 toDate(timestamp)을 사용하여 일별로 파티셔닝되어야 합니다.

쿼리 API

쿼리 서비스를 백업하는 쿼리 API는 중앙 집중식으로 확장 가능한 구성 요소로써 UI로 추적/스팬을 반환할 책임이 있습니다. 이 쿼리 서비스의 좋은 시작점은 Jaeger 쿼리 서비스 코드와 Jaeger 쿼리 서비스 스웨거를 활용하는 것일 것입니다. 이 쿼리 서비스는 미래에 메트릭 및 로그 지원을 포함하도록 확장되고, GitLab UI의 Vue.js 코드에서 직접 쿼리될 것입니다.

GA의 노력 범위는 두 가지 API를 포함할 것입니다:

  • /v1/traces이 사양을 준수합니다.
  • /v1/traces/{trace_ID}이 사억을 준수합니다.

인증 및 권한

GitLab Observability 백엔드는 인스턴스 전역 신뢰하는 GitLab OAuth 토큰을 이용하여 신뢰할 수 있는 OAuth 흐름을 수행하여 GitLab 사용자를 GitLab Observability 백엔드 (GOB)에 대해 인증합니다. GOB는 인증 세션을 만들고 그 세션 식별자를 http-only, 보안 쿠키에 저장합니다. 이 메커니즘은 이미 AppSec에 의해 조사 및 승인되었습니다. 관측성 UI가 이제는 GitLab.com에서 호스팅되는 UI 내에서 네이티브로 되기 때문에, 이 인증이 이전에 의존했던 임베디드 iframe 대신 새로운 UI 도메인에 대해 작동하도록 몇 가지 조정이 필요합니다 (이전 observe.gitLab.com 대신 GitLab.com).

GitLab UI에는 GOB 인증된 API를 소비해야 하는 페이지에만 숨겨진 iframe이 포함될 것입니다. 이것은 프록시 계층이 없고 프록시와 GOB 사이의 적은 안전한 공유 토큰에 의존하지 않고 GitLab.com UI가 GOB API와 직접 통신할 수 있도록 합니다. 이 iframe은 숨겨지며 그 유일한 목적은 OAuth 흐름을 수행하고 GOB 사용자 세션을 포함하는 http-only 보안 쿠키를 할당하는 것입니다. 이 흐름은 투명하며 사용자로부터 완전히 숨겨질 수 있습니다. 현재 세션은 30일 후에 만료되며, GOB 배포 terraform에서 구성 가능합니다.

이 방법을 사용하여 GitLab.com에서 observe.gitLab.com으로 직접 요청을 허용하려면, 모든 요청에 {withCredentials: true}를 포함해야 합니다. GitLab.com이 추적 데이터를 조회할 “읽기 전용” API에 대해 NGINX.Ingress.Kubernetes.io/cors-allow-credentials: “true” 및 NGINX.Ingress.Kubernetes.io/cors-allow-origin: “GitLab.com”을 구성해야 하며, Gatekeeper에서 효과적인 CSRF 보호 기능이 활성화되어 있어야 합니다 (Gatekeeper는 요청 권한을 처리합니다).

그럼으로써 GitLab.com에서 observe.gitLab.com으로의 모든 요청은 observe.gitLab.com에서 유효한 GOB 세션 쿠키를 포함하고 있다가 유효성을 검사할 것입니다. 권한은 Gatekeeper 구성 요소에 의해 처리되며 그룹/프로젝트 멤버십을 GitLab과 확인하고 적절한 접근을 처리합니다. 개발자 또는 해당 멤버십을 상속한 누구든 해당 프로젝트의 추적 UI에 액세스할 수 있을 것입니다.

데이터베이스 스키마

ClickHouse를 위한 커뮤니티 개발 OTEL 내보내기는 이미 추적과 span을 저장하기 위한 데이터베이스 스키마를 구현했습니다. ClickHouse의 블로그 글에서는 커뮤니티에서 개발한 내보내기에 대한 자세한 내용을 다루고 있으며, 우리는 실험 및 베타 단계에서 시도할 권장 스키마 디자인을 시작점으로 활용할 예정입니다. 블로그 글을 읽어서 우리가 시도할 예정인 스키마와 해당 SQL 쿼리에 대해 더 자세히 알아보시기를 권장합니다.

UI 디자인

새로운 UI는 Pajamas Design System을 사용하여 GitLab UX 디자인 표준에 따라 구축될 것입니다. UI는 vue.js를 통해 GOB 쿼리 서비스와 직접 상호작용하여 (위의 아키텍처 다이어그램 참조) {withCredentials: true}와 함께 observe.gitLab.com/v1/query 하위 도메인으로 fetch를 보내게 됩니다. 이를 가능하게 하는 자세한 내용은 위의 인증 및 권한 부분을 참조하시기 바랍니다.

TODO Figma UI 디자인 및 코멘터리

반복

16.2

  • 그룹 CR에 첨부된 모든 리소스를 테넌트 CR로 이관
  • ClickHouse 내보내기를 fork하고 빌드
  • 모든 추적/스팬에 project_ID 추가
  • 게이트키퍼: 그룹 수준이 아닌 프로젝트 수준에서 멤버십 확인
  • 추적을 나열하는 기본 쿼리 서비스 (필터링/검색 없음)
  • 숨겨진 iframe 기반 OAuth 메커니즘 구현 (GOUI에서 이미 수행한 것 재사용/적응)
  • 추적 목록을 위한 UI

16.3

  • 필터링/검색 쿼리 서비스 (traceID, service, status, duration min/max, start/end time, span attributes로)
  • read_observabilitywrite_observability 스코프를 프로젝트 액세스 토큰에 추가하고 프로젝트 수준 인게스트 API에 대한 프로젝트 액세스 토큰 지원
  • 프로비저닝 API
  • 기존 iframe 프로비저닝 제거
  • 추적 상세를 위한 UI
  • 추적 필터링/검색을 위한 UI
  • 프로비저닝, 데이터 전송, UI에서 쿼리를 위한 기본 e2e 테스트
  • 메트릭, 대시보드, 경고

16.4

  • “가능성론”을 활성화하는 UI 설정 페이지 (이는 프로비저닝 API와 상호작용하게 됨)
  • 상용화 준비 검토
  • 완전한 문서
  • GitLabNamespace CR을 테넌트(즉, 최상위 네임스페이스)만 나타내도록 변경
  • 그룹 CR 및 해당 컨트롤러 삭제
  • 아직 추가되지 않은 e2e 테스트
  • 클러스터 내 스모크 테스트