This page contains information related to upcoming products, features, and functionality. It is important to note that the information presented is for informational purposes only. Please do not rely on this information for purchasing or planning purposes. The development, release, and timing of any products, features, or functionality may be subject to change or delay and remain at the sole discretion of GitLab Inc.
Status Authors Coach DRIs Owning Stage Created
proposed @ankitbhatnagar @mappelman @sguyon @nicholasklick monitor observability 2022-11-09

GitLab Observability - 메트릭

요약

일반적으로 OpenTelemetry과 Clickhouse를 사용하여 포맷된 다양한 산업 표준 형식을 저장하고 쿼리하는 다중 사용자 시스템을 개발하여 장기 데이터 보존 및 집계를 지원합니다.

동기

가능한 일선 시스템의 운영 포지션에 대한 통찰력을 사용자에게 제공하여 현대 시스템에서 가장 중요한 옵저버빌리티의 여섯 가지 기둥 중 하나로서 메트릭은 모니터링된 시스템의 운영 상태에 대한 통찰력을 사용자에게 제공하는 데 도움이 되는데 있습니다.

시계열 데이터로 일반적으로 구성된 메트릭은 다음과 같은 특성을 가지고 있습니다:

  • 해당 타임스탬프로 색인화됩니다.
  • 지속적으로 크기가 확장됩니다.
  • 일반적으로 집계, 다운샘플링 및 범위별로 쿼리됩니다.
  • 매우 쓰기 집중적인 요구 사항이 있습니다.

GitLab Observability Backend 내에서 우리는 고객이 시스템 및 응용 프로그램에 대한 옵저버빌리티 데이터를 수용하고 쿼리할 수 있도록 지원할 것입니다. 그들이 시스템의 운영 상태를 개선하는 데 도움이 되기를 희망합니다.

목표

제안된 시스템을 개발하는 데 있어 우리의 목표는 다음과 같습니다:

  • 반복 가능한 벤치마크를 통해 성능이 증명된 Clickhouse를 백엔드로 사용하는 확장 가능하고 저지연 및 비용 효율적인 모니터링 시스템.

  • 오픈텔레미터 호환 에이전트를 통해 수신된 메트릭의 장기 리포지터리를 지원하고 GitLab 네이티브 UI를 통한 쿼리를 지원하며 메타데이터 및 사례를 지원할 가능성이 높습니다.

상기한 목표는 다음의 네 가지 하위 목표로 분해될 수 있습니다:

데이터 수용

  • 시스템이 대량의 쓰기 및 읽기를 수용할 수 있도록 하기 위해 수평 확장 가능하고 수용 후 내림차순 검증을 보장하여 쓰기가 수용되지 않도록 해야 합니다.

데이터 지속

  • 오픈텔레미터 사양을 사용하여 메트릭 계측된 텔레메트리/데이터를 저장하는 지원을 목표로 합니다. 첫 번째 반복에서는 데이터 세트에 대한 모든 영향력에서 기본적으로 multi-tenant이며 동일한 리포지터리 백엔드 내에서 여러 그룹/프로젝트의 옵저버빌리티 데이터를 저장할 수 있도록 보장합니다.

데이터 읽기

  • GitLab 네이티브 UX를 통한 데이터 쿼리를 지원할 것입니다. 이는 사용자 정의 DSL/쿼리 빌더를 사용하여 GitLab에서 API 요청을 보내고 이를 Clickhouse SQL로 변환하는 것을 의미합니다. 내부적인 논의를 통해 Product Analytics Visualisation Designer가 이에 대한 영감의 출처이기도 합니다.

데이터 삭제

  • 필요한 경우 수용된 데이터를 삭제하는 것을 지원할 것입니다. 또한 구성된 TTL이 만료되거나 관련 보존 정책이 시행될 때 데이터를 자연적으로 삭제하는 것 외에, 스키마 내에서 레이블 또는 콘텐츠별로 데이터를 삭제하는 방법을 구축하고 해당 작업을 수행하는 데 필요한 도구를 제공할 예정입니다.

