26Z12g

Young-Kyoo Kim·3일 전

Thanos에서 histogram_quantile과 rate 조합이 타임아웃을 일으키는 이유는 모든 le(bucket) 라벨과 Pod/Node별 시계열에 대해 rate()를 전부 계산한 뒤 Thanos Querier 메모리에서 집계하기 때문입니다. 특히 타임 레인지가 길거나 카디널리티가 높은 환경에서는 데이터량이 기하급수적으로 늘어납니다.

이를 해결하고 쿼리 속도를 획기적으로 줄이는 4가지 방법을 제안합니다.

1. Recording Rule 도입 (가장 근본적이고 확실한 해결책)

Thanos가 원본(Raw) 버킷 시계열 전체를 조회하지 않도록, 각 Prometheus 수집 단에서 미리 rate와 le 집계를 연산해두는 Recording Rule을 등록합니다.

Prometheus / Rule-Manager 설정 (PrometheusRule CRD 예시):

groups:
  - name: minio.rules
    rules:
      # 1단계: Prometheus 단에서 5m rate 및 le 집계를 미리 수행
      - record: job_le:minio_s3_requests_ttfb_seconds_bucket:rate5m
        expr: sum(rate(minio_s3_requests_ttfb_seconds_bucket[5m])) by (le, cluster, namespace, job)

Grafana / Thanos 쿼리 (변경 후):

histogram_quantile(0.95, sum(job_le:minio_s3_requests_ttfb_seconds_bucket:rate5m{cluster=~"$cluster", namespace=~"$namespace"}) by (le))
  • 효과: Thanos가 수천 개의 개별 Pod 버킷을 조회하는 대신, 이미 수집 단에서 계산된 단 몇 개의 le 시계열만 읽어오므로 쿼리 속도가 10~50배 이상 빨라집니다.

2. 평균 Latency 지표로 대체 (_sum / _count 활용)

p95p_{95}의 정확한 수치보다 전체적인 지연 시간 추이와 스파이크 감지가 목적이라면, Bucket 연산이 필요 없는 Sum/Count 지표 기반의 평균 지연 시간을 사용하는 것이 가장 빠릅니다.

sum(rate(minio_s3_requests_ttfb_seconds_sum{cluster=~"$cluster", namespace=~"$namespace"}[5m]))
/
sum(rate(minio_s3_requests_ttfb_seconds_count{cluster=~"$cluster", namespace=~"$namespace"}[5m]))
  • 효과: 10~20개의 le 버킷 시계열을 전수 조사할 필요 없이 단 2개의 카운터(_sum, _count)만 계산하므로 타임아웃 없이 연산이 마무리됩니다.

3. PromQL 타임 윈도우 및 레이블 필터 최적화

Recording Rule 적용이 당장 어렵다면 기존 쿼리에 아래 연산 최적화를 적용합니다.

  1. Grafana $__rate_interval 적용: [5m] 대신 [$__rate_interval]을 사용하여 대시보드 조회 기간(1일, 7일 등)에 맞춰 샘플링 간격을 가변적으로 조정합니다.
  2. 대상 레이블 사전 범위 축소: {le!=""} 내부에 불필요한 메트릭이 수집되지 않도록 job이나 api 레이블 필터를 쿼리 가장 안쪽에 명시합니다.
histogram_quantile(0.95, 
  sum(rate(minio_s3_requests_ttfb_seconds_bucket{cluster=~"$cluster", namespace=~"$namespace", job=~".*minio.*"}[$__rate_interval])) by (le)
)

4. Thanos Downsampling (다운샘플링) 활용

7일 이상의 장기 데이터를 볼 때 타임아웃이 난다면, Grafana Prometheus Data Source 설정에서 Downsampling resolution을 강제 지정합니다.

  • Grafana Data Source 설정:
  • Max source resolution →\rightarrow 5m 또는 1h 선택
  • PromQL에 direct 적용 (Thanos 전용):
    쿼리 옵션 파라미터로 step을 넓히거나 Thanos Query 옵션에서 step 크기를 크게 잡습니다.

권장 적용 순서

  1. 즉시 적용: 2번(평균 Latency 쿼리)으로 전환하여 대시보드 타임아웃을 즉시 해제합니다.
  2. 정식 조치: 1번(Recording Rule)을 Prometheus에 배포하여 정확한 p95p_{95} 수치를 고성능으로 조회할 수 있도록 아키텍처를 개선합니다.

===

