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. As with all projects, the items mentioned on this page are subject to change or delay. The development, release, and timing of any products, features, or functionality 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 - Metrics

요약

Clickhouse를 기본 저장소로 사용하여 OpenTelemetry와 같은 산업 표준 형식으로 일반적으로 서식화된 관측 데이터를 저장하고 조회하는 풍부한 구성의 다중 사용자 시스템을 개발합니다. 장기간 데이터 보관 및 집계를 지원하며 데이터 쌓임에 대응합니다.

동기

관측 가능성의 여섯 가지 기둥 중 ‘TEMPLE’로 약칭되는 것에서, Traces, Events, Metrics, Profiles, Logs 및 Errors를 일반적으로 구성하는 메트릭은 사용자가 모니터링된 시스템의 운영 상태에 대한 통찰을 얻는 데 도움이 되어 현대 시스템에서 가장 중요한 요소 중 하나입니다.

시계열 데이터로 구조화된 메트릭은 다음과 같은 특성을 가지고 있습니다. - 해당 타임스탬프에 따라 색인화됨 - 크기가 지속적으로 증가함 - 일반적으로 범위 내에서 집계, 다운샘플링 및 조회됨 - 매우 쓰기 집약적인 요구 사항을 가짐

GitLab Observability Backend에서는 우리의 고객이 시스템과 애플리케이션에 대해 관측 데이터를 수용하고 조회하여 시스템의 운영 상태를 향상시킬 수 있도록 지원할 것입니다.

목표

제안된 시스템을 개발하는 데 다음과 같은 목표를 가지고 있습니다.

  • Clickhouse를 사용하여 검증된 성능을 가진 확장 가능하고 저렴한 모니터링 시스템을 지원합니다.
  • OpenTelemetry 호환 요소를 통해 수용된 메트릭의 장기 저장을 지원하고 GitLab 원본 UI를 통한 쿼리를 가능하게 하며 메타데이터 및 예시 지원 가능성도 있습니다.

상기한 목표는 다음과 같은 네 가지 하위 목표로 세분화될 수 있습니다.

데이터 수용

  • 대량의 쓰기와 읽기를 수용할 수 있는 시스템을 구축하여 수용된 데이터가 삭제되지 않도록 하고 내구성 보장을 지원할 것입니다.

데이터 지속성

  • OpenTelemetry 사양을 사용하여 계측된 텔레메트리/데이터를 지원할 것입니다. 첫 번째 반복에서는 데이터 집합을 위해 설계된 모든 지속성이 기본적으로 멀티 테넌트일 것으로, 동일한 저장소 백엔드 내에서 여러 그룹/프로젝트의 관측 가능성 데이터를 저장할 수 있도록 보증할 것입니다.

데이터 읽기

  • GitLab 본연의 사용자 경험을 통해 쿼리 데이터 지원을 목표로 할 것입니다. 이는 사용자 정의 DSL/쿼리 빌더를 사용하여 GitLab로부터 API 요청을 서비스하기 위해 백엔드에 전송될 것이며, 그에 따라 Clickhouse SQL로 변환될 것입니다. 내부 토론에서 제품 분석 시각화 디자이너가 이에 대한 영감의 좋은 출처라고 할 수 있습니다.

데이터 삭제

  • 필요시 수용된 데이터를 삭제할 수 있는 지원을 목표로 합니다. 또한 구성된 TTL이 만료되거나 해당 보존 정책이 시행될 때 데이터를 자연적으로 삭제함에 따라 이에 추가하여 스키마 내에서 레이블 또는 내용별로 데이터를 삭제하는 방법을 구축하고, 이를 수행하는 데 필요한 도구를 추가할 것입니다.

비목표

상기한 목표를 토대로 현재 제안에 따른 특정 사항이 비목표임을 명확히 하고자 합니다. 이는 다음과 같습니다.

  • 초기 반복에 있어 우리는 PromQL을 통한 수용된 텔레메트리 쿼리를 지원하고자 하지 않으며, 이에 대한 사업적 필요가 생긴 경우에 대비하여 이를 연기할 것입니다. 그러나 사용자는 Prometheus 메트릭의 경우 OpenTelemetry Line Protocol (OTLP)을 사용하여 메트릭을 수용할 수 있습니다(e.g. Prometheus Receiver).

제안

