Loki 컴포넌트

Loki는 여러 컴포넌트를 포함하는 모듈식 시스템으로, 함께 실행(대상 all을 사용하는 "단일 바이너리" 모드), 논리적 그룹으로 실행(대상 read, write, backend를 사용하는 "단순 확장 가능 배포" 모드) 또는 개별적으로 실행("마이크로서비스" 모드)할 수 있습니다. 자세한 내용은 배포 모드를 참조하세요.

이 페이지는 이러한 각 컴포넌트의 책임을 설명합니다.

Distributor

distributor 서비스는 클라이언트로부터 들어오는 푸시 요청을 처리하는 역할을 합니다. 이는 로그 데이터의 쓰기 경로에서 첫 번째 단계입니다. distributor가 HTTP 요청으로 스트림 집합을 받으면, 각 스트림은 정확성을 검증받고 구성된 테넌트(또는 전역) 제한 내에 있는지 확인됩니다. 그런 다음 각 유효한 스트림은 병렬로 n개의 ingester로 전송되며, 여기서 n은 데이터의 복제 계수입니다. distributor는 일관된 해싱을 사용하여 스트림을 보낼 ingester를 결정합니다.

들어오는 트래픽을 적절하게 분산시키기 위해 distributor 앞에 로드 밸런서가 있어야 합니다. Kubernetes에서는 서비스 로드 밸런서가 이 서비스를 제공합니다.

distributor는 상태 비저장 컴포넌트입니다. 이로 인해 쓰기 경로에서 가장 중요한 컴포넌트인 ingester로부터 가능한 한 많은 작업을 확장하고 오프로드하기가 쉽습니다. 이러한 유효성 검사 작업을 독립적으로 확장할 수 있다는 것은 Loki가 ingester를 과부하시킬 수 있는 서비스 거부 공격으로부터 자신을 보호할 수 있음을 의미합니다. 또한 복제 계수에 따라 쓰기를 팬아웃(fan-out)할 수 있습니다.

유효성 검사

distributor가 수행하는 첫 번째 단계는 들어오는 모든 데이터가 사양에 맞는지 확인하는 것입니다. 여기에는 레이블이 유효한 Prometheus 레이블인지 확인하고, 타임스탬프가 너무 오래되거나 너무 새롭지 않은지, 로그 라인이 너무 길지 않은지 확인하는 것 등이 포함됩니다.

전처리

현재 distributor가 들어오는 데이터를 변경하는 유일한 방법은 레이블을 정규화하는 것입니다. 즉, {foo="bar", bazz="buzz"}를 {bazz="buzz", foo="bar"}와 동일하게 만드는 것, 즉 레이블을 정렬하는 것입니다. 이를 통해 Loki는 결정론적으로 캐시하고 해시할 수 있습니다.

속도 제한

distributor는 또한 테넌트당 최대 데이터 수집 속도를 기준으로 들어오는 로그를 속도 제한할 수 있습니다. 이는 테넌트당 제한을 확인하고 이를 현재 distributor의 수로 나누어 수행합니다. 이를 통해 클러스터 수준에서 테넌트당 속도 제한을 지정할 수 있으며, distributor를 확장하거나 축소할 때마다 distributor당 제한이 그에 따라 조정되도록 할 수 있습니다. 예를 들어, 10개의 distributor가 있고 테넌트 A가 10MB의 속도 제한을 가지고 있다고 가정해 봅시다. 각 distributor는 제한하기 전에 최대 1MB/s까지 허용합니다. 이제 다른 대규모 테넌트가 클러스터에 합류하여 10개의 distributor를 추가해야 한다고 가정해 봅시다. 이제 20개의 distributor는 테넌트 A에 대한 속도 제한을 (10MB / 20 distributors) = 500KB/s로 조정합니다. 이것이 전역 제한이 Loki 클러스터의 훨씬 간단하고 안전한 운영을 가능하게 하는 방법입니다.