Thanos에서 histogram_quantile과 rate 조합이 타임아웃을 일으키는 이유는 모든 le(bucket) 라벨과 Pod/Node별 시계열에 대해 rate()를 전부 계산한 뒤 Thanos Querier 메모리에서 집계하기 때문입니다. 특히 타임 레인지가 길거나 카디널리티가 높은 환경에서는 데이터량이 기하급수적으로 늘어납니다.

이를 해결하고 쿼리 속도를 획기적으로 줄이는 4가지 방법을 제안합니다.

1. Recording Rule 도입 (가장 근본적이고 확실한 해결책)

Thanos가 원본(Raw) 버킷 시계열 전체를 조회하지 않도록, 각 Prometheus 수집 단에서 미리 rate와 le 집계를 연산해두는 Recording Rule을 등록합니다.

Prometheus / Rule-Manager 설정 (PrometheusRule CRD 예시):

groups:
  - name: minio.rules
    rules:
      # 1단계: Prometheus 단에서 5m rate 및 le 집계를 미리 수행
      - record: job_le:minio_s3_requests_ttfb_seconds_bucket:rate5m
        expr: sum(rate(minio_s3_requests_ttfb_seconds_bucket[5m])) by (le, cluster, namespace, job)

Grafana / Thanos 쿼리 (변경 후):

histogram_quantile(0.95, sum(job_le:minio_s3_requests_ttfb_seconds_bucket:rate5m{cluster=~"$cluster", namespace=~"$namespace"}) by (le))
  • 효과: Thanos가 수천 개의 개별 Pod 버킷을 조회하는 대신, 이미 수집 단에서 계산된 단 몇 개의 le 시계열만 읽어오므로 쿼리 속도가 10~50배 이상 빨라집니다.

2. 평균 Latency 지표로 대체 (_sum / _count 활용)

p95p_{95}의 정확한 수치보다 전체적인 지연 시간 추이와 스파이크 감지가 목적이라면, Bucket 연산이 필요 없는 Sum/Count 지표 기반의 평균 지연 시간을 사용하는 것이 가장 빠릅니다.

sum(rate(minio_s3_requests_ttfb_seconds_sum{cluster=~"$cluster", namespace=~"$namespace"}[5m]))
/
sum(rate(minio_s3_requests_ttfb_seconds_count{cluster=~"$cluster", namespace=~"$namespace"}[5m]))
  • 효과: 10~20개의 le 버킷 시계열을 전수 조사할 필요 없이 단 2개의 카운터(_sum, _count)만 계산하므로 타임아웃 없이 연산이 마무리됩니다.

3. PromQL 타임 윈도우 및 레이블 필터 최적화

Recording Rule 적용이 당장 어렵다면 기존 쿼리에 아래 연산 최적화를 적용합니다.

  1. Grafana $__rate_interval 적용: [5m] 대신 [$__rate_interval]을 사용하여 대시보드 조회 기간(1일, 7일 등)에 맞춰 샘플링 간격을 가변적으로 조정합니다.
  2. 대상 레이블 사전 범위 축소: {le!=""} 내부에 불필요한 메트릭이 수집되지 않도록 job이나 api 레이블 필터를 쿼리 가장 안쪽에 명시합니다.
histogram_quantile(0.95, 
  sum(rate(minio_s3_requests_ttfb_seconds_bucket{cluster=~"$cluster", namespace=~"$namespace", job=~".*minio.*"}[$__rate_interval])) by (le)
)

4. Thanos Downsampling (다운샘플링) 활용

7일 이상의 장기 데이터를 볼 때 타임아웃이 난다면, Grafana Prometheus Data Source 설정에서 Downsampling resolution을 강제 지정합니다.

  • Grafana Data Source 설정:
  • Max source resolution →\rightarrow 5m 또는 1h 선택
  • PromQL에 direct 적용 (Thanos 전용):
    쿼리 옵션 파라미터로 step을 넓히거나 Thanos Query 옵션에서 step 크기를 크게 잡습니다.

권장 적용 순서

  1. 즉시 적용: 2번(평균 Latency 쿼리)으로 전환하여 대시보드 타임아웃을 즉시 해제합니다.
  2. 정식 조치: 1번(Recording Rule)을 Prometheus에 배포하여 정확한 p95p_{95} 수치를 고성능으로 조회할 수 있도록 아키텍처를 개선합니다.
profile
Young-Kyoo Kim
engineer
이전 포스트

26Z12f

다음 포스트

26Z12h

0개의 댓글