내부 분석

내부 분석 시스템은 GitLab 인스턴스의 사용자 행동 및 시스템 상태를 추적할 수 있는 기능을 제공하여 고객 성공 서비스 및 추가 제품 개발에 도움을 줍니다.

이 문서 페이지는 새로운 기능을 개발하거나 기존 기능을 계측할 때 GitLab의 내부 분석 기능을 활용하는 방법에 대한 가이드와 정보를 제공합니다.

기본 개념

이벤트 및 메트릭의 개념에 대한 비디오를 확인하세요.

이벤트와 메트릭은 내부 분석 시스템의 기초입니다.

두 개념의 차이를 이해하는 것은 시스템을 사용하는 데 매우 중요합니다.

이벤트

이벤트는 GitLab 인스턴스 내에서 발생한 행동의 기록입니다.

예제 행동으로는 문제 페이지를 방문하거나 상단 내비게이션 검색 위에 마우스 커서를 올리는 사용자 상호작용이 있습니다.

다른 행동은 예약된 파이프라인 성공이나 3rd party 시스템의 API 호출 수신과 같은 백그라운드 시스템 처리가 결과로 이어질 수 있습니다.

모든 행동이 추적되어 자동으로 기록된 이벤트로 전환되는 것은 아닙니다.

대신, 행동이 제품 통찰력을 이끌어내고 더 정보에 입각한 비즈니스 결정을 내리는 데 도움이 되는 경우, 행동이 발생할 때 이벤트를 추적할 수 있습니다.

생성된 이벤트 기록은 최소한 행동이 발생했음을 나타내는 정보를 보유하지만,

이 행동과 함께한 컨텍스트에 대한 추가 세부 정보를 포함할 수도 있습니다.

컨텍스트의 예로는 행동을 수행한 사람에 대한 정보나 행동 당시 시스템의 상태가 있습니다.

메트릭

단일 이벤트 기록은 충분히 정보가 없으며 우연에 의해 발생할 수 있습니다.

분석의 기초가 되기 위해서는 공통 특성을 공유하는 이벤트의 집합을 찾아야 합니다.

여기서 메트릭이 등장합니다. 메트릭은 정보 조각에 대해 수행되는 계산입니다.

예를 들어, 신규 기능이 출시된 후 유료 사용자가 기능 페이지를 방문한 단일 이벤트는 이 신규 기능의 성공에 대해 아무것도 알려주지 않습니다.

그러나 신규 기능 출시 전 주에 발생한 페이지 뷰 이벤트 수를 계산한 후

기능 출시 후 주에 대한 이벤트 수와 비교하면,

신규 기능 출시로 인한 관심 증가에 대한 통찰력을 도출할 수 있습니다.

이 과정은 우리가 메트릭이라고 부르는 것으로 이어집니다. 이벤트 기반 메트릭은 특정 기간 동안 또는 전체적으로 이벤트가 발생한 횟수를 계산합니다.

같은 이벤트는 다양한 메트릭에서 사용될 수 있으며, 메트릭은 하나 이상의 이벤트를 셀 수 있습니다.

계산은 이벤트를 수행한 고유한 사용자만 계산하는 등의 고유성 기준에 기반할 수도 있지만, 반드시 그럴 필요는 없습니다.

메트릭은 이벤트에 기반할 필요는 없습니다. 메트릭은 GitLab 인스턴스 자체의 상태에 대한 관찰일 수도 있습니다,

예를 들어 설정의 값이나 데이터베이스 테이블의 행 수와 같은 것입니다.

계측

데이터 탐색

이벤트 및 메트릭 데이터는 궁극적으로 우리의 Snowflake 데이터 웨어하우스에 저장됩니다.

SQL을 통해 Snowflake에 직접 접근하여 애드혹 분석을 수행하거나 데이터 시각화 도구인 Tableau에서 시각화할 수 있습니다.

두 플랫폼 모두 접근 요청이 필요합니다 (Snowflake, Tableau).

참고: 브라우저에서 사용자 상호작용을 추적하려면 Do-Not-Track(DNT)를 비활성화해야 합니다. DNT는 대부분의 브라우저에서 기본적으로 비활성화되어 있습니다.

Tableau