참고: distributor는 내부적으로 ring 컴포넌트를 사용하여 동료들 사이에 자신을 등록하고 활성 distributor의 총 수를 얻습니다. 이것은 ingester가 링에서 사용하는 것과 다른 "키"이며 distributor 자체의 링 구성에서 비롯됩니다.

전달

distributor가 모든 유효성 검사 의무를 수행하면, 데이터를 궁극적으로 쓰기 작업을 승인하는 책임이 있는 ingester 컴포넌트로 전달합니다.

복제 계수(Replication factor)

단일 ingester에서 데이터를 잃을 가능성을 완화하기 위해 distributor는 쓰기를 복제 계수만큼의 ingester로 전달합니다. 일반적으로 복제 계수는 3입니다. 복제는 쓰기 실패 없이 ingester 재시작 및 롤아웃을 허용하며 일부 시나리오에서 데이터 손실에 대한 추가적인 보호를 추가합니다. 느슨하게 말하면, distributor에 푸시되는 각 레이블 세트( 스트림 이라고 함)에 대해 레이블을 해시하고 결과 값을 사용하여 ring( 분산 해시 테이블을 노출하는 하위 컴포넌트)에서 replication_factor개의 ingester를 조회합니다. 그런 다음 동일한 데이터를 모든 ingester에 쓰려고 시도합니다. 이는 쿼럼 미만의 쓰기가 성공하면 오류를 생성합니다. 쿼럼은 floor( replication_factor / 2 ) + 1로 정의됩니다. 따라서 replication_factor가 3인 경우 두 번의 쓰기가 성공해야 합니다. 두 번 미만의 쓰기가 성공하면 distributor는 오류를 반환하고 쓰기 작업이 재시도됩니다.

주의: 2/3의 ingester가 쓰기를 승인하면 하나의 ingester 손실은 견딜 수 있지만 두 개의 ingester 손실은 데이터 손실로 이어질 수 있으므로 견딜 수 없습니다.

복제 계수가 데이터 손실을 방지하는 유일한 것은 아니며, 주요 목적은 롤아웃 및 재시작 중에 중단 없이 쓰기를 계속할 수 있도록 하는 것입니다. ingester 컴포넌트는 이제 들어오는 쓰기를 디스크에 유지하여 디스크가 손상되지 않는 한 손실되지 않도록 보장하는 미리 쓰기 로그 (opens in a new tab)(WAL)를 포함합니다. 복제 계수와 WAL의 보완적인 특성은 두 메커니즘 모두에 심각한 장애(즉, 여러 ingester가 죽고 디스크를 잃거나 손상시키는 경우)가 없는 한 데이터가 손실되지 않도록 보장합니다.

해싱

Distributor는 구성 가능한 복제 계수와 함께 일관된 해싱을 사용하여 ingester 서비스의 어떤 인스턴스가 주어진 스트림을 수신해야 하는지 결정합니다.

스트림은 테넌트 및 고유한 레이블 세트와 관련된 로그 집합입니다. 스트림은 테넌트 ID와 레이블 세트를 모두 사용하여 해시된 다음 해시를 사용하여 스트림을 보낼 ingester를 찾습니다.

Memberlist (opens in a new tab) 프로토콜을 사용하는 피어 투 피어 통신에 의해 유지 관리되거나 Consul (opens in a new tab)과 같은 키-값 저장소에 저장된 해시 링은 일관된 해싱을 달성하는 데 사용됩니다. 모든 ingester는 자신이 소유한 토큰 세트로 해시 링에 자신을 등록합니다. 각 토큰은 임의의 부호 없는 32비트 숫자입니다. 토큰 세트와 함께 ingester는 자신의 상태를 해시 링에 등록합니다. JOINING 및 ACTIVE 상태는 모두 쓰기 요청을 받을 수 있으며, ACTIVE 및 LEAVING ingester는 읽기 요청을 받을 수 있습니다. 해시 조회를 할 때 distributor는 요청에 적합한 상태에 있는 ingester에 대한 토큰만 사용합니다.

