실험적 기능

실험적 기능 (Feature flags)

프로메테우스에는 기본적으로 비활성화된 기능들이 있어요. 그것들은 호환성 깨짐(breaking changes)이거나 실험적이라고 간주되기 때문이에요. 그 동작은 향후 릴리스에서 바뀔 수 있으며, 이는 릴리스 체인지로그로 전달돼요. 이 문서는 이런 기능 플래그(feature flag)들을 하나씩 설명해 드려요.

이 기능들은 --enable-feature 플래그에 쉼표로 구분된 목록으로 활성화할 수 있고, 미래 버전에서는 기본적으로 활성화될 수도 있어요. 각 기능이 무엇을 하는지, 어떤 실험적 위험과 한계가 있는지 한국어로 풀어드릴게요.

출처: 문서

본문

여기에 기본적으로 비활성화된 기능 목록이 있어요. 그것들은 호환성 깨짐이거나 실험적이라고 간주되기 때문이에요. 그 동작은 향후 릴리스에서 바뀔 수 있으며, 이는 릴리스 체인지로그로 전달돼요.

--enable-feature 플래그에 쉼표로 구분된 기능 목록으로 활성화할 수 있어요. 그것들은 미래 버전에서 기본적으로 활성화될 수 있어요.

Exemplars 저장 (Exemplars storage)

--enable-feature=exemplar-storage

OpenMetrics는 스크랩 타깃이 특정 메트릭에 exemplar를 추가할 수 있는 능력을 도입해요. Exemplar는 MetricSet 외부의 데이터에 대한 참조예요. 흔한 사용 사례는 프로그램 트레이스(trace)의 ID예요.

Exemplar 저장은 모든 시리즈의 exemplar를 메모리에 저장하는 고정 크기 원형 버퍼로 구현돼요. 이 기능을 활성화하면 Prometheus가 스크랩한 exemplar의 저장이 활성화돼요. 구성 파일의 storage/exemplars 블록으로 exemplar 수에 따라 원형 버퍼 크기를 제어할 수 있어요. trace_id=만 있는 exemplar는 인메모리 exemplar 저장을 통해 대략 100바이트의 메모리를 사용해요. Exemplar 저장이 활성화되면 (WAL 기간 동안) 로컬 영속화를 위해 exemplar를 WAL에도 추가해요.

셧다운 시 메모리 스냅샷 (Memory snapshot on shutdown)

--enable-feature=memory-snapshot-on-shutdown

이것은 셧다운 시 메모리에 있는 청크를 시리즈 정보와 함께 스냅샷으로 찍어 디스크에 저장해요. 이렇게 하면 메모리 상태가 이 스냅샷과 m-mapped 청크로 복원될 수 있고, WAL 재생은 스냅샷에 없는 부분에만 필요하므로 시작 시간이 줄어들어요.

추가 스크랩 메트릭 (Extra scrape metrics)

--enable-feature=extra-scrape-metrics

참고: 이 기능 플래그는 더 이상 사용되지 않아요(deprecated). 대신 extra_scrape_metrics 구성 옵션을 사용하세요(전역과 scrape-config 수준 모두에서 사용 가능). 기능 플래그는 미래의 주요 버전에서 제거될 거예요. 자세한 내용은 구성 문서를 보세요.

활성화하면 각 인스턴스 스크랩에 대해 Prometheus가 다음 추가 타임시리즈에 샘플을 저장해요.

  • scrape_timeout_seconds. 타깃에 대해 구성된 scrape_timeout. 이를 통해 scrape_duration_seconds / scrape_timeout_seconds로 각 타깃이 타임아웃에 얼마나 가까운지 측정할 수 있어요.

  • scrape_sample_limit. 타깃에 대해 구성된 sample_limit. 이를 통해 scrape_samples_post_metric_relabeling / scrape_sample_limit로 각 타깃이 한도에 얼마나 가까운지 측정할 수 있어요. 구성된 한도가 없으면 scrape_sample_limit은 0이 될 수 있다는 점에 유의하세요. 즉 위 쿼리는 한도가 없는 타깃에 대해 (0으로 나누므로) +Inf를 반환할 수 있어요. 샘플 한도가 있는 타깃만 쿼리하고 싶다면 다음 쿼리를 사용하세요: scrape_samples_post_metric_relabeling / (scrape_sample_limit > 0).

  • scrape_body_size_bytes. 성공했다면 가장 최근 스크랩 응답의 압축되지 않은 크기. body_size_limit을 초과해 실패한 스크랩은 -1을 보고하고, 다른 스크랩 실패는 0을 보고해요.

