내부 분석

내부 분석 시스템은 GitLab 인스턴스의 사용자 동작 및 시스템 상태를 추적하여 고객 성공 서비스 및 제품 개발을 위한 정보를 제공합니다.

이 문서 페이지들은 신규 기능을 개발하거나 기존 기능에 계기를 도입할 때 GitLab의 내부 분석 기능을 최대한 활용하는 방법에 대한 안내 및 정보를 제공합니다.

기본 개념

이벤트 및 메트릭스 개념에 대한 비디오를 보세요.에 대한 동영상을 확인하세요.

이벤트와 메트릭스는 내부 분석 시스템의 기반입니다. 이 두 가지 개념의 차이를 이해하는 것은 시스템을 사용하는 데 중요합니다.

이벤트

이벤트는 GitLab 인스턴스 내에서 발생한 동작의 기록입니다. 사용자 상호 작용(예: 이슈 페이지 방문 또는 상단 네비게이션 검색 위에 마우스 커서를 두는 것)과 같은 동작이 하나의 예입니다. 다른 동작은 스케줄된 파이프라인 성공 또는 3rd party 시스템에서의 API 호출과 같은 백그라운드 시스템 처리로부터 발생할 수 있습니다. 모든 동작이 추적되어 기록된 이벤트로 자동으로 변환되는 것은 아닙니다. 대신, 동작이 제품 통찰을 도출하고 더 훈련된 비즈니스 결정을 내릴 수 있도록 도와주면, 해당 동작이 발생할 때 이벤트를 추적할 수 있습니다. 생성된 이벤트 레코드는 최소한 해당 동작이 발생한 사실에 대한 정보를 포함하며, 해당 동작과 함께 발생한 상황에 대한 추가적인 세부 정보를 포함할 수도 있습니다. 상황의 예로는 누가 해당 동작을 수행했는지 또는 해당 동작이 발생한 시스템의 상태에 대한 정보 등이 있습니다.

메트릭스

단일 이벤트 레코드 자체만으로는 충분한 정보를 제공하지 못하고 우연히 발생할 수 있습니다. 분석의 기초를 마련하기 위해 공통 특성을 가진 이벤트 집합을 찾아야 합니다. 이것이 메트릭스가 필요한 이유입니다. 메트릭스는 정보 조각에 대해 수행된 계산입니다. 예를 들어, 새로운 기능을 출시한 후 유료 사용자가 해당 기능 페이지를 방문하는 단일 이벤트의 기록은 새로운 기능의 성공에 대해 아무것도 알려주지 않습니다. 그러나 새로운 기능 출시 전 주의 페이지 뷰 이벤트 수를 계산하고, 그 후 주의 이벤트 수와 비교할 경우, 새로운 기능 출시로 인한 관심 증가에 대한 통찰을 얻을 수 있습니다.

이 프로세스는 우리가 메트릭스라고 부르는 것으로 이어집니다. 이벤트 기반 메트릭스는 특정 기간 전반 또는 지정된 시간 프레임 내에 이벤트가 발생한 횟수를 계산합니다. 같은 이벤트는 서로 다른 메트릭스에서 사용될 수 있으며 메트릭스는 하나 또는 여러 이벤트를 계산할 수 있습니다. 횟수는 고유성 기준에 따라 기반을 둘 수도 있지만, 필수는 아닙니다. 즉, 동작을 수행한 고유한 사용자만을 계산할 수도 있고 않을 수도 있습니다.

메트릭스는 반드시 이벤트에 기반할 필요는 없습니다. 메트릭스는 GitLab 인스턴스 자체의 상태에 관한 관측치일 수도 있습니다. 예를 들어, 설정의 값 또는 데이터베이스 테이블의 행 수 등입니다.

계기 설정

데이터 이용 가능성