해시 조회를 수행하기 위해 distributor는 스트림의 해시보다 큰 값을 가진 가장 작은 적절한 토큰을 찾습니다. 복제 계수가 1보다 크면 다른 ingester에 속한 다음 후속 토큰(링에서 시계 방향)도 결과에 포함됩니다.

이 해시 설정의 효과는 ingester가 소유한 각 토큰이 해시 범위에 대한 책임이 있다는 것입니다. 값이 0, 25, 50인 세 개의 토큰이 있는 경우 해시 3은 토큰 25를 소유한 ingester에게 주어집니다. 토큰 25를 소유한 ingester는 1-25의 해시 범위를 담당합니다.

쿼럼 일관성

모든 distributor가 동일한 해시 링에 대한 액세스를 공유하므로 쓰기 요청은 모든 distributor로 보낼 수 있습니다.

일관된 쿼리 결과를 보장하기 위해 Loki는 읽기 및 쓰기에 Dynamo 스타일 (opens in a new tab) 쿼럼 일관성을 사용합니다. 이는 distributor가 샘플을 보낼 ingester의 절반 더하기 일 이상의 긍정적인 응답을 기다린 후에야 전송을 시작한 클라이언트에 응답한다는 것을 의미합니다.

Ingester

ingester 서비스는 데이터를 유지하고 장기 저장소(Amazon Simple Storage Service, Google Cloud Storage, Azure Blob Storage 등)로 전송하는 쓰기 경로와, 최근에 수집된 인메모리 로그 데이터를 쿼리를 위해 반환하는 읽기 경로를 담당합니다.

Ingester에는 해시 링에서 ingester의 라이프사이클을 관리하는 lifecycler가 포함되어 있습니다. 각 ingester는 PENDING, JOINING, ACTIVE, LEAVING 또는 UNHEALTHY 상태를 가집니다.

• PENDING은 LEAVING 상태인 다른 ingester로부터 핸드오프를 기다리는 Ingester의 상태입니다. 이는 레거시 배포 모드에만 적용됩니다.

  참고: 핸드오프는 주로 상태 비저장 ingester 배포에서 사용되는 더 이상 사용되지 않는 동작이며 권장되지 않습니다. 대신, 미리 쓰기 로그와 함께 상태 저장 배포 모델을 사용하는 것이 좋습니다.

• JOINING은 현재 링에 토큰을 삽입하고 자신을 초기화하는 Ingester의 상태입니다. 소유한 토큰에 대한 쓰기 요청을 받을 수 있습니다.
• ACTIVE는 완전히 초기화된 Ingester의 상태입니다. 소유한 토큰에 대한 쓰기 및 읽기 요청을 모두 받을 수 있습니다.
• LEAVING은 종료 중인 Ingester의 상태입니다. 아직 메모리에 있는 데이터에 대한 읽기 요청을 받을 수 있습니다.
• UNHEALTHY는 하트비트에 실패한 Ingester의 상태입니다. UNHEALTHY는 distributor가 주기적으로 링을 확인할 때 설정됩니다.

ingester가 수신하는 각 로그 스트림은 메모리에서 많은 "청크" 집합으로 구축되고 구성 가능한 간격으로 백킹 스토리지 백엔드로 플러시됩니다.

청크는 다음과 같은 경우 압축되고 읽기 전용으로 표시됩니다.

• 현재 청크가 용량에 도달한 경우 (구성 가능한 값).
• 현재 청크가 업데이트되지 않고 너무 많은 시간이 경과한 경우
• 플러시가 발생하는 경우.

청크가 압축되고 읽기 전용으로 표시될 때마다 쓰기 가능한 청크가 그 자리를 차지합니다.

ingester 프로세스가 충돌하거나 갑자기 종료되면 아직 플러시되지 않은 모든 데이터가 손실될 수 있습니다. Loki는 일반적으로 이 위험을 완화하기 위해 각 로그의 여러 복제본(보통 3개)을 복제하도록 구성됩니다.