Tableau는 데이터 시각화 플랫폼으로 대시보드와 GUI 기반 이벤트 및 메트릭 발견을 구축할 수 있습니다.

이 발견 방법은 비즈니스 인텔리전스 도구에 익숙한 사용자와 기본 검증 및 영구적이고 공유 가능한 대시보드와 시각화를 만드는 데 가장 적합합니다.

Tableau에 접근하려면 액세스 요청이 필요합니다.

이벤트 확인

Snowplow 이벤트 탐색 대시보드를 방문하세요.

이 대시보드는 이벤트 수와 가장 많이 발생한 이벤트를 보여줍니다.

하단으로 스크롤하여 “지난 30일 동안 프로덕션에서 발생한 구조화된 이벤트” 차트를 보고 특정 이벤트 동작에 대해 필터링할 수 있습니다. 필터는 정확한 이름으로만 작동합니다.

메트릭 확인

메트릭 탐색 대시보드를 방문할 수 있습니다.

측면에는 메트릭의 key_path에 해당하는 메트릭 경로 필터와 GitLab.com을 필터링하는 방법에 대한 안내가 포함된 설치 ID 필터가 있습니다.

커스텀 차트 및 대시보드

Tableau 내에서 이 펀넬 분석과 같은 더 고급 차트도 수행할 수 있습니다.

커스텀 차트와 대시보드는 제품 데이터 인사이트 팀에 그들의 프로젝트에서 이슈를 생성하여 요청할 수 있습니다.

Snowflake

Snowflake는 Snowflake SQL 방언으로 UI 내에서 관련 테이블을 직접 쿼리할 수 있습니다.

이 발견 방법은 SQL에 익숙한 사용자에게 가장 적합하며 데이터가 올바르게 전파되었는지 빠르고 유연하게 확인하는 데 유용합니다.

Snowflake에 접근하려면 액세스 요청이 필요합니다.

이벤트 쿼리

다음 예제 쿼리는 feature_used 이벤트의 일일 이벤트 발생 수를 반환합니다.

SELECT
  behavior_date,
  COUNT(*) as event_occurences
FROM prod.common_mart.mart_behavior_structured_event
WHERE event_action = 'feature_used'
AND behavior_date > '2023-08-01' -- 성능을 위한 제한된 최소 날짜
AND app_id='gitlab' -- 프로덕션 이벤트에는 gitlab을 사용하고 스테이징 이벤트에는 gitlab-staging을 사용
GROUP BY 1 ORDER BY 1 desc

다른 메트릭 테이블의 목록은 데이터 모델 치트 시트를 참조하세요.

메트릭 쿼리

다음 예제 쿼리는 지난 6개월 동안 count_distinct_user_id_from_feature_used_7d에 대해 보고된 모든 값을 반환하고 해당 instance_id를 반환합니다.

SELECT
  date_trunc('week', ping_created_at),
  dim_instance_id,
  metric_value
FROM prod.common.fct_ping_instance_metric_rolling_6_months -- 성능을 위해 지난 6개월로 제한된 모델
WHERE metrics_path = 'counts.users_visiting_dashboard_weekly' -- 관심 있는 메트릭으로 설정
ORDER BY ping_created_at DESC

다른 메트릭 테이블의 목록은 데이터 모델 치트 시트를 참조하세요.

제품 분석

내부 분석은 GitLab 제품 분석 기능을 사용하여 이벤트를 시각화할 수 있습니다.
분석 대시보드 문서화는 사용자 지정 시각화 및 대시보드를 구축하는 방법을 설명합니다.
GitLab 프로젝트 내에서 액세스할 수 있는 사용자 지정 대시보드는 별도의 리포지토리에 정의되어 있습니다.
내부 이벤트 시스템을 통해 계측된 이벤트를 기반으로 대시보드를 구축하는 것이 가능합니다. .com 설치에서 발생한 이벤트만 이러한 시각화에 포함됩니다.

제품 분석 그룹의 대시보드는 개별 이벤트를 기반으로 차트를 구축하는 방법에 대한 영감을 제공할 수 있습니다.

데이터 가용성

GitLab에는 GitLab.com과 자체 관리 또는 GitLab 전용 인스턴스 간에 분석 설정에 중요한 차이가 있습니다.