메트릭 구현을 위해 GitLab Observability Backend (GOB)을 사용할 것으로, 이미 우리 백엔드의 확립된 구성 요소를 통해 해당 수명 주기를 관리할 수 있습니다.

아키텍처

위 다이어그램에 나타난 것처럼, OTEL-수집기 파이프라인, 인덱서 및 쿼리 서비스는 여기에서 제안된 것으로 개발되어야 할 구성 요소입니다. 나머지 주변 구성 요소는 이미 존재하거나 GOB 내 중앙 집중식 ‘스케줄러’에서 기존 코드를 통해 제공될 수 있습니다.

쓰기 경로:

  • 우리는 기존 서비스(예: errortracking, tracing)와 유사하게 HTTP/JSON를 통해 들어오는 데이터를 예상하고 있습니다.
  • 저장 공간을 줄이기 위해 시계열 메타데이터 별로 인덱싱/캐싱하여 데이터 중복을 크게 줄이려 합니다.
  • Clickhouse로 데이터를 기록하기 전에 데이터를 일괄 처리하여 작은 쓰기를 피하려 합니다.

읽기 경로:

메트릭 읽기 경로

  • 우리는 사용자들이 수용된 데이터를 읽기 위해 GitLab 자체를 사용할 수 있도록 하려 합니다. 이는 GitLab으로부터 시작된 API 요청을 서비스하기 위해 백엔드에 전용 쿼리 서비스를 구축해야 함을 의미합니다.
  • 기초 시스템이 항상 운영 상태를 유지하기 위해 필요한 쿼리 유효성 검사, 산업화 및 비율 제한을 구현할 것입니다.

GitLab Observability 테넌트

특히 그라파나 기반의 UX 사용을 폐기하는 등 최근 백엔드 디자인의 변경 사항으로 우리는 시스템 내에서 테넌트를 어떻게 중앙화하는지 단순화할 수 있는 기회를 찾았습니다. 이 개선사항은 각 최상위 GitLab 네임스페이스마다 전용 IngressIngester 인스턴스를 배포하여 해당 테넌트의 트래픽 볼륨에 따라 각 테넌트를 확장할 수 있도록 한 후 리소스 소비를 분리함으로써 우리 시스템의 멀티 테넌트를 고립시키는 데 도움이 됩니다.

시리즈별 메타데이터 색인

ingester의 내부 구성 요소로, 우리는 시계열 데이터를 중복 제거하고 메타데이터와 점 데이터로 분리하여 저장 공간을 크게 줄여 운영 비용을 최소화하기 위해 시리즈별 레이블 및/또는 메타데이터를 색인화하는 것을 목표로 합니다. 이 색인화된 데이터는 또한 Query Service에서 모든 수신 읽기 요청에 대해 효율적으로 시계열을 계산하는 데에 활용될 수 있습니다. 이 아키텍처의 이 부분에 대한 더 자세한 내용은 제안: 효율적인 중복 제거와 쿼리 시계열 데이터를 색인하는 메트릭 레이블 색인화에서 더 자세히 설명되어 있습니다.

Query Service

Query Service는 주로 두 가지 기본 구성 요소로 구성됩니다. - 1. 요청 파서 및 2. 백엔드별 쿼리 구현. 요청 경로에서, 지정된 엔드포인트(들)로 수신되자마자, 이것은 요청 파서의 일부인 핸들러에 의해 처리됩니다. 파서의 책임은 수신된 쿼리 페이로드를 unmarshal하고 내용을 유효성 검사하며 이 쿼리/요청이 어떻게 처리되어야 하는지 설명하는 SearchContext 객체를 생성하는 것입니다. SearchContext 객체 내에는 더 구체적인 Query 객체인 QueryContext 속성이 포함되어 있으며, 이는 각각이 우리 백엔드 중 하나에 대한 완전히 독립적인 데이터 쿼리를 더 정의합니다.

QueryServiceInternals

API 구조

사용자를 대상으로 하는 API의 경우, HTTP/JSON 엔드포인트를 통해 사용자 쿼리를 요청 본문 내에서 페이로드로 marshalled하는 지원을 추가할 예정입니다. 예를 들어, 모든 instance 레이블 값에 대해 apiserver_request_total 메트릭의 분 단위 델타의 합을 계산하려면 다음과 같이 https://observe.gitlab.com/query/$GROUP/$PROJECT/metrics에 POST 요청을 보내면 됩니다.