영구 저장소 공급자로 플러시가 발생하면 청크는 테넌트, 레이블 및 내용에 따라 해시됩니다. 이는 동일한 데이터 사본을 가진 여러 ingester가 동일한 데이터를 백킹 저장소에 두 번 쓰지 않지만, 복제본 중 하나에 쓰기가 실패하면 백킹 저장소에 여러 개의 다른 청크 객체가 생성됨을 의미합니다. 데이터가 중복 제거되는 방법에 대해서는 Querier를 참조하세요.

타임스탬프 순서

Loki는 기본적으로 순서가 맞지 않는 쓰기를 허용하도록 구성되어 있습니다.

순서가 맞지 않는 쓰기를 허용하도록 구성되지 않은 경우, ingester는 수집된 로그 라인이 순서대로인지 확인합니다. ingester가 예상 순서를 따르지 않는 로그 라인을 받으면 해당 라인은 거부되고 사용자에게 오류가 반환됩니다.

ingester는 로그 라인이 타임스탬프 오름차순으로 수신되었는지 확인합니다. 각 로그에는 이전 로그보다 나중에 발생하는 타임스탬프가 있습니다. ingester가 이 순서를 따르지 않는 로그를 받으면 해당 로그 라인은 거부되고 오류가 반환됩니다.

각 고유 레이블 세트의 로그는 메모리에서 "청크"로 구축된 다음 백킹 스토리지 백엔드로 플러시됩니다.

ingester 프로세스가 충돌하거나 갑자기 종료되면 아직 플러시되지 않은 모든 데이터가 손실될 수 있습니다. Loki는 일반적으로 재시작 시 재생될 수 있는 미리 쓰기 로그와 이 위험을 완화하기 위해 각 로그의 replication_factor(보통 3)로 구성됩니다.

순서가 맞지 않는 쓰기를 허용하도록 구성되지 않은 경우, 주어진 스트림(레이블의 고유한 조합)에 대해 Loki에 푸시된 모든 라인은 이전에 수신된 라인보다 최신 타임스탬프를 가져야 합니다. 그러나 동일한 나노초 타임스탬프를 가진 동일한 스트림에 대한 로그를 처리하는 두 가지 경우가 있습니다.

• 들어오는 라인이 이전에 수신된 라인과 정확히 일치하는 경우(이전 타임스탬프와 로그 텍스트 모두 일치), 들어오는 라인은 정확한 중복으로 처리되어 무시됩니다.
• 들어오는 라인이 이전 라인과 동일한 타임스탬프를 가지고 있지만 내용이 다른 경우, 로그 라인이 수락됩니다. 이는 동일한 타임스탬프에 대해 두 개의 다른 로그 라인을 가질 수 있음을 의미합니다.

핸드오프(Handoff)

경고: 핸드오프는 주로 상태 비저장 ingester 배포에서 사용되는 더 이상 사용되지 않는 동작이며 권장되지 않습니다. 대신, 미리 쓰기 로그와 함께 상태 저장 배포 모델을 사용하는 것이 좋습니다.

기본적으로, ingester가 종료되고 해시 링을 떠나려고 할 때, 플러시하기 전에 새로운 ingester가 들어오려고 하는지 확인하고 핸드오프를 시작하려고 합니다. 핸드오프는 떠나는 ingester가 소유한 모든 토큰과 인메모리 청크를 새로운 ingester에게 전송합니다.

해시 링에 참여하기 전에, ingester는 PENDING 상태에서 핸드오프가 발생하기를 기다립니다. 구성 가능한 타임아웃 후, 전송을 받지 못한 PENDING 상태의 ingester는 정상적으로 링에 참여하여 새로운 토큰 세트를 삽입합니다.

이 프로세스는 종료 시 모든 청크를 플러시하는 것을 피하기 위해 사용되며, 이는 느린 프로세스입니다.

