• 요약
• 동기
• 옵저빠빌리티 그룹 목표
  • 목표
• 타임라인
• 제안
  • 주요 컴포넌트
  • 데이터 수집
  • 제한 사항
  • 쿼리 API
  • 인증 및 권한 부여
  • 데이터베이스 스키마
  • UI 디자인
• 반복

분산 추적 기능

요약

GitLab에는 이미 분산 추적이 기능으로 제공됩니다. 따라서이 제안은 기능을 GA로 전환하기 위해 필요한 변경 사항에 중점을 둡니다. 동기 부분에서 더 자세히 다루는 전략적 방향 업데이트를 고려하면, GitLab UI에 트레이싱의 원격 UI 구축을 우선시하여 GitLab Observability UI (GOUI)를 deprecated합니다.

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

분산 추적 기능은 Premium 기능으로 GA될 것이며, 처음에는 Premium 및 Ultimate 사용자만 사용할 수 있습니다.

동기

2021년 12월에 GitLab은 OpsTrace를 인수하고 옵저빠빌리티 기능을 DevOps 플랫폼에 통합하는 작업을 시작했습니다. 그 당시 목표는 GitLab과 독립적으로 실행될 수있고 DevSecOps 플랫폼에 원활하게 통합되는 옵저빠빌리티 배포를 만드는 것이었습니다. 이전 전략에 대한 자세한 내용은 내부 전용-Argus FAQ을 참조하세요.

2021년 12월 이후로 세상과 GitLab에서 많은 변화가 있었습니다. GitLab은 옵저버빌리티가 기본적으로 GitLab UI 내에 네이티브로 작성되어야 하며 기능의 조각나는 것을 피하고 단일 UX를 보장하기 위해 노력해야 한다고 믿고 있습니다. 따라서, 2021년 12월에 Grafana의 fork로 시작한 GitLab Observability UI를 deprecated하고 있습니다.

GitLab Observability 아키텍처 및 기능 중 많은 부분이 Grafana의 fork를 기반으로 만들어졌습니다. 따라서 본 제안은 다음과 같은 고수준의 목표를 달성하도록 우리를 정렬시키는 일련의 제안 중 일환입니다.

옵저빠빌리티 그룹 목표

아래의 그룹 수준 목표들은 맥락을 제공하기 위해 포함되었습니다. 아래 목표들은 이 설계에 완전히 다루어지지 않았습니다. 이 설계는 분산 추적에 중점을 둡니다. 로깅, 메트릭, 자동 모니터등에 대한 더 많은 설계 문서가 작성될 것입니다.

타임라인: 2024년 12월 이전 완료

목표:

• 완전한 (메트릭, 로그, 추적) 옵저빠빌리티 플랫폼의 GA - 추적, 메트릭 및 로깅에 대한 기본 설정 추가, 해당 서비스가 GitLab.com 및 Self-Managed형 사용자를 위해 GA로 제공됨. 사용자는 오픈 소스 추적기를 사용하여 마이크로서비스 또는 분산 시스템을 추적할 수 있어야 합니다. 또한 사용자는 샘플링에 대한 합리적인 기본 설정을 적용하거나 tail 기반 샘플링과 같은 고급 기술을 사용할 수 있어야 합니다.

• 맞춤형 트리아즈 워크플로우 - 사용자가 메트릭, 로그 및 Spans/Traces 사이의 연결을 찾아내고 질의하며 모든 유형의 텔레메트리 데이터를 연결하는 것은 사용자가 중요한 알림과 사건을보다 빨리 해결할 수 있도록 도와줍니다.

• 자동 모니터 - 개발자가 새 프로젝트를 시작하면 해당 응용 프로그램이 자동으로 계기가 설치되며, 경보가 설정되고 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는 Gatekeeper와 직접 상호 작용합니다.
• Ingress: 모든 들어오는 요청을 처리하는 데 사용되는 NGINX-Ingress
• ClickHouse: 모든 옵저버빌리티 데이터의 백엔드 리포지터리로 사용됩니다.
• 질의 서비스: 질의에 대한 ClickHouse에서 데이터를 검색하는 수평 확장 가능한 서비스
• GitLab UI: GitLab.com에서 호스팅되는 UI
• Redis: GitLab API 응답을 캐싱하기 위한 HA Redis 클러스터

데이터 수집

각 최상위 GitLab 네임스페이스 당 데이터 수집 파이프라인이 배포됩니다. 현재 우리는 옵저빌리티를 활성화할 수 있는 각 GitLab 그룹별로 하나의 파이프라인을 배포하고 있으며, 멀티테넌트 Grafana 인스턴스가 없으면 이 아키텍처는 비효율적이고 복잡합니다. 이 멀티테넌트 수집 시스템에는 다음과 같은 이점이 있습니다.