비목표

상기 목표를 설정한 상태에서 현재 제안을 통해 특정 사항이 비목표인지 확인하고자 합니다. 그것은 다음과 같습니다:

  • 첫 번째 반복에서는 PromQL을 사용한 텔레메트리 쿼리를 지원하지 않을 것입니다. 그 비즈니스적 요구가 발생할 때까지 연기할 것입니다. 그러나 사용자들은 Prometheus 메트릭의 경우 OpenTelemetry Line Protocol (OTLP), 예를들어 Prometheus Receiver를 통해 메트릭을 수용할 수 있을 것입니다.

제안

우리는 메트릭 구현에 대한 GitLab 옵저버빌리티 백엔드(GOB)를 사용함으로써 이미 우리의 백엔드의 기존 구성요소를 통해 라이프사이클을 관리할 수 있도록 합니다.

아키텍처

위 다이어그램에서 OTEL-수집기, 인덱서 및 쿼리 서비스는 여기서 제안된 대로 개발되어야 할 구성요소입니다. 나머지 주변 요소들은 이미 존재하거나 GOB 내 중앙 집중식 scheduler의 기존 코드를 통해 사전에 제공될 수 있습니다.

쓰기 경로에서:

  • 우리는 기존 서비스인 errortracking, tracing과 유사한 방식으로 HTTP/JSON을 통해 들어오는 데이터를 기대합니다.

  • 수용하기 이전에 타임시리즈를 매우 중복되지 않도록 하기 위해 각 시리즈 메타데이터를 인덱싱/캐싱하여 우리의 저장 공간을 줄이는 것을 목표로 합니다.

  • Clickhouse에 작성하기 전에 데이터를 배치 처리하여 많은 양의 작은 쓰기가 되지 않도록 하는 것이 목표입니다.

읽기 경로에서:

메트릭 읽기 경로

  • 우리는 사용자가 수용된 데이터를 읽을 수 있도록 허용할 것입니다. 이는 GitLab에서 발생하는 API 요청을 네이티브 UI에서 서비스 할 수 있도록 하기위해 백엔드에 전용 쿼리 서비스를 구축하는 것이 필요할 것입니다.

  • 포함된 시스템이 항상 원활한 운영 상태를 유지하기 위해 리소스 소비에 대한 필요한 쿼리 유효성 검증, 살균 및 제한 처리를 구현하는 것이 목표입니다.

GitLab 옵저버빌리티 테넌트

특히 그라파나 기반 UX의 사용을 폐기하는 최근 백엔드 디자인 변경을 통해 시스템 내에서 테넌트를 프로비저닝하는 방법을 최적화할 수 있는 기회를 파악하게 되었습니다. 이러한 이니셔티브로써 우리는 높은 수준의 GitLab 네임스페이스마다 dedicate된 Ingress 및 Ingester 인스턴스를 배포하여 해당 테넌트가 해당 그룹 및 프로젝트의 트래픽 양에 따라 확장될 수 있도록 합니다. 또한 여러 테넌트의 리소스 소비를 분리함으로써 우리와 같은 다중 테넌트 시스템 내에서 리소스 소비를 격리하는 데 도움됩니다.

시리즈 메타데이터에 대한 인덱싱

우리는 Ingester의 내부 부분으로써 닫혀있을 시리즈 레이블 및/또는 메타데이터를 인덱싱하여 들어오는 시계열 데이터를 중복 제거하고 메타데이터 및 포인트 데이터로 분류하는 것이 목표입니다. 종합된 데이터는 Query Service에 의해 효율적으로 모든 들어오는 읽기 요청의 시계열을 계산하는 데 사용될 수 있습니다. 우리 아키텍처의 이 부분은 제안: 효율적으로 시계열 데이터를 중복 제거하고 쿼리하기 위한 메트릭 레이블 인덱싱에서 더 자세히 설명되어 있습니다.