GitLab의 경우 SaaS와 Self-Managed 또는 GitLab 전용 인스턴스 간에 분석 설정에 중요한 차이점이 있습니다. SaaS 인스턴스의 경우 개별 이벤트 및 사전 계산된 메트릭스를 분석할 수 있습니다. 또한 SaaS의 경우 페이지 조회 수가 자동으로 계기화됩니다. Self-Managed의 경우 설치된 GitLab 버전에 계기화된 메트릭만 사용할 수 있습니다.

이벤트

이벤트는 실시간으로 수집되지만 비동기적으로 처리됩니다. 일반적으로 이벤트는 발생한 후 최대 48시간 이후에 데이터 웨어하우스에서 사용할 수 있으며, 일찍 사용할 수도 있습니다.

메트릭스

메트릭스는 매주 한 번 계산되어 인스턴스 당 한 번 전송됩니다. GitLab.com의 경우 이 일정은 일요일에 설정되며, 새로운 값은 월요일 내내 사용할 수 있게 됩니다. Self-Managed의 경우 특정 인스턴스에 따라 상황이 다릅니다. 일반적으로 설치된 GitLab 버전에 대해 계기화된 메트릭만 전송됩니다.

데이터 검색

이벤트 및 메트릭스 데이터는 궁극적으로 우리의 Snowflake 데이터 웨어하우스에 저장됩니다. 할당된 분석을 위한 권한을 통해 직접 SQL로 액세스하거나, 데이터 시각화 도구인 Tableau로 시각화할 수 있습니다. 두 플랫폼 모두 액세스 요청(Snowflake,Tableau)이 필요합니다.

Tableau

Tableau은 데이터 시각화 플랫폼으로 대시보드 및 GUI 기반 이벤트 및 메트릭의 발견을 가능하게 합니다. 이러한 발견 방법은 비즈니스 인텔리전스 도구, 기본적인 검증 및 지속적이고 공유 가능한 대시보드 및 시각화를 생성하는 데 익숙한 사용자에게 가장 적합합니다. Tableau에 액세스하려면 액세스 요청이 필요합니다.

이벤트 확인

Snowplow 이벤트 탐색 대시보드를 방문하세요. 이 대시보드는 이벤트 수와 가장 많이 발생한 이벤트를 보여줍니다. “Structured Events Firing in Production Last 30 Days” 차트로 스크롤하고 특정 이벤트 작업에 대해 필터링할 수 있습니다. 필터는 정확한 이름으로만 작동합니다.

메트릭 확인

메트릭 탐색 대시보드를 방문할 수 있습니다. 키 경로(metric path)에 대한 필터와 GitLab.com에 대한 필터링 지침을 포함한 설치 ID에 대한 필터가 있습니다.

Snowflake

Snowflake는 Snowflake SQL 방언을 사용하여 웨어하우스에서 관련 테이블을 직접 쿼리하는 것을 가능하게 합니다. 이러한 발견 방법은 SQL에 익숙하고 데이터가 올바르게 전파되었는지 빠르고 유연하게 확인하는 데 적합합니다. Snowflake에 액세스하려면 액세스 요청이 필요합니다.

이벤트 쿼리

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

SELECT
  behavior_date,
  COUNT(*) as event_occurences
FROM 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 common.fct_ping_instance_metric_rolling_6_months --성능을 위해 마지막 6개월로 제한된 모델
WHERE metrics_path = 'counts.users_visiting_dashboard_weekly' --관심있는 메트릭으로 설정
ORDER BY ping_created_at DESC

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

데이터 흐름

SaaS 이벤트 레코드는 직접 Snowplow라는 수집 시스템으로 전송되고 데이터 웨어하우스로 가져옵니다. Self-managed 및 GitLab 전용 인스턴스는 로컬에서 이벤트 카운트를 기록합니다. 매주 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)됩니다. 내부 사용 분석 시스템을 통해 수집되는 데이터 유형에 대한 정확한 설명은 핸드북에서 제공됩니다.