파일 시스템 지원

ingester는 BoltDB를 통해 파일 시스템에 쓰는 것을 지원하지만, 이는 단일 프로세스 모드에서만 작동합니다. querier는 동일한 백엔드 저장소에 액세스해야 하고 BoltDB는 한 번에 하나의 프로세스만 DB에 대한 잠금을 가질 수 있기 때문입니다.

Query Frontend

query frontend는 querier의 API 엔드포인트를 제공하는 선택적 서비스이며 읽기 경로를 가속화하는 데 사용할 수 있습니다. query frontend가 있는 경우, 들어오는 쿼리 요청은 querier 대신 query frontend로 전달되어야 합니다. querier 서비스는 실제 쿼리를 실행하기 위해 클러스터 내에서 여전히 필요합니다.

query frontend는 내부적으로 일부 쿼리 조정을 수행하고 내부 큐에 쿼리를 보관합니다. 이 설정에서 querier는 큐에서 작업을 가져와 실행하고 집계를 위해 query frontend로 반환하는 작업자 역할을 합니다. querier는 query frontend에 연결할 수 있도록 query frontend 주소(-querier.frontend-address CLI 플래그를 통해)로 구성해야 합니다.

Query frontend는 상태 비저장입니다. 그러나 내부 큐가 작동하는 방식 때문에 공정한 스케줄링의 이점을 얻기 위해 몇 개의 query frontend 복제본을 실행하는 것이 좋습니다. 대부분의 경우 두 개의 복제본이면 충분합니다.

큐잉(Queueing)

별도의 query scheduler 컴포넌트가 사용되지 않는 경우, query frontend는 기본적인 쿼리 큐잉도 수행합니다.

• querier에서 메모리 부족(OOM) 오류를 일으킬 수 있는 대규모 쿼리가 실패 시 재시도되도록 보장합니다. 이를 통해 관리자는 쿼리에 대한 메모리를 과소 프로비저닝하거나 낙관적으로 더 작은 쿼리를 병렬로 실행하여 총 소유 비용(TCO)을 줄일 수 있습니다.
• 모든 querier에 걸쳐 선입선출 큐(FIFO)를 사용하여 여러 대규모 요청이 단일 querier에 몰리는 것을 방지합니다.
• 테넌트 간에 쿼리를 공정하게 예약하여 단일 테넌트가 다른 테넌트를 서비스 거부(DOS)하는 것을 방지합니다.

분할(Splitting)

query frontend는 더 큰 쿼리를 여러 개의 더 작은 쿼리로 분할하여 다운스트림 querier에서 병렬로 실행하고 결과를 다시 합칩니다. 이는 대규모(여러 날 등) 쿼리가 단일 querier에서 메모리 부족 문제를 일으키는 것을 방지하고 더 빨리 실행하는 데 도움이 됩니다.

캐싱(Caching)

메트릭 쿼리

query frontend는 메트릭 쿼리 결과 캐싱을 지원하고 후속 쿼리에서 재사용합니다. 캐시된 결과가 불완전한 경우 query frontend는 필요한 하위 쿼리를 계산하고 다운스트림 querier에서 병렬로 실행합니다. query frontend는 쿼리 결과의 캐시 가능성을 향상시키기 위해 선택적으로 쿼리를 단계 매개변수와 정렬할 수 있습니다. 결과 캐시는 모든 Loki 캐싱 백엔드(현재 Memcached, Redis 및 인메모리 캐시)와 호환됩니다.

로그 쿼리

query frontend는 또한 음수 캐시 형태로 로그 쿼리 캐싱을 지원합니다. 즉, 양자화된 시간 범위에 대한 로그 결과를 캐싱하는 대신 Loki는 양자화된 시간 범위에 대한 빈 결과만 캐싱합니다. 이는 로그 쿼리가 제한적(보통 1000개 결과)이고 실제 결과만 캐싱하는 경우에도 다른 항목이 일치하지 않음을 확인하기 위해 결과 캐시의 데이터 외에 많은 데이터를 처리해야 하기 때문에 실제 결과를 캐싱하는 것보다 더 효율적입니다.