단계별 통계 (Per-step stats)

--enable-feature=promql-per-step-stats

활성화하면 쿼리 요청에서 stats=all을 전달할 때 단계별 통계가 반환돼요. 다음 샘플 통계가 포함돼요.

  • totalQueryableSamples / totalQueryableSamplesPerStep: 쿼리 중 로드된 총 샘플 수. 여러 단계에 걸쳐 평가되는 범위-벡터 함수(예: rate, sum_over_time)는 각 단계가 전체 창을 계산합니다(같은 점이 여러 단계에서 계산될 수 있음).

  • samplesRead / samplesReadPerStep: 읽은(I/O) 총 샘플 수. 범위 쿼리의 범위-벡터 함수는 단계당 새 점만 계산합니다(단계 0: 전체 창; 이후 단계: 이전 단계에서 보지 못한 점). 다른 쿼리 유형에서는 totalQueryableSamples와 같음.

  • peakSamples: 평가 중 메모리의 샘플 최대 수(query.max-samples 한도에 사용됨).

Prometheus 서버는 관측 가능성을 위한 두 개의 카운터를 노출해요: prometheus_engine_query_samples_total(로드된 샘플, 단계당 전체 창)과 prometheus_engine_query_samples_read_total(읽은 샘플, 범위-벡터의 단계당 델타).

엔진이나 쿼리에서 비활성화되면 단계별 통계는 전혀 계산되지 않아요.

실험적 PromQL 함수 (Experimental PromQL functions)

--enable-feature=promql-experimental-functions

실험적이라고 간주되는 PromQL 함수를 활성화해요. 이 함수들은 이름, 문법 또는 의미가 바뀔 수 있어요. 완전히 제거될 수도 있어요.

시작(Created) 타임스탬프 0 주입 (Start (Created) Timestamps Zero Injection)

--enable-feature=created-timestamp-zero-ingestion

참고: CreatedTimestamp 기능은 일관성을 위해 StartTimestamp로 이름이 바뀌었어요. 위 플래그는 안정성을 위해 옛 이름을 사용해요.

시작 타임스탬프(Start timestamp) 수집을 활성화해요. 시작 타임스탬프는 적절할 때 0 값 샘플로 주입돼요. 자세한 내용은 PromCon 강연을 보세요.

현재 Prometheus는 다음에서 시작 타임스탬프를 지원해요.

  • PrometheusProto

  • OpenMetrics1.0.0

위 중 Prometheus는 PrometheusProto를 권장해요. OpenMetrics 1.0 Start Timestamp 정보가 _created 메트릭으로 공유되고, 그것을 파싱하는 것은 오류가 나기 쉽고 비싸기(오버헤드 추가) 때문이에요. 또한 불필요한 _created 메트릭으로 Prometheus를 오염시키지 않도록 주의해야 해요.

따라서 created-timestamp-zero-ingestion이 활성화되면 Prometheus는 전역 scrape_protocols 기본 구성 옵션을 [ PrometheusProto, OpenMetricsText1.0.0, OpenMetricsText0.0.1, PrometheusText0.0.4 ]로 바꿔서, 프로메테우스 Protobuf 프로토콜을 먼저 협상하게 해요(scrape_protocols 옵션이 다른 값으로 명시적으로 설정되지 않은 경우).

Prometheus에서 이 기능을 활성화하는 것 외에, 시작 타임스탬프는 스크랩되는 애플리케이션이 노출해야 해요.

시작 타임스탬프(ST) 네이티브 저장 (Start timestamp (ST) native storage)

--enable-feature=st-storage