쿼리 서비스

쿼리 서비스는 두 가지 주요 구성요소로 이루어져 있습니다. 1. 요청 파서 & 2. 백엔드별 쿼리 구현체입니다. 요청 경로에서 할당된 엔드포인트로 들어온 후, 요청 파서의 일부인 핸들러에 의해 처리됩니다. 파서의 책임은 들어오는 쿼리 페이로드를 unmarshal하고 내용을 유효성 검사하여이 쿼리/요청이 어떻게 처리되어야 하는지를 설명하는 SearchContext 개체를 만드는 것입니다. SearchContext 개체 내에는 하나 이상의 Query 개체를 정의하는 QueryContext 속성이 또한 포함되어 있습니다. 이것은 모두 백엔드 중 하나에 대한 완전히 독립적인 데이터 쿼리입니다.

쿼리 서비스 내부

API 구조

사용자를 위한 API에 대해서는 사용자측 쿼리가 요청 본문 내의 페이로드로 마샬된 HTTP/JSON 엔드 포인트를 통해 지원할 것입니다. 예를 들어, 메트릭:apiserver_request_total의 수분 간견 델타의 합을 모든 label:instance의 값에 대해 계산하려면 다음과 같이 요청 본문에 POST 요청을 보낼 수 있습니다 https://observe.gitlab.com/query/$GROUP/$PROJECT/metrics: 

{
  "queries": {
    "A": {
      "type": "metrics",
      "filters": [
        {
          "key": "__name__",
          "value": "apiserver_request_total",
          "operator": "eq"
        }
      ],
      "aggregation": {
        "function": "rate",
        "interval": "1m"
      },
      "groupBy": {
        "attribute": [
          "instance"
        ],
        "function": "sum"
      },
      "sortBy": {},
      "legend": {}
    }
  },
  "expression": "A"
}

AST로 쿼리 표현 

type SearchContext struct {
  UserContext    *UserContext    `json:"authContext"`
  BackendContext *BackendContext `json:"backendContext"`
  
  StartTimestamp      int64 `json:"start"`
  EndTimestamp        int64 `json:"end"`
  StepIntervalSeconds int64 `json:"step"`
  
  QueryContext       *QueryContext          `json:"queryContext"`
  CorrelationContext *CorrelationContext    `json:"correlationContext"`
  Variables          map[string]interface{} `json:"variables,omitempty"`
}

일반적으로 말하자면:

  • SearchContext는 검색을 실행해야 하는 방법을 정의합니다.
    • 내부적으로는 QueryContext를 포함하며, 이는 특정 백엔드를 대상으로 하는 하나 이상의 Query(s)를 가리킵니다.
    • 각 Query는 독립적으로 구문 분석되고 처리되어야 하며, QueryContext 또는 SearchContext 내의 기타 공통 속성으로 보완되어야 합니다.
  • Query는 쿼리를 수행하는 방법을 설명하는 AST 유사한 개체를 정의합니다.
    • 명시적으로 스키마에 구애받지 않으며, 시스템 내외에서 직렬화되고 전달될 수 있도록 의도되어 있습니다.
    • 또한 쿼리 엔티티에 대한 내부 데이터 모델링의 세부 정보를 숨기는 추상화입니다.
    • 들어오는 쿼리가 Query 개체로 구문 분석되고 유효성이 검증될 수 있다고 가정한다면, Querier는 해당 쿼리에 대한 검색/쿼리를 실행할 수 있습니다.
  • UserContext는 요청이 검색 대상 데이터에 액세스하는 지를 정의합니다.
    • 이것은 아마도 요청 할당량, 요청 제한 등을 모델링하고 시행하는 좋은 장소일 수 있습니다.
    • 이 속성의 일부를 채우는 것은 API 게이트웨이 또는 Gatekeeper를 통해 기타 전역 상태를 읽는 구문 분석기가 의존합니다.
  • BackendContext는 요청이 처리되어야 하는 백엔드를 정의합니다.
    • 멀티테넌트 환경에서 적절한 백엔드로 요청을 라우팅하는 데 도움이 됩니다.
    • 그러나 현재 이터레이션에서는 아키텍처와 동일하게 하나의 백엔드만 작업할 것을 의도하고 있습니다.
  • CorrelationContext는 여러 쿼리가 서로 관련되어 앞단에서 일관된 보기를 작성할 수 있는 방법을 정의합니다.
    • 그러나 현재 이터레이션에서는 빈 채로 유지하고 나중에 상관 벡터를 추가하기만 할 것을 의도하고 있습니다.