인덱스 통계 쿼리

query frontend는 메트릭 쿼리 결과와 유사하게 인덱스 통계 쿼리 결과를 캐싱합니다. 이 캐시는 단일 저장소 TSDB를 사용할 때만 적용됩니다.

로그 볼륨 쿼리

query frontend는 메트릭 쿼리 결과와 유사하게 로그 볼륨 쿼리 결과를 캐싱합니다. 이 캐시는 단일 저장소 TSDB를 사용할 때만 적용됩니다.

Query Scheduler

query scheduler는 query frontend보다 더 고급 큐잉 기능을 제공하는 선택적 서비스입니다. Loki 배포에서 이 컴포넌트를 사용할 때, query frontend는 분할된 쿼리를 query scheduler로 푸시하고, query scheduler는 이를 내부 인메모리 큐에 넣습니다. 모든 테넌트에 걸쳐 쿼리 공정성을 보장하기 위해 각 테넌트에 대한 큐가 있습니다. query scheduler에 연결하는 querier는 큐에서 작업을 가져와 실행하고 집계를 위해 query frontend로 반환하는 작업자 역할을 합니다. 따라서 querier는 query scheduler에 연결할 수 있도록 query scheduler 주소(-querier.scheduler-address CLI 플래그를 통해)로 구성해야 합니다.

Query scheduler는 상태 비저장입니다. 그러나 인메모리 큐 때문에 고가용성의 이점을 유지하기 위해 하나 이상의 복제본을 실행하는 것이 좋습니다. 대부분의 경우 두 개의 복제본이면 충분합니다.

Querier

querier 서비스는 Log Query Language (LogQL) 쿼리를 실행하는 역할을 합니다. querier는 클라이언트로부터 직접 HTTP 요청을 처리하거나("단일 바이너리" 모드 또는 "단순 확장 가능 배포"의 읽기 경로의 일부로) query frontend 또는 query scheduler에서 하위 쿼리를 가져올 수 있습니다("마이크로서비스" 모드).

ingester와 장기 저장소 모두에서 로그 데이터를 가져옵니다. Querier는 백엔드 저장소에 대해 동일한 쿼리를 실행하기 전에 모든 ingester에 인메모리 데이터에 대한 쿼리를 보냅니다. 복제 계수 때문에 querier가 중복된 데이터를 수신할 수 있습니다. 이를 해결하기 위해 querier는 동일한 나노초 타임스탬프, 레이블 세트 및 로그 메시지를 가진 데이터를 내부적으로 중복 제거합니다.

Index Gateway

index gateway 서비스는 메타데이터 쿼리를 처리하고 제공하는 역할을 합니다. 메타데이터 쿼리는 인덱스에서 데이터를 조회하는 쿼리입니다. 인덱스 게이트웨이는 단일 저장소 TSDB 또는 단일 저장소 BoltDB와 같은 "shipper stores"에서만 사용됩니다.

query frontend는 쿼리의 로그 볼륨에 대해 인덱스 게이트웨이를 쿼리하여 쿼리를 분할하는 방법을 결정할 수 있습니다. querier는 주어진 쿼리에 대한 청크 참조에 대해 인덱스 게이트웨이를 쿼리하여 어떤 청크를 가져와서 쿼리해야 하는지 알 수 있습니다.

인덱스 게이트웨이는 simple 또는 ring 모드로 실행할 수 있습니다. simple 모드에서는 각 인덱스 게이트웨이 인스턴스가 모든 테넌트의 모든 인덱스를 제공합니다. ring 모드에서는 인덱스 게이트웨이가 일관된 해시 링을 사용하여 사용 가능한 인스턴스 간에 테넌트별로 인덱스를 배포하고 분할합니다.

Compactor