{
  "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는 검색을 어떻게 실행해야 하는지를 정의합니다.
    • 이는 내부적으로 주어진 백엔드를 대상으로 하는 하나 이상의 Query를 가리키는 QueryContext를 포함합니다.
    • QueryQueryContext 또는 SearchContext 내의 다른 일반적인 속성에 의해 독립적으로 구문 분석 및 처리되어야 합니다.
  • Query는 쿼리를 어떻게 수행해야 하는지를 기술하는 AST와 유사한 객체를 정의합니다.
    • 명시적으로 스키마에 대한 의존성을 갖지 않으며 시스템 내부에서 데이터 모델링을 숨기는 추상화입니다.
    • 오는 쿼리가 Query 객체로 구문 분석되고 유효성이 검증될 수 있다고 가정하면, Querier는 해당 쿼리에 대해 검색/쿼리를 실행할 수 있습니다.
  • UserContext는 검색 대상 데이터에 대한 액세스 권한이 있는지 여부를 정의합니다.
    • 이것은 아마도 요청 할당량, 속도 제한 등을 모델링하고 강제하는 좋은 위치일 것입니다.
    • 이 속성의 부분을 채우는 것은 파서가 API 게이트웨이 또는 Gatekeeper를 통해 다른 전역 상태를 읽는 데에 따라 다릅니다.
  • BackendContext는 요청이 처리되어야 하는 적절한 백엔드를 정의합니다.
    • 다중 테넌트 환경에서 요청을 적절한 백엔드로 라우팅하는 데에 도움이 됩니다.
    • 그러나 본 이터레이션에서는 우리 아키텍처와 일치하는 경우에만 한 개의 백엔드로 작업할 계획입니다.
  • CorrelationContext는 여러 쿼리가 서로 어떻게 연관되어 전체적인 뷰를 작성하는 데에 도움이 되는지를 정의합니다.
    • 그러나 본 이터레이션에서는 이를 비워두고 나중에 상관 관계 벡터를 추가하는 것에만 초점을 두고 있습니다.

목표 환경

현재의 작동 구조와 일치하도록, 우리는 메트릭 오퍼링을 다음의 두 대상 환경의 일부로 배포할 예정입니다:

  • 로컬 개발을 위한 kind 클러스터
  • 스테이징/프로덕션 환경을 위한 GKE 클러스터

프로덕션 준비 상태

배치 처리

대량의 작은 쓰기 작업을 Clickhouse에 삽입하기 전에 데이터를 일괄 처리해야 할 것으로 고려될 때, 설계는 성능을 높이고 테이블 엔진이 데이터를 계속해서 성공적으로 보존할 수 있도록 하기 위해 지정된 크기의 일괄 처리로 Clickhouse에 랜딩하기 전에 들어오는 데이터를 로컬에서 일괄 처리할 수 있도록 계정해야 합니다.

우리는 다음과 같은 대안을 고려해왔습니다.

  • 메모리 내 - 비내구성
  • BadgerDB - 내구성 있고, 내장되어 있으며 성능이 우수
  • Redis - 미미한 외부 종속성
  • Kafka - 미미하지 않은 외부 종속성이지만, 다른 다양한 사용 사례를 증가시키고 GitLab의 다른 문제 도메인을 돕을 수 있습니다.

참고: 비슷한 도전은 현재 구현 중인 CH 상호 작용 errortracking에서도 나타났습니다. 이전에 이러한 문제 도메인을 해결하기 위해 여러 번 시도가 있었습니다 - 이 MR은 메모리 내 대안을 구현하고 이 MR은 디스크 상의 대안을 시도했습니다.

이 문제에 대한 어떠한 작업도 errortracking, 로그 등 다른 서브시스템에 이로운 결과를 가져올 것입니다.

확장성

우리는 초기 가설을 시험/설정하기 위해 초당 10K 메트릭 포인트로 제안된 구현을 테스트해야 할 의도입니다. 하지만 이상적으로, 우리는 초기에는 초당 1M 포인트를 삽입할 수 있도록 기반이 되도록 설계해야 합니다.

벤치마킹

제안된 구현을 벤치마킹하는 동안 다음과 같은 세 가지 차원을 테스트하기로 제안합니다.

  • 데이터 삽입 성능 (기능적)
  • 평균 쿼리 응답 시간 (기능적)
  • 저장소 요구 사항 (운영적)

성능을 이해하기 위해서는 테스트를 위해 삽입하는 데이터에 대한 쿼리 목록을 먼저 작성해야 할 것입니다. Clickhouse 쿼리 로깅은 이 작업을 할 때 매우 도움이 됩니다.

참고: 이상적으로, 시스템을 초당 1M 개 이상의 메트릭 포인트를 삽입하고 대부분의 쿼리를 1초 미만으로 유지할 수 있도록 벤치마킹을 목표합니다.

과거 작업 및 참고 자료

비용 추정

  • 시스템이 사용자에게 효율적인 비용으로 텔레메트리 데이터를 삽입하고 쿼리하기 위해서 우리의 데이터 모델링과 저장된 데이터에 어떻게 영향을 미치는지가 주요한 요소 중 하나입니다. 그래도 되도록 하기 위해 의도된 제안은 데이터 중복성을 줄이고 사용되지 않는 메트릭을 가지치기하는 등의 조치를 통해 최적화되어야 합니다.

  • 티어별 저장매체의 다중 사용, 특히 다음과 같은 사용을 고려해야 합니다.

    • 계층화된 저장소
    • 객체 저장소

도구

여기서 주된 결과로서 우리는 삽입된 데이터 주변으로 필요한 도구 및/또는 텔레메트리를 구축하기 위해 노력하고 있습니다. 이것은 모든 사용자 인격이 높은 카디널리티 메트릭에 대한 시각성을 갖게 해서 사용되지 않는 메트릭들을 가지치거나 삭제하는데 도움을 주기 위해 수행되는 것이 좋습니다. 예를 들어, 메트릭 스크래이프 빈도별 사용량 통계를 가지고, 사용자들이 필요로 하거나 유용하게 여기지 않는 볼륨의 데이터를 삽입하지 않도록 합니다.

향후 반복 사항

텔레메트리 pillar, 예제 사이의 연결

우리는 시스템이 우리에게 공급된 모든 이곳으로 데이터와 같은 다른 텔레메트리 피들과 연관시킬 수 있도록 메트릭 시스템을 구축해야 할 것입니다.

사용자 정의 SQL 쿼리 지원하여 데이터 집계 및/또는 처리된 뷰 생성

우리는 Prometheus 레코드 룰이 기존 것에서 사용자 정의와 임시 쿼리를 실행할 수 있도록 도와주는 것과 유사한 방식으로 시스템 사용자가 사용자 정의, 즉석 쿼리를 실행할 수 있도록 해야 합니다.

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

우리는 데이터를 삽입하는 데 로컬에서 데이터를 버퍼링하고/또는 Clickhouse에서 데이터를 보관하는 것에 대한 욕구를 느낀다면, 디스크 WAL은 다른 모니터링 시스템에서의 보편적인 사용을 고려할 때 해당 방향으로 진행하기에 좋은 방향일 것입니다.

쿼리 서비스 기능

  • 복합 쿼리와/또는 표현식 지원 추가
  • 추적, 로그 및 오류 추적에 대한 질의 기능의 통합화
  • 질의 엔진을 사용하여 경고와 같은 통합을 구축
  • PromQL, MetricQL, OpenSearch 등과 같은 기타 모니터링/질의 표준 지원 추가
  • 메트릭 카디널리티 및 자원 소비에 대한 자동화된 통찰력 추가

계획된 로드맵

다음 섹션에서는 GitLab Observability Service에 Metrics 지원을 구축하는 제안을 어떻게 실행할 것인지에 대해 열거합니다. 각 해당 문서 및/또는 이슈에는 각 단계가 어떻게 계획되어 있는지에 대한 자세한 내용이 포함되어 있습니다.

16.5

  • 연구 및 설계 제안 및/또는 요구 사항 초고 작성.
  • 피드백을 위해 개방된 구조적 청사진 작성.

16.6

  • OpenTelemetry 기반 수신 지원 개발.
  • 데이터 쿼리 지원 개발; 특정 테넌트에 대해 수신된 메트릭 목록을 나열하는 API로 시작.
  • GitLab UI 내에서 수신된 메트릭 목록을 표시하는 지원 개발.
  • 실험 버전 릴리스.

16.7

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

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

  • End-to-end 테스트 개발, 필요한 제품 운영 준비 및 사용자 피드백 처리 완료.
  • GA 버전 릴리스.