의도된 대상 환경

현재 운영 구조에 따라, 메트릭 오퍼링을 GitLab Observability Backend의 일부로 배포할 것을 의도하며, 다음 두 대상 환경에 배포할 것입니다:

  • kind 클러스터 (로컬 개발용)
  • GKE 클러스터 (스테이징/프로덕션 환경용)

프로덕션 준비도

배치 처리

Clickhouse로 대량의 소규모 쓰기를 입력하기 전에 데이터를 배치 처리해야 하므로, 설계는 성능을 향상시키고 테이블 엔진이 데이터를 계속 성공적으로 유지할 수 있도록 사전 결정된 크기의 일괄 처리로 Clickhouse에 데이터를 착륙하기 전에 들어오는 데이터를 로컬로 배치 할 수 있도록 앱 내부 영속성을 고려해야 합니다.

우리는 앱 내부 배치를 구현하기 위해 다음과 같은 대체 방안을 고려했습니다:

  • 인메모리 - 비내구성
  • BadgerDB - 내구성, 내장형, 성능 우수
  • Redis - 사소하지만 외부 의존성 있음
  • Kafka - 중요하지 않으나, 외부 의존성이 있으며 기타 문제 영역을 보완하고 GitLab에서 다른 문제 도메인에 도움을 줄 수 있음

참고: 이와 유사한 도전 과제는 현재 구현된 CH 상호 작용 errortracking과 함께 나타났습니다. 과거에 이 문제 영역을 해결하기 위한 여러 시도가 있었으며, 이 MR는 인메모리 대안을 구현하였으며, 이것은 온디스크 대안을 시도했습니다.

이 영역의 작업은 errortracking, 로깅 등과 같은 기타 서브시스템에도 도움이 될 것입니다.

확장성

우리는 초기 가설을 테스트/확립하기 위해 초당 10K 메트릭 포인트로 제안된 구현을 테스트 시작하고자 합니다. 그러나 이상적으로는 초당 1M 포인트를 처리하기 위해 백엔드를 설계해야 할 것입니다.

벤치마킹

제안된 구현을 벤치마킹 하는 동안 다음 세 가지 측면을 테스트하는 것을 제안합니다:

  • 데이터 수집 성능 (기능적)
  • 평균 쿼리 응답 시간 (기능적)
  • 리포지터리 요구 사항 (운영적)

성능을 이해하기 위해 테스트할 데이터 요청에 대한 디렉터리을 먼저 컴파일해야 할 것입니다. 클릭하우스 쿼리 로깅은 이 작업을 수행하는 데 매우 유용합니다.

참고: 이상적으로 시스템을 벤치마킹하여 초당 1M 메트릭 포인트 이상을 수집하고 대부분의 쿼리를 일관되게 < 1초 안에 처리할 수 있도록 만들고자 합니다.

과거 작업 및 참고 자료

비용 추정

  • 시스템이 텔레메트리 데이터를 입력 및 쿼리하는 데 사용자에게 비용 효율적이라고 확신합니다. 기본 비용에 영향을 미치는 중요한 요소 중 하나는 입수된 데이터를 모델링하고 저장하는 방법이며, 의도된 제안은 데이터 중복성을 줄이고 사용되지 않는 메트릭을 가시화하기 위해 다듬기 등의 조치를 최적화해야 합니다.

  • 특히 다음과 같은 여러 저장 매체의 사용을 고려해야 할 것입니다:

    • 계층별 저장
    • 객체 리포지터리