compactor 서비스는 단일 저장소 TSDB 또는 단일 저장소 BoltDB와 같은 "shipper stores"에서 사용되며, ingester에 의해 생성되고 객체 저장소로 전송된 여러 인덱스 파일을 하루 및 테넌트당 단일 인덱스 파일로 압축합니다. 이를 통해 인덱스 조회가 더 효율적이 됩니다.

이를 위해 compactor는 정기적으로 객체 저장소에서 파일을 다운로드하고, 이를 단일 파일로 병합하고, 새로 생성된 인덱스를 업로드하고, 이전 파일을 정리합니다.

또한 compactor는 로그 보존 및 로그 삭제도 담당합니다.

Loki 배포에서 compactor 서비스는 일반적으로 단일 인스턴스로 실행됩니다.

Ruler

ruler 서비스는 규칙 구성에 제공된 규칙 및/또는 경고 표현식을 관리하고 평가합니다. 규칙 구성은 객체 저장소(또는 로컬 파일 시스템)에 저장되며 ruler API를 통해 관리하거나 객체 저장소에 파일을 직접 업로드하여 관리할 수 있습니다.

또는 ruler는 규칙 평가를 query frontend에 위임할 수도 있습니다. 이 모드를 원격 규칙 평가라고 하며, query frontend의 쿼리 분할, 쿼리 샤딩 및 캐싱의 이점을 얻기 위해 사용됩니다.

여러 ruler를 실행할 때, 그들은 일관된 해시 링을 사용하여 사용 가능한 ruler 인스턴스 간에 규칙 그룹을 배포합니다.

Bloom Planner

경고: 이 기능은 실험적 기능입니다. 엔지니어링 및 온콜 지원은 제공되지 않습니다. SLA는 제공되지 않습니다.

Bloom Planner 서비스는 bloom 생성을 위한 작업을 계획하는 역할을 합니다. 싱글톤으로 실행되며 Bloom Builder가 작업을 가져오는 큐를 제공합니다. 계획은 주기적으로 실행되며 특정 날짜 및 테넌트에 대해 이미 빌드된 bloom과 새로 추가해야 하는 시리즈를 고려합니다.

이 서비스는 bloom 보존을 적용하는 데에도 사용됩니다.

Bloom Builder

경고: 이 기능은 실험적 기능입니다. 엔지니어링 및 온콜 지원은 제공되지 않습니다. SLA는 제공되지 않습니다.

Bloom Builder 서비스는 Bloom Planner가 생성한 작업을 처리하는 역할을 합니다. Bloom Builder는 로그 항목의 구조화된 메타데이터에서 bloom 블록을 생성합니다. 결과적인 bloom은 특정 날짜의 여러 시리즈 및 청크에 걸친 bloom 블록으로 그룹화됩니다. 이 컴포넌트는 또한 각 시리즈 및 TSDB 인덱스 파일에 대해 어떤 블록을 사용할 수 있는지 추적하는 메타데이터 파일을 빌드합니다.

서비스는 상태 비저장이며 수평적으로 확장 가능합니다.

Bloom Gateway

경고: 이 기능은 실험적 기능입니다. 엔지니어링 및 온콜 지원은 제공되지 않습니다. SLA는 제공되지 않습니다.

Bloom Gateway 서비스는 청크 필터링 요청을 처리하고 제공하는 역할을 합니다. 인덱스 게이트웨이는 청크 참조를 계산하거나 주어진 쿼리에 대한 샤드를 계산할 때 Bloom Gateway를 쿼리합니다. 게이트웨이 서비스는 청크 목록과 필터링 표현식을 가져와 bloom과 일치시키고 주어진 레이블 필터 표현식과 일치하지 않는 청크를 필터링합니다.

서비스는 수평적으로 확장 가능합니다. 여러 인스턴스를 실행할 때 클라이언트(인덱스 게G이트웨이)는 참조된 bloom 블록의 해시를 기반으로 인스턴스 간에 요청을 분할합니다.