• 요금 한도를 넘어 사용자가 시스템 자원 (메모리, CPU)을 더 이상 할당받지 못하도록 사용자 당 자원 한도를 강제로 적용할 수 있습니다.
• 각 사용자 파이프라인의 수평 확장에 대한 미세 제어를 활성화할 수 있습니다. 추가로 OTEL Collector 인스턴스를 추가하여 각 사용자 파이프라인의 수평 확장을 더 관리할 수 있습니다.
• 각 사용자의 테넌트를 GitLab 구독 티어에 따라 관리합니다. 예를 들어 할당량, 처리량, 콜드 스토리지, 다른 데이터베이스로 분할하여 사용자의 테넌트를 관리합니다.
• 오프 스레드 컴포넌트를 활용하여 파이프라인을 간소화하고 보안성을 향상시킴으로써, 파이프라인의 복잡성을 줄임

옵저빌리티를 프로젝트 설정에서 활성화 할 경우 사용자의 모든 네임스페이스에 파이프라인이 배포됩니다. 현재 iframe을 통해 프로비저닝을 관리하고 있지만, 선호되는 방법은 RESTful API를 사용하여 프로비저닝하는 것입니다. GitLab UI에는 사용자가 오늘날 오류 추적을 활성화하는 것과 마찬가지로 “옵저빌리티를 활성화”할 수 있는 프로젝트 설정 섹션이 있을 것입니다.

오픈텔레메트리 수집기는 수신기, 프로세서 및 익스포터에 대한 우수한 커뮤니티 개발으로 인해 핵심 파이프라인 구현으로 사용됩니다. 커뮤니티에서 ClickHouse를위한 익스포터가 등장했습니다 그리고 우리는 이를 활용할 것입니다. 현재 opentelemetry traces, metrics 및 logs를 지원하고 있습니다. 이것은 추적 뿐만 아니라 메트릭 및 로그를 흡수하는 노력을 가속화 할 것입니다.

제한 사항

각 입수 파이프라인에 대한 기존 CPU 및 메모리 제한 외에도 다음 제한 사항과 할당량이 적용됩니다.

• 최상위 네임스페이스 당 초당 추적 총 투입 속도가 100KB (이것을 1MB로 증가 할 수 있음)
• 30 일 데이터 보유
• TBD GB 총 저장 공간

위의 모든 제한 사항은 변경될 수 있으며 상위 네임스페이스 구성에 따라 스크립트 및 향후 기능이 이용하여 이러한 제한 사항을 더 동적으로 만들 수 있게 됩니다. 이 구성은 테넌트-operator 커스텀 리소스의 일부가 될 것입니다.

투입률 제한은 내부 Redis 클러스터를 활용하여 Cloudflare처럼 간단하고 성능이 좋은 슬라이딩 창 제한을 수행합니다. 이 코드는 Redis에 이미 연결이 관리되는 Gatekeeper에 있을 것입니다.

데이터 유지 관리 및 총 저장량 한도는 ClickHouse 테이블이 toDate(timestamp)로 파티션화되어 하루단위로 파티션화되어야한다는 점에 유의해야합니다.

(번역이 완료되지 않은 테이블 뒷부분을 제외하지 않고 안내하길 바랍니다.)

쿼리 API

쿼리 API는 쿼리 서비스에 의해 지원되며 UI로 다시 추적/스팬을 반환하는 중앙 집중식 가로 확장 가능한 컴포넌트로 책임을 질 것입니다. 이 쿼리 서비스의 좋은 시작점은 Jaeger 쿼리 서비스 코드와 Jaeger 쿼리 서비스 스웨거를 활용하는 것일 수 있습니다. 이 쿼리 서비스는 향후 메트릭 및 로그 지원이 포함되도록 확장되며 GitLab UI 내의 vue.js 코드에서 직접 쿼리될 것입니다.

GA의 노력 범위에는 두 가지 API가 포함됩니다. - /v1/traces는 이 사양을 준수합니다. - /v1/traces/{trace_ID}는 이 사양을 준수합니다.

인증 및 권한 부여

