Cilium 1.18 → Hubble로 east-west 트래픽 분석 — Prometheus 메모리 너무 큼

Hubble의 metric high-cardinality는 흔한 문제입니다. 3단계 접근.

1. metric scope 줄이기

Cilium configmap에서 metric label 명시 제거:

# cilium-config
hubble:
  metrics:
    enabled:
    - "flow:sourceContext=namespace;destinationContext=namespace"
    # pod 대신 namespace로 cardinality 다운
    - "drop"
    - "tcp"
    - "policy"

변경 후 — pod별 1.4M → namespace별 30K series. 95% 절감.

2. recording rules로 aggregation

Prometheus에서 자주 보는 view를 미리 aggregation. raw metric은 짧게 보관.

groups:
- name: hubble_aggregated
  interval: 30s
  rules:
  - record: hubble:flows_by_namespace
    expr: sum by (source_namespace, dest_namespace) (rate(hubble_flows_processed_total[1m]))

raw metric retention 7일 → aggregated 90일. 메모리 70% 절감.

3. Hubble Relay → ClickHouse

raw flow data는 Prometheus에 두지 말고 별도 ClickHouse로:

Hubble Relay → Vector → ClickHouse
# Grafana에서 ClickHouse 직접 query
# 자세한 flow 분석은 ClickHouse, summary는 Prometheus

ClickHouse는 compression 90%+ 효율적. flow 1억 row이 1.4GB.

저희 운영 패턴

1. Prometheus — namespace 단위 metric (Grafana 대시보드용)


2. ClickHouse — pod 단위 raw flow (사후 분석용)


3. 장기 보관 — S3 + Iceberg parquet 30일 후

총 메모리 28GB → 4GB, 디스크 비용 -68%, 가시성 유지.

Mimir(Grafana)로 Prometheus 대체도 옵션입니다. Mimir는 long-term storage S3 직결 + horizontal scale. high-cardinality에 강합니다. 다만 운영 복잡도 추가.