WAL, TSDB/Agent, Remote-Write 2.0을 통해 샘플당 시작 타임스탬프(ST)의 저장을 활성화해요. 이 옵션은 스크랩과 수신 프로토콜에서 제시된 그대로 정확한 ST 값을 보존할 수 있게 해 줘요. 이 기능은 미래에 합성 0 샘플을 주입하는 created-timestamp-zero-ingestion의 대체품이 될 의도예요.

현재 Prometheus는 다음에서 시작 타임스탬프를 지원해요.

  • PrometheusProto

  • OpenMetrics1.0.0

ST 전달의 효율성 때문에 PrometheusProto가 권장돼요.

Prometheus에서 이 기능을 활성화하는 것 외에, 시작 타임스탬프는 스크랩되는 애플리케이션이 노출해야 해요.

참고: 이것은 완전히 구현될 때까지 알려진 한계가 있는 실험적 기능이에요.

  • 새로운 WAL 레코드 타입(SamplesV2)을 도입하며, 이것은 Prometheus 3.11 이상에서만 재생될 수 있어요.

  • 영속 저장소(TSDB 블록) 지원을 위해 부동소수점용 XOR2 청크 형식(xor2-encoding 플래그)과 네이티브 히스토그램용 히스토그램 ST 청크 형식(histograms-st-encoding 플래그)에 수동으로 옵트인해야 해요. st-storage가 활성일 때 부동소수점 청크 인코딩은 XOR2로 해석되어야 해요. XOR 청크는 시작 타임스탬프를 저장하지 않기 때문이에요. 해석된 인코딩이 XOR이면(즉 --enable-feature=xor2-encoding이 설정되지 않고 chunk_encoding.floats: xor2가 구성되지 않으면), Prometheus는 계속 실행하는 대신 구성을 검증 실패로 처리하고 시작을 거부해요. 마찬가지로 st-storage가 활성인 동안 구성 파일에서 chunk_encoding.floats: xor를 명시적으로 설정하는 것은 구성 리로드에서 거부돼요. 이 제약들은 실험 단계를 끝낸 뒤 변경될 수 있어요.

  • 네이티브 히스토그램과 NHCB에 대한 ST 지원의 다른 영역은 여전히 진행 중이에요(#18315 참조).

  • PromQL에서의 ST 사용은 이 기능의 범위 밖이에요.

PromQL 함수에서 시작 타임스탬프(ST) 사용 (Start timestamp (ST) usage in PromQL functions)

--enable-feature=use-start-timestamps

rate(), irate(), increase(), start_timestamp() 같은 PromQL 함수에서 시작 타임스탬프(ST) 사용을 활성화해요. 이 기능은 현재 확장 범위 셀렉터(promql-extended-range-selectors)와는 작동하지 않아요.

시작 타임스탬프(ST) 합성 (Start timestamp (ST) synthesis)

--enable-feature=st-synthesis

누적 메트릭(Counters, Classic Histograms, Native Histograms)에 대해 시작 타임스탬프(ST)가 소스에서 제공되지 않을 때 그것의 합성을 활성화해요. 공식 OpenTelemetry metricstarttimeprocessor와 유사하게, 리셋을 감지하기 위해 이전 값을 추적하고 초기 기준점을 빼서 첫 번째 샘플부터 0 기반 타임라인을 합성해요.

참고: 이것은 실험적 기능이에요.

  • 이 기능을 켜면 시작 타임스탬프 기준점을 세우기 위해 첫 번째 샘플이 버려져요. 결과적으로 시리즈에 단일 포인트만 보고되면, 이 기능을 켜는 것이 그 시리즈에 포인트가 전혀 수집되지 않을 수 있어요.

  • 합성은 정확한 카운터 비율을 유지하면서 정확한 Start Timestamp를 산출해요. 하지만 원시 카운터 값은 스크랩된 것과 다를 거예요. 첫 번째 포인트가 버려지고 그 타임스탬프가 이후 모든 포인트의 시작 타임스탬프로 사용되기 때문이에요. 이후 모든 포인트는 그 버려진 포인트에 대해 정규화(즉 빼기)돼요. 사실상 합성은 원본 데이터의 알려진 시작 타임스탬프로 새 카운터 스트림을 만들어요.

  • 합성은 스크랩된 데이터에서만 작동해요(RW와 Otel 수신기는 구현되지 않음).

  • 합성은 정렬된 샘플을 요구해요. 결과적으로 ST가 없는 순서가 어긋난 누적 샘플은 tsdb. out_of_order_time_window 설정에도 불구하고 거부돼요.

  • 시리즈에 대한 append가 실패하면(예: 순서가 어긋난 샘플이 거부되는 경우), 그 시리즈의 합성 상태가 지워져요. 결과적으로 실패 후 받은 다음 샘플이 다시 첫 번째 샘플로 취급되어 새 기준점을 세우기 위해 버려져요.

독립 규칙의 동시 평가 (Concurrent evaluation of independent rules)

--enable-feature=concurrent-rule-eval

기본적으로 규칙 그룹은 동시에 실행되지만, 그룹 안의 규칙은 순차적으로 실행돼요. 규칙이 앞선 규칙의 출력을 입력으로 사용할 수 있기 때문이에요. 하지만 규칙들 사이에 감지 가능한 관계가 없다면 순차적으로 실행할 이유가 없어요. concurrent-rule-eval 기능 플래그가 활성화되면, 규칙 그룹 안에서 다른 규칙에 대한 의존성이 없는 규칙이 동시에 평가돼요. 이것은 더 많은 동시 쿼리 로드를 추가하는 대가로 규칙 그룹 평가 지연시간과 리소스 활용을 개선할 가능성이 있어요.

동시 규칙 평가 수는 --rules.max-concurrent-evals로 구성할 수 있으며, 기본값은 4예요.

이전 Prometheus UI 서빙 (Serve old Prometheus UI)

새 UI 대신 이전(Prometheus 2.x) 웹 UI를 서빙하는 것으로 폴백해요. Prometheus 3.0의 일부로 릴리스된 새 UI는 완전한 재작성이며, 더 깔끔하고 덜 어수선하며 내부적으로 더 현대적이 되도록 목표해요. 하지만 아직 완전한 기능과 실전 테스트가 되지 않아서, 일부 사용자는 여전히 이전 UI를 선호할 수 있어요.

--enable-feature=old-ui

메타데이터 WAL 레코드 (Metadata WAL Records)

--enable-feature=metadata-wal-records

활성화하면 Prometheus는 메타데이터를 인메모리로 저장하고 시리즈별로 WAL 레코드로 메타데이터 변경을 추적해요.

새로운 remote write 2.0으로 메타데이터를 보내고 싶다면 이것을 사용해야 해요.

컴팩션 시작 시간 지연 (Delay compaction start time)

--enable-feature=delayed-compaction

청크 범위의 최대 10%까지의 무작위 오프셋이 Head 컴팩션 시작 시간에 추가돼요. 이는 Prometheus 인스턴스들이 동시 컴팩션을 피하고 공유 리소스에 대한 부하를 줄이는 데 도움을 줘요.

자동 Head 컴팩션과 그것에서 직접 비롯된 작업만 이 지연의 대상이에요.

여러 번의 연속적인 Head 컴팩션이 가능한 경우 첫 번째 컴팩션만 이 지연을 겪어요.

이 지연 동안 Head는 시리즈 서빙과 추가를 포함한 평소 작업을 계속한다는 점에 유의하세요.

컴팩션의 지연에도 불구하고 만들어진 블록은 지연이 없었을 때와 같은 방식으로 시간 정렬돼요.

PromQL 엔진의 __name__ 라벨 제거 지연 (Delay name label removal for PromQL engine)

--enable-feature=promql-delayed-name-removal

활성화하면 Prometheus는 PromQL 쿼리 결과에서 __name__ 라벨을 제거하는 방식(필요한 함수와 표현식에 대해)을 바꿔요. 구체적으로, 파생 메트릭을 만드는 표현식이나 함수가 평가될 때마다가 아니라 쿼리 평가의 마지막 단계로 제거를 지연해요.

이를 통해 label_replace와 label_join 함수로 __name__ 라벨을 선택적으로 보존할 수 있고, __name__ 라벨에 regex 매처를 적용할 때 생길 수 있는 "vector cannot contain metrics with the same labelset" 오류를 방지하는 데 도움이 돼요.

쿼리의 일부를 따로 평가하는 것은 여전히 labelset 충돌을 일으킨다는 점에 유의하세요. 이것은 보통 쿼리의 중간 결과를 수동으로 또는 PromLens 같은 도구로 분석할 때 발생해요.

쿼리가 이미 제거된 __name__ 라벨을 참조하면, 이 기능 플래그가 설정된 동안 그 동작이 바뀔 수 있어요. (예: sum by (__name__) (rate({foo="bar"}[5m])), GitHub의 세부 내용 참조.) 이런 쿼리는 드물게 발생하고 고치기 쉬워요. (위 예에서 by (__name__)를 제거하면 기능 플래그가 없을 때는 아무것도 바뀌지 않고, 기능 플래그가 있을 때 가능한 문제를 고쳐요.)

__name__으로 집계하고 지연된 이름 제거가 있는 샘플과 없는 샘플을 같은 그룹에 넣는 쿼리를 만들 수 있어요. 그 경우 이름이 영향받는 그룹에서 제거돼요. 이 경우는 실용적인 목적을 충족하는 쿼리에서는 거의 발생하지 않는다는 점에 유의하세요.

OTLP 델타 변환 (OTLP Delta Conversion)

--enable-feature=otlp-deltatocumulative

활성화하면 Prometheus는 OTLP 메트릭을 델타 시간성에서 누적(cumulative) 등가물로 변환하는데, 버리는 대신요. 이것은 otlp-native-delta-ingestion과 함께 활성화할 수 없어요.

이것은 OTel 수집기의 deltatocumulative를 기본 설정으로 사용해요.

델타 변환은 시간에 따라 시리즈별로 델타 변경을 집계하기 위해 인메모리 상태를 유지해요. Prometheus가 재시작하면 이 상태가 손실되어 집계가 0부터 다시 시작돼요. 결과적으로 누적 시리즈에서 카운터 리셋이 발생해요.

이 상태는 비활성 시리즈에 대해 주기적으로(max_stale) 지워져요.

인메모리 상태가 뮤텍스로 보호되기 때문에 이것을 활성화하면 성능에 부정적인 영향이 있을 수 있어요. 누적 전용 OTLP 요청은 영향받지 않아요.

OTLP 네이티브 델타 지원 (OTLP Native Delta Support)

--enable-feature=otlp-native-delta-ingestion

활성화하면 변환 없이 원시 샘플 값을 저장하는 델타 OTLP 메트릭의 네이티브 수집을 허용해요. 이것은 otlp-deltatocumulative와 함께 활성화할 수 없어요.

현재 StartTimeUnixNano 필드는 무시되고, 델타에는 알 수 없는 메트릭 메타데이터 타입이 주어져요.

델타 지원은 매우 초기 개발 단계이며 수집과 쿼리 과정은 시간이 지나면서 바뀔 수 있어요. 공개 제안은 prometheus/proposals#48을 보세요.

쿼리 (Querying)

우리는 사용자가 델타와 기존 PromQL 함수를 실험하도록 권장해요; 우리는 피드백을 수집하고 델타 쿼리 경험을 개선하기 위한 기능을 만들 것입니다.

표준 PromQL 카운터 함수인 rate()와 increase()는 누적 메트릭을 위해 설계되었으며 델타 메트릭에 사용하면 잘못된 결과를 낸다는 점에 유의하세요. 이것은 미래에 바뀔 수 있지만, 지금은 델타 메트릭에 비슷한 결과를 얻으려면 sum_over_time()이 필요해요.

  • sum_over_time(delta_metric[]): 지정된 시간 범위에 걸친 델타 값의 합을 계산.

  • sum_over_time(delta_metric[]) / : 델타 메트릭의 초당 비율을 계산.

이것들은 ``이 메트릭의 수집 간격의 배수가 아니면 잘 작동하지 않을 수 있어요. 예를 들어 sum_over_time(delta_metric[1m]) / 1m 범위 쿼리(1m 스텝으로)를 하는데 메트릭의 수집 간격이 10m이면, 그래프는 더 낮고 일정한 값의 10개 포인트가 아니라 10분마다 높은 rate 값의 단일 포인트를 보여줄 거예요.

현재의 함정 (Current gotchas)

델타 메트릭이 페더레이션을 통해 노출되면, 수집 간격이 페더레이트된 엔드포인트의 스크랩 간격과 같지 않을 때 데이터가 잘못 수집될 수 있어요.

메트릭 이름이나 라벨에 시간성 표시가 없으므로 메트릭이 델타인지 누적인지 알아내기 어려워요. 지금은 델타와 누적 메트릭을 섞어 수집한다면 그것들을 구분하기 위해 자신의 라벨을 명시적으로 추가하는 것을 권장해요. 미래에 우리는 타입 라벨을 도입해 메트릭 타입을 일관되게 구분하고 잠재적으로 PromQL 함수를 타입 인식하게 만들(예: 누적 전용 함수가 델타 메트릭에 사용될 때 경고 제공) 계획이에요.

같은 타임스탬프에 여러 샘플이 수집되고 있으면 하나의 포인트만 유지돼요 - 샘플은 합산되지 않아요(이것은 일반적으로 Prometheus가 작동하는 방식이에요 - 중복 타임스탬프 샘플은 거부됨). 어떤 집계든 Prometheus에 샘플을 보내기 전에 수행되어야 해요.

타입과 단위 라벨 (Type and Unit Labels)

--enable-feature=type-and-unit-labels

활성화하면 Prometheus는 PROM-39 제안에서 설계한 대로 추가적이고 예약된 __type__와 __unit__ 라벨을 주입하기 시작해요.

이 라벨들은 OpenMetrics Text, Prometheus Text, Prometheus Proto, Remote Write 2, OTLP 같은 기존 스크랩·수집 형식의 메타데이터 구조에서 비롯돼요. 사용자가 제공한 모든 __type__와 __unit__ 라벨은 덮어써져요.

PromQL 계층은 이 라벨들을 __name__이 처리되는 것과 같은 방식으로 처리해요. 예: -나 + 같은 특정 연산에서 버려지고 promql-delayed-name-removal 기능의 영향을 받음.

이 기능은 중요한 메타데이터 정보가 샘플과 PromQL 계층에서 직접 접근 가능하게 해 줘요.

특히 다음 사용자에게 유용해요:

  • 타입이나 단위를 기준으로 메트릭을 선택하고 싶은 경우.

  • 같은 메트릭 이름과 다른 타입·단위의 시리즈 사례를 처리하고 싶은 경우. 예: 네이티브 히스토그램 마이그레이션이나 OTLP 엔드포인트의 OpenTelemetry 메트릭을 번역 없이.

미래에는 이에 의존하는 더 많은 작업이 계획되어 있어요. 예: 잘못된 타입이 잘못된 함수에 사용될 때 도움이 되는 풍부한 PromQL UX, 자동 이름 변경, 델타 타입 등.

메타데이터 레코드와의 동작 (Behavior with metadata records)

이 기능이 활성화되고 메타데이터 WAL 레코드가 존재할 때, 흔치 않은 경우로 둘 사이에서 타입이나 단위가 다르면 Prometheus 출력은 __type__와 __unit__ 라벨 값을 선호하려 해요. 예를 들어 Remote Write 2.0에서 메타데이터 레코드가 어떤 이유로(예: 버그) "counter"라고 하지만 __type__="gauge"라면 원격 타임시리즈는 gauge로 설정돼요.

캐시 없는 IO 사용 (Use Uncached IO)

--enable-feature=use-uncached-io

실험적이고 Linux에서만 사용 가능해요.

활성화하면 청크 쓰기가 페이지 캐시를 우회해요. 주요 목표는 페이지 캐시 동작에 대한 혼란을 줄이고 오도하는 캐시 성장에 반응한 메모리 과잉 할당을 방지하는 것이에요.

이것은 현재 direct I/O로 구현돼요.

자세한 내용은 제안을 보세요.

XOR2 청크 인코딩 (XOR2 chunk encoding)

--enable-feature=xor2-encoding

경고: 이것은 매우 실험적이고 위험한 설정이에요.

  • XOR2로 인코딩된 청크는 그 인코딩을 지원하지 않는 오래된 Prometheus 버전이 읽을 수 없어요. 일단 활성화하고 데이터가 쓰이면, 디스크에서 블록을 수동으로 삭제해야 해요. 그렇지 않으면 Prometheus가 모든 쿼리에 오류를 반환해요.

  • 우리는 여전히 최종 인코딩을 실험 중이에요. 지금으로서는 이 인코딩이 어떤 Prometheus 버전에서도 바뀔 수 있어요. 모든 영속 블록 데이터가 버전 사이에 손실될 거예요.

  • 이 인코딩은 새것이므로, 다운스트림 도구와 LTS 시스템이 아직 지원하지 않을 수 있어요(예: Thanos sidecar가 업로드한 블록).

이 설정은 부동소수점 샘플에 대해 새 XOR2 청크 인코딩을 활성화하는데, 일반적인 Prometheus 워크로드에서 기본 XOR 인코딩보다 더 나은 디스크 압축을 제공해요. 이 형식은 또한 Start Timestamp(ST)를 저장할 수 있게 해 줘요.

네이티브 히스토그램과 부동소수점 히스토그램을 위한 동등한 ST 지원 청크 인코딩은 histograms-st-encoding 플래그를 보세요. 두 플래그는 독립적이에요.

히스토그램 ST 청크 인코딩 (Histogram ST chunk encoding)

--enable-feature=histograms-st-encoding

경고: 이것은 매우 실험적이고 위험한 설정이에요.

  • histogramST와 floathistogramST로 인코딩된 청크는 그 인코딩을 지원하지 않는 오래된 Prometheus 버전이 읽을 수 없어요. 일단 활성화하고 데이터가 쓰이면, 디스크에서 블록을 수동으로 삭제해야 해요. 그렇지 않으면 Prometheus가 모든 쿼리에 오류를 반환해요.

  • 우리는 여전히 최종 인코딩을 실험 중이에요. 지금으로서는 이 인코딩이 어떤 Prometheus 버전에서도 바뀔 수 있어요. 모든 영속 블록 데이터가 버전 사이에 손실될 거예요.

  • 이 인코딩은 새것이므로, 다운스트림 도구와 LTS 시스템이 아직 지원하지 않을 수 있어요(예: Thanos sidecar가 업로드한 블록).

이 설정은 네이티브 히스토그램과 부동소수점 히스토그램 샘플에 대해 새 histogramST와 floathistogramST 청크 인코딩을 활성화해요. 이 인코딩들은 해당 히스토그램 청크 형식을 Start Timestamp(ST) 헤더와 샘플별 ST 인코딩으로 확장해요. 이것은 xor2-encoding이 부동소수점 청크에 하는 것과 동등해요. 이 플래그는 부동소수점 청크에 영향을 주지 않아요.

인코딩은 구성 파일의 storage.tsdb 섹션에 있는 chunk_encoding.floats 필드로 각 구성 리로드에서도 제어할 수 있어요. chunk_encoding.floats: xor로 설정하면 --enable-feature=xor2-encoding이 설정돼 있어도 표준 XOR 인코딩을 강제하고, chunk_encoding.floats: xor2로 설정하면 --enable-feature=xor2-encoding이 활성화되어야 해요.

st-storage가 없으면 XOR과 XOR2는 호환 인코딩이므로, chunk_encoding.floats로 인코딩을 바꿔도 현재 청크를 자르지 않아요. 새 인코딩은 현재 청크가 어떤 이유(크기, 시간 범위, 샘플 수)든 다음에 잘릴 때 적용돼요. st-storage도 활성화되면 XOR과 XOR2는 XOR 청크가 시작 타임스탬프를 저장하지 않으므로 호환되지 않아서, 인코딩 변경 후 다음 append에서 진행 중인 청크가 잘려요.

--enable-feature=st-storage가 XOR2 인코딩을 자동으로 활성화하지는 않는다는 점에 유의하세요. 하지만 st-storage가 활성인 동안 chunk_encoding.floats: xor를 설정하는 것은 XOR 청크가 시작 타임스탬프를 저장하지 않으므로 구성 리로드에서 거부돼요.

확장 범위 셀렉터 (Extended Range Selectors)

--enable-feature=promql-extended-range-selectors

PromQL 범위·인스턴트 셀렉터에 대한 실험적 anchored와 smoothed 수정자를 활성화해요. 이 수정자들은 rate와 increase 같은 함수에서 특히 누락되거나 불규칙한 데이터로 범위 경계가 처리되는 방식에 대한 더 많은 제어를 제공해요.

네이티브 히스토그램은 아직 확장 범위 셀렉터에서 지원되지 않아요.

anchored

범위 시작의 (lookback delta 안의) 가장 최근 샘플을 사용하거나, lookback delta 안에 샘플이 없으면 범위 안의 첫 번째 샘플을 사용해요. 범위 안의 마지막 샘플도 범위 끝에 사용돼요. 외삽이나 보간이 적용되지 않으므로, 샘플 값 사이의 직접적인 차이를 얻는 데 유용해요.

Anchored 범위 셀렉터는 다음과 함께 작동해요: resets, changes, rate, increase, delta.

예제 쿼리: increase(http_requests_total[5m] anchored)

참고: increase 함수와 anchored 수정자를 사용하면 반환되는 결과는 정수예요.

smoothed

범위 셀렉터에서 범위 경계의 값을 선형 보간하며, 경계 전후의 샘플 값을 사용해 불규칙한 스크랩과 누락된 샘플에 강한 개선된 추정을 제공해요. 하지만 작동하려면 평가 간격 이후의 샘플이 필요해요. 아래 참고를 보세요.

인스턴트 셀렉터에서는 평가 타임스탬프에서 그 지점 전후의 샘플을 사용해 값을 선형 보간해요.

Smoothed 범위 셀렉터는 다음과 함께 작동해요: rate, increase, delta.

예제 쿼리: rate(http_requests_total[step()] smoothed)

알림과 기록 규칙에 대한 참고: smoothed 수정자는 평가 간격 이후의 샘플이 필요하므로, 알림이나 기록 규칙에 직접 사용하면 평가 시점에 미래 샘플이 없으므로 보통 결과를 과소평가해요. smoothed를 규칙에서 안전하게 사용하려면 계산 창이 완전히 과거에 있고 필요한 모든 샘플이 사용 가능하도록 규칙 그룹에 query_offset을 적용해야 해요(문서 참조). 중요한 알림의 경우 오프셋을 적어도 하나의 스크랩 간격으로 설정하세요. 덜 중요하거나 더 회복력 있는 사용 사례에는 더 큰 오프셋(여러 스크랩 간격)을 고려해 누락된 스크랩을 허용하세요.

자세한 내용은 설계 문서를 보세요.

참고: 확장 범위 셀렉터는 서브쿼리에서 지원되지 않아요.

이진 연산자 fill 수정자 (Binary operator fill modifiers)

--enable-feature=promql-binop-fill-modifiers

PromQL 이진 연산자에 대한 실험적 fill(), fill_left(), fill_right() 수정자를 활성화해요. 이 수정자들은 이진 연산 양쪽의 누락된 일치 항목을 제공된 기본 샘플 값으로 채우는 것을 허용해요.

예제 쿼리:

  rate(successful_requests[5m])
+ fill(0)
  rate(failed_requests[5m])

자세한 내용과 예제는 fill 수정자 문서를 보세요.

검색 API (Search API)

--enable-feature=search-api

메트릭 이름, 라벨 이름, 라벨 값을 퍼지 매칭과 필터링 지원으로 발견하기 위한 실험적 검색 API 엔드포인트를 활성화해요. 자세한 내용은 검색 API 문서를 보세요.

--web.search.max-limit 플래그(기본 10000)는 검색 엔드포인트가 받아들이는 limit 쿼리 파라미터를 제한해요. 더 높은 limit의 요청은 HTTP 400으로 거부돼요. 기본 응답 제한(100)은 이 최대값으로 조용히 클램프되므로, 운영자가 더 작은 상한을 설정해도 no-limit 요청을 깨뜨리지 않아요. 플래그를 0으로 설정하면 상한이 완전히 비활성화돼요. 신뢰할 수 있는 네트워크 밖에 노출된 엔드포인트에는 권장되지 않는데, 단일 클라이언트가 한 응답으로 전체 인덱스를 요청할 수 있기 때문이에요.

더 알아보기 (Learn more)