자체 관리 및 전용

자체 관리 및 전용 인스턴스에서는 사전 계산된 메트릭만 사용할 수 있습니다.
이러한 메트릭은 무작위로 선택된 날에 주 1회 계산되며, Service Ping이라는 프로세스를 통해 버전 앱으로 전달됩니다.
인스턴스가 실행 중인 버전까지 계측된 메트릭만 사용할 수 있습니다. 예를 들어, 메트릭이 버전 16.9 개발 중에 계측되면 16.9 이상의 버전을 실행 중인 인스턴스에서는 사용할 수 있지만 16.8과 같은 이전 버전을 실행 중인 인스턴스에서는 사용할 수 없습니다.
수신된 페이로드는 하루에 한 번 데이터 웨어하우스로 가져옵니다.

GitLab.com

우리의 GitLab.com 인스턴스에서는 개별 이벤트와 사전 계산된 메트릭 모두 분석을 위해 사용할 수 있습니다. 또한 페이지 뷰는 자동으로 계측됩니다.

개별 이벤트 및 페이지 뷰

개별 이벤트와 페이지 뷰는 직접적으로 수집 인프라로 전달되며, 거기에서 데이터 웨어하우스로 들어갑니다.
그러나 이 단계에서 데이터는 쿼리하기 어려운 원시 형식입니다. 이런 이유로 데이터를 정리하고 웨어하우스를 통해 전파하여 데이터 검색 섹션에서 지적한 테이블과 도표에서 사용할 수 있게 됩니다.

전파 프로세스는 완료되는 데 여러 시간이 걸립니다. 다음 다이어그램은 이벤트의 가용성을 보여줍니다:

GitLab.com에서 이벤트 수집 및 전파의 타임라인

출처

사전 계산된 메트릭

메트릭은 자체 관리와 마찬가지로 주 1회 계산되지만, 가장 큰 차이점은 대부분의 계산이 인스턴스가 아닌 웨어하우스 내에서 이루어진다는 점입니다.
GitLab.com의 경우 이 프로세스는 월요일 아침에 시작되어 일요일 23:59 UTC부터 이번 일요일 23:59 UTC까지의 시간 범위에 대한 메트릭을 계산합니다.

다음 다이어그램은 프로세스를 보여줍니다:

GitLab.com에서 Service Ping 계산의 타임라인

출처

데이터 흐름

SaaS 이벤트 기록은 Snowplow라고 불리는 수집 시스템으로 직접 전송되며, 우리의 데이터 웨어하우스에 가져와집니다.

Self-managed 및 GitLab Dedicated 인스턴스는 이벤트 수를 로컬에 기록합니다. 매주 Service Ping이라는 프로세스가 모든 미리 정의된 활성 메트릭의 현재 값을 데이터 웨어하우스로 전송합니다. GitLab.com의 경우, 메트릭은 데이터 웨어하우스에서 직접 계산됩니다.

다음 차트는 이 데이터 흐름을 설명하는 것을 목표로 합니다:

flowchart LR; feature-->track track-->|이벤트 기록 전송 - gitlab.com에서만|snowplow track-->|메트릭 카운트 증가|redis database-->service_ping redis-->service_ping service_ping-->|메트릭 값이 포함된 json - 주간 내보내기|snowflake snowplow-->|이벤트 기록 - 지속적인 가져오기|snowflake snowflake-->vis subgraph glb[Gitlab 애플리케이션] feature[기능 코드] subgraph events[내부 분석 코드] track[track_event / trackEvent] redis[(Redis)] database[(데이터베이스)] service_ping[\Service Ping 프로세스\] end end snowplow[\Snowplow 파이프라인\] snowflake[(Snowflake 데이터 웨어하우스)] vis[Tableau 대시보드]

데이터 개인 정보 보호

GitLab은 self-managed 인스턴스에서 이벤트 수 또는 유사한 집계 정보만 수신합니다. GitLab의 SaaS 버전에서 개별 이벤트에 대한 사용자 식별자는 가명 처리(pseudonymized)됩니다.

내부 분석 시스템을 통해 어떤 종류의 데이터가 수집되는지에 대한 정확한 설명은 우리의 핸드북에 나와 있습니다.

기여 지침