GitLab Observability Backend는 인스턴스 전체 신뢰할 수 있는 GitLab OAuth 토큰을 활용하여 신뢰할 수 있는 OAuth 흐름을 수행하여 GitLab 사용자를 GitLab Observability Backend (GOB)에 인증하는 데 사용합니다. GOB는 인증 세션을 만들고 해당 세션 식별자를 HTTP 전용 및 안전한 쿠키에 저장합니다. 이 메커니즘은 이미 AppSec에서 조사하고 승인했습니다. 이제 Observability UI가 GitLab.com에서 직접 호스팅되며 UI 내에 네이티브로 표시될 것이므로 이전에 의존했던 임베디드 iframe 대신에 새로운 UI 도메인에 대해 인증이 작동하도록 몇 가지 작은 조정이 필요합니다 (observe.gitLab.com 대신 GitLab.com).

숨겨진 iframe은 GitLab UI에만 임베드되며, GOB 인증된 API를 사용해야 하는 페이지에만 나타납니다. 이를 통해 GitLab.com UI는 중간 프록시 레이어나 덜 안전한 공유 토큰에 의존하지 않고 Rails에서 GOB API와 직접 통신할 수 있습니다. 이 iframe은 숨겨지며 해당 목적은 OAuth 흐름을 수행하고 GOB 사용자 세션을 포함하는 HTTP 전용 안전한 쿠키를 할당하는 것뿐입니다. 이 흐름은 신뢰할 수 있는 GitLab OAuth 흐름이기 때문에 사용자로부터 완전히 숨겨질 수 있습니다. 현재 세션은 GOB 배포 테라폼에서 구성 가능한 30일 후에 만료됩니다.

이 방법을 사용하여 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"와 함께 Ingress 구성
• Gatekeeper 컴포넌트에서 유효한 CSRF 보호가 활성화되어 있는지 확인 (Gatekeeper는 요청 승인을 담당함)

그런 다음 모든 GitLab.com 요청은 observe.gitLab.com이 유효한지 확인하기 위해 GOB 세션 쿠키를 포함할 것입니다. 권한은 Gatekeeper 컴포넌트에서 처리되며 해당 컴포넌트는 GitLab의 그룹/프로젝트 멤버십을 확인하고 알맞게 액세스를 처리합니다. 상속된 개발자 또는 해당 이상의 멤버십을 가진 사용자는 해당 프로젝트의 추적 UI에 액세스할 수 있습니다.

데이터베이스 스키마

ClickHouse용 커뮤니티 개발 OTEL 익스포터는 이미 추적 및 스팬을 저장하는 데이터베이스 스키마를 구현했습니다. ClickHouse의 블로그 게시물에서는 커뮤니티 개발된 익스포터에 대한 자세한 내용을 다루며, 실험 및 베타 단계에서 시험할 스키마 설계를 시작점으로 사용할 것을 의도하고 있습니다. 스키마 및 해당 SQL 쿼리에 대해 자세히 알아보기 위해 블로그 게시물을 읽는 것이 좋습니다.

UI 디자인

새로운 UI는 GitLab UX 디자인 표준에 따라 Pajamas 디자인 시스템을 사용하여 구축될 것입니다. UI는 vue.js를 통해 (위의 아키텍처 다이어그램 참조) 직접 GOB 쿼리 서비스와 상호 작용할 것입니다. 위에서 설명한 Authentication 및 Authorization 항목에서 자세한 내용을 확인하세요.

TODO Figma UI 디자인 및 설명

반복

16.2

• 그룹 CR에 연결된 모든 리소스를 테넌트 CR로 이관
• Clickhouse 익스포터를 포크하여 빌드
• 모든 추적/스팬에 project_ID 추가
• 그룹 수준이 아닌 프로젝트 수준에서 멤버십을 확인하는 게이트키퍼 추가
• 추적 디렉터리을 표시하는 기본 쿼리 서비스 구현 (필터링/검색 없음)
• 숨겨진 iframe 기반의 OAuth 메커니즘 구현 (GOUI에서 이미 수행한 것 재사용/조정)
• 추적 디렉터리을 위한 UI

16.3

• 필터링/검색 쿼리 서비스 (트레이스 ID, 서비스, 상태, 기간 최소/최대, 시작/종료 시간, 스팬 속성별)
• 프로젝트 액세스 토큰에 read_observability 및 write_observability 스코프 추가 및 프로젝트 액세스 토큰을 사용하여 프로젝트 수준 인게스트 API에 대한 지원 추가
• API 프로비저닝
• 기존의 iframe 프로비저닝 제거
• 추적 세부 정보를 위한 UI
• 추적 필터링/검색을 위한 UI
• 프로비젼, 데이터 전송, UI에서의 쿼리 기본 e2e 테스트
• 메트릭, 대시보드, 경보

16.4

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