메트릭 수명 주기
GitLab v19.1다음 가이드라인은 메트릭 수명 주기의 각 단계에서 따라야 할 절차를 설명합니다. 메트릭의 계산 로직이나 중요한 속성의 변경은 방지하고자 합니다. 메트릭을 변경하는 경우, 모든 GitLab 인스턴스가 최신 버전으로 실행되고 있지 않을 수 있다는 점을 고려해야 합니다.
다음 가이드라인은 메트릭 수명 주기의 각 단계에서 따라야 할 절차를 설명합니다.
새 메트릭 추가#
메트릭 계측 가이드를 따르세요.
기존 메트릭 변경#
메트릭의 계산 로직이나 중요한 속성의 변경은 방지하고자 합니다. 이를 변경하면 GitLab의 서로 다른 버전 간 동일 메트릭 비교가 무효화되기 때문입니다.
메트릭을 변경하는 경우, 모든 GitLab 인스턴스가 최신 버전으로 실행되고 있지 않을 수 있다는 점을 고려해야 합니다. 구버전 인스턴스는 계속해서 이전 버전의 메트릭을 보고합니다. 또한, 메트릭의 보고된 수치는 주로 이전에 보고된 수치와 비교할 때 의미가 있습니다. 따라서 메트릭의 다음 항목 중 하나를 변경해야 하는 경우, 기존 메트릭을 변경하는 대신 새 메트릭을 추가해야 합니다. 기존 메트릭을 새 메트릭과 함께 유지할지, 아니면 제거할지는 선택 사항입니다.
-
계산 로직: 이전 구현과 다른 값을 생성할 수 있는 모든 변경 사항
-
YAML 속성: 다음 속성들은 분석이나 계산에 직접 사용됩니다:
key_path,time_frame,value_type,data_source.
메트릭의 performance_indicator_type 속성을 변경하거나 위에 명시된 규칙의 예외가 필요하다고 판단되는 경우, 머지 리퀘스트 또는 이슈의 댓글에서 해당 그룹을 @ 멘션하여 Customer Success Ops 팀(@csops-team), Analytics Engineers(@gitlab-data/analytics-engineers), Product Analysts(@gitlab-data/product-analysts) 팀에 알리세요.
계산이나 분석에 영향을 주지 않고 다른 속성들은 변경할 수 있습니다. 메트릭 속성 업데이트에 도움이 되는 이 동영상 튜토리얼을 참조하세요.
현재 Metrics Dictionary는 하루에 한 번 자동으로 빌드됩니다. 메트릭의 YAML 파일을 변경하면 24시간 이내에 딕셔너리에서 변경 사항을 확인할 수 있습니다.
메트릭 제거#
- 아직 이슈가 없다면, 메트릭 제거를 위한 이슈를 생성하세요. 이슈에는 해당 메트릭을 제거해야 하는 이유가 포함되어야 합니다. 이 이슈를 제거 프로세스를 문서화하는 데 사용할 수 있습니다.
메트릭에 [x]mau 또는 customer_health_score 유형의 performance_indicator_type이 하나 이상 있는 경우:
이슈의 댓글에서 해당 그룹을 @ 멘션하여 Customer Success Ops 팀(@csops-team), Analytics Engineers(@gitlab-data/analytics-engineers), Product Analysts(@gitlab-data/product-analysts)에 알리세요. 이러한 메트릭이 예기치 않게 변경되면 리포팅이 중단될 수 있습니다.
-
메트릭이 제거를 수행하는 그룹이 아닌 다른 그룹이 소유한 경우: stages 파일에 따라 소유 그룹의 PM과 EM을 태그하세요.
-
data_source에 따라 메트릭 계측 코드를 제거합니다:
database/system: 메트릭에 instrumentation_class가 있고 해당 클래스가 다른 메트릭에서 더 이상 사용되지 않는 경우 클래스와 스펙을 제거할 수 있습니다.
메트릭이 lib/gitlab/usage_data.rb
또는 ee/lib/ee/gitlab/usage_data.rb 내에서 계측된 경우, 관련 코드와 스펙을 제거하세요
(예시).
-
redis_hll/redis/internal_events: 추적 코드(예:track_internal_event)와 관련 스펙을 제거하세요. -
메트릭 YAML 정의의 속성을 업데이트합니다:
status:를 removed로 설정합니다.
-
removed_by_url:을 메트릭을 제거하는 MR의 URL로 설정합니다. -
milestone_removed:를 메트릭이 제거된 마일스톤 번호로 설정합니다.
메트릭의 YAML 정의를 완전히 제거하지 마세요. 일부 GitLab Self-Managed 인스턴스는 즉시 최신 버전의 GitLab으로 업데이트하지 않을 수 있으며, 따라서 제거된 메트릭을 계속 보고할 수 있습니다. Analytics Instrumentation 팀은 제거된 메트릭을 식별하고 필터링하기 위해 모든 제거된 메트릭의 기록이 필요합니다.
그룹 이름 변경#
이벤트나 메트릭을 소유하는 그룹의 이름이 변경되면, 해당 그룹에 속한 모든 메트릭 및 이벤트 정의에서 product_group 속성을 업데이트해야 합니다.
product_group_renamer 스크립트를 사용하면 수동으로 작업하지 않고 모든 정의를 업데이트할 수 있습니다.
예를 들어, 그룹 5-min-app이 2-min-app으로 이름이 변경된 경우 다음과 같이 관련 파일을 업데이트할 수 있습니다:
$ scripts/internal_events/product_group_renamer.rb 5-min-app 2-min-app
Updated '5-min-app' to '2-min-app' in 3 files
Updated files:
config/metrics/schema/product_groups.json
config/metrics/counts_28d/20210216184517_p_ci_templates_5_min_production_app_monthly.yml
config/metrics/counts_7d/20210216184515_p_ci_templates_5_min_production_app_weekly.yml
스크립트를 실행한 후 수정된 모든 파일을 Git에 커밋하고 머지 리퀘스트를 생성해야 합니다.
이 스크립트는 GDK의 일부이며 프론트엔드 또는 백엔드 개발자가 스크립트를 실행하고 머지 리퀘스트를 준비할 수 있습니다.
그룹이 여러 그룹으로 분할되는 경우, product_group을 수동으로 업데이트해야 합니다.