도구

이에 관한 전반적인 결과로서, 입력된 데이터를 위해 필요한 도구 및/또는 텔레메트리를 구축하여 모든 사용자 페르소나가 고카드널리티 메트릭을 볼 수 있도록 하여 사용되지 않는 데이터를 가시화하거나 삭제하는 데 도움이 되도록 데이터를 사용하는 데 걸리는 주기(예: 메트릭 당 스크랩 빈도)의 사용 통계를 갖는 것이 현명할 것입니다.

향후 이터레이션

텔레메트리 피라미드 간 연결, 예시들

시스템이 보내는 모든 도구화의 보다 헐리스틱한 전망을 제공하기 위해, 추적, 로그 및 오류와 같은 다른 텔레메트리 피라미드와 수신된 데이터를 상호참조할 수 있는 방식으로 메트릭 시스템을 구축해야 합니다.

사용자 정의 SQL 쿼리 지원

기존 메트릭에서 사용자 정의된 ad-hoc 쿼리를 실행할 수 있도록 시스템 사용자에게 허용해야 합니다. 이는 Prometheus 기록 규칙이 기존 메트릭에서 사용자 지정 메트릭을 생성하는 데 도움을 주는 방식과 유사합니다.

확장 가능한 데이터 입력 지원

Clickhouse에서 데이터 수신을 위한 로컬 버퍼링 및/또는 데이터 영속성을 위해 Clickhouse를 벗어나고자 하는 의도가 있다면, 다른 모니터링 시스템에서 사용되는 현실적인 방향으로 전진하는 것이 좋을 것입니다.

쿼리 서비스 기능

  • 복합쿼리 및/또는 표현식 지원 추가
  • 쿼리 엔진을 사용하여 추적, 로깅 및 오류추적을 위한 쿼리 능력을 통합
  • PromQL, MetricQL, OpenSearch 등과 같은 기타 모니터링/쿼리 표준을 지원 추가
  • 메트릭 신용카드널리 및 리소스 사용량 주변 자동화된 통찰력 추가

계획된 로드맵

다음 섹션은 GitLab Observability Service에 메트릭 지원을 구축하는 제안을 구현하는 방법에 대한 세부 정보를 포함하고 있는 각 문서와/또는 이슈를 나열하고 있습니다.

16.5

  • 연구 및 설계 제안서 및/또는 요구 사항 초안하여 초안 작성
  • 구조 설계도 작성 및 피드백 받을 수 있도록

16.6

  • OpenTelemetry를 기반으로 데이터 수집 지원 개발.
  • 데이터 쿼리 지원 개발; 주어진 테넌트에 대해 수집된 모든 메트릭 디렉터리을 나열하는 API로 시작.
  • GitLab UI 내에서 수집된 메트릭 디렉터리을 표시하는 지원 개발.
  • 실험 버전 릴리스.

16.7

  • 데이터 쿼리 지원 개발, 지원되는 메트릭 유형에 대한 메트릭 검색 엔드포인트 추가.
  • 쿼리 빌더의 첫 번째 반복 개발, 백엔드 API에 쿼리 기능 활성화.
  • 백엔드 API를 통해 반환된 데이터를 그래프로 표시하는 메트릭 세부 정보 페이지 개발.
  • 테스트 설정, 반복 가능한 벤치마킹/테스트 수행 가능하도록 보장.
  • 베타 버전 릴리스, 내부 및 외부 고객들에 의한 초기 사용을 위해 오픈.

16.9 (GA 릴리스를 위한 사용자 피드백을 수용하기 위한 갭)

  • End-to-end 테스트 개발, 필요한 프로덕션 준비 작업 완료, 사용자 피드백 처리.
  • GA 버전 릴리스.