메트릭 라이프사이클

다음 지침은 메트릭 라이프사이클 각 단계에서 따를 단계를 설명합니다.

새로운 메트릭 추가

메트릭 인스트루먼테이션 가이드를 따르세요.

기존 메트릭 변경

경고: 새로운 버전의 GitLab에서 동일한 메트릭을 비교하는 것을 무효화시키므로 계산 로직이나 중요한 속성을 변경하는 것을 방지하고자 합니다.

메트릭을 변경하면 GitLab의 모든 인스턴스가 최신 버전이 아닐 수 있다는 점을 고려해야 합니다. 이전 버전의 인스턴스는 여전히 이전 버전의 메트릭을 보고할 것입니다. 또한, 메트릭의 보고된 숫자는 주로 이전에 보고된 숫자와 비교하는 것이 주된 관심사입니다. 결과적으로, 메트릭의 다음 부분 중 하나를 변경해야 하는 경우 새로운 메트릭을 추가해야 합니다. 이전 메트릭을 유지할지 새로운 메트릭과 함께 유지할지 여부는 당신의 선택입니다. 또는 제거할 수도 있습니다.

  • 계산 로직: 이전 구현과 다른 값을 생성할 수 있는 변경 사항
  • YAML 속성: 다음 속성은 직접 분석이나 계산에 사용됩니다: key_path, time_frame, value_type, data_source.

만약 메트릭의 performance_indicator_type 속성을 변경하거나 규칙에서 벗어나는 경우에는 이를 병합 요청이나 이슈의 코멘트에서 @csops-team, @gitlab-data/analytics-engineers, @gitlab-data/product-analysts 팀에 알려주시기 바랍니다.

계산 또는 분석에 영향을 미치지 않는 다른 속성은 자유롭게 변경할 수 있습니다. 메트릭 속성 업데이트에 도움이 되는 이 비디오 튜토리얼을 참조하세요.

현재 메트릭사전은 매일 자동으로 작성됩니다. 메트릭의 YAML 파일을 변경하면 24시간 이내에 사전에 반영됩니다.

메트릭 제거

  1. 메트릭을 제거하는 문제가 아직 없는 경우 문제를 만드세요. 메트릭 제거 이유를 개요해야 합니다. 이 문제를 사용하여 제거 프로세스를 문서화할 수 있습니다.

    • 메트릭이 하향 시스템에서 의존성이 없는지 확인하려면 Customer Success Ops 팀 (@csops-team)과 Analytics Engineers (@gitlab-data/analytics-engineers)에게 공지하세요.
    • 메트릭에 [x]mau 종류의 performance_indicator_type가 최소 하나 이상 있는 경우: 이 메트릭에 대한 예상치 못한 변경이 보고를 망가뜨릴 수 있으므로 이상 제품 분석가(@gitlab-data/product-analysts)에게 이슈 코멘트에서 알려주세요.
    • 메트릭이 제거를 수행하는 그룹과 소유 그룹이 다른 경우: 단계 파일에 따라 소유 그룹의 PM 및 EM에게 태그를 달아주세요.

  2. 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)와 연관된 스펙을 제거하세요.

  3. 메트릭의 YAML 정의 속성을 업데이트하세요:

    • 상태:를 제거됨으로 설정하세요.
    • removed_by_url:을 메트릭을 제거하는 MR의 URL로 설정하세요.
    • milestone_removed:를 메트릭이 제거된 마일스톤 숫자로 설정하세요.

    메트릭의 YAML 정의 자체를 제거하지 마세요. 일부 자기 관리형 인스턴스는 즉시 GitLab의 최신 버전으로 업데이트되지 않을 수 있으며, 따라서 제거된 메트릭을 계속해서 보고할 것입니다. 분석 인스트루멘테이션 팀은 모든 제거된 메트릭의 레코드를 식별하고 필터링하기 위해 필요합니다.