본문으로 건너뛰기
관측성
메트릭
Cortex vs VictoriaMetrics
목차

Cortex vs VictoriaMetrics 비교와 선택

1. 한눈 비교와 선택 조건

Prometheus의 remote_write를 받는 Cortex·Grafana Mimir와, vmagent 또는 Prometheus가 전송하는 VictoriaMetrics cluster를 비교합니다. 단일 서버 단계의 선택은 Prometheus와 VictoriaMetrics의 확장 방식과 운영 비용 비교에, 여러 클러스터를 연결하는 구성은 여러 클러스터의 메트릭을 모으는 Thanos와 VictoriaMetrics 구성에 있습니다.

근거 표기 — ✓ 1차 출처 확인 · Ⓑ 공개 벤치마크 · Ⓥ 벤더 주장 · ≈ 추정 · ? 미확인 · Σ 종합 판단. 각 절 끝의 ‘근거와 측정 조건’에 조건과 출처를 모았습니다.

한눈 비교표

비교 축CortexMimirVictoriaMetrics
장기 저장 위치오브젝트 스토리지오브젝트 스토리지vmstorage 로컬 디스크
복제와 저장 용량compactor 중복 제거
장기 용량 대략 1배		compactor 중복 제거
장기 용량 대략 1배		복제 계수 N에 따라 N배
조회 시 dedup
외부 의존성오브젝트 스토리지
캐시(memcached·redis·in-memory)		오브젝트 스토리지·memcached 캐시
ingest storage는 Kafka 추가		없음
쿼리 언어·엔진PromQL·Prometheus 엔진PromQL·MQEMetricsQL
멀티테넌시테넌트별 런타임 overrides테넌트별 런타임 overrides테넌트 식별 지원
OSS 테넌트별 수집·시리즈 limit 없음
다운샘플링없음없음Enterprise만
라이선스Apache-2.0AGPL-3.0OSS Apache-2.0
Enterprise 상용
현재 버전v1.21.13.2.4v1.155.0
LTS v1.148.x·v1.136.x(Enterprise)

장점·단점 표

제품장점단점맞는 조건
CortexApache-2.0
CNCF 거버넌스
테넌트별 limit		다운샘플링 미제공
다른 두 제품보다 적은 최근 52주 커밋·작성자 수		Apache-2.0·재단 거버넌스 필요
테넌트별 한도 필요
Mimir오브젝트 스토리지 장기 보존
테넌트별 limit·shuffle sharding		ingest storage의 Kafka 운영
classic → ingest storage 이전 시 병행 클러스터		테넌트 격리 우선
AGPL-3.0 수용
ingest storage 선택 시 Kafka 운영 가능
VictoriaMetrics외부 의존성 없는 구성
수신·저장·조회 역할 분리		복제 계수만큼 디스크 증가
MetricsQL 계산 차이
다운샘플링·LTS의 Enterprise 제한		로컬 디스크 중심 운영
기존 쿼리 결과 검증 가능
근거와 측정 조건
항목값·조건출처근거
Cortex 버전v1.21.1(2026-06-05). v1.22.0은 rc.3(2026-10-06)까지만 나옴Cortex 릴리스✓
Mimir 버전3.2.4(2026-10-30). 3.1.x도 병행 패치(3.1.9). 3.0.0은 2025-10-31Mimir 릴리스✓
VictoriaMetrics 버전v1.155.0(2026-10-26). LTS는 v1.148.x와 v1.136.xVictoriaMetrics 릴리스, LTS 문서✓
Cortex 중복 제거compactor가 복제로 여러 블록에 쓰인 샘플을 중복 제거Cortex compactor 문서✓
Mimir 중복 제거 규모10억 active series 테스트에서 30억 시리즈가 들어와 compaction 중 10억으로 중복 제거Grafana Labs 블로그(2022-04-08)Ⓥ
ingest storage 중복 제거compactor가 여러 ingester 블록을 합쳐 중복 제거Mimir ingest storage 문서✓
VM 용량 산정공식에 Replication Factor가 곱해짐VictoriaMetrics 용량 산정 가이드✓
Cortex 링 KV·캐시Consul, etcd, memberlist. 캐시는 memcached·redis·in-memory, 다단 가능Cortex 아키텍처·querier 문서✓
VM 외부 의존성없음. 오브젝트 스토리지는 vmbackup 대상VictoriaMetrics cluster 문서✓
Cortex·Mimir limit런타임 overrides. Cortex 1.21 Overrides API. Mimir 3.1은 헤더 메타데이터 기반 부분 limitCortex v1.21.0 릴리스, Mimir 3.1 릴리스✓
VM tenant limitOSS에는 tenant별 수집·시리즈 limit 없음. 노드 단위 합산 limit만. tenant별 속도 제한은 vmgateway(Enterprise)VictoriaMetrics cluster·Enterprise 문서✓
shuffle shardingCortex·Mimir 모두 기본 꺼짐. Mimir는 쓰기 경로에서 켜면 읽기 경로도 자동 적용Cortex·Mimir shuffle sharding 문서✓
Cortex 엔진기본 Prometheus PromQL 엔진. Thanos 엔진은 experimental(-querier.thanos-engine). 1.21에서 논리 플랜 분할·projection pushdown 추가Cortex v1guarantees·querier 문서, v1.21.0 릴리스✓
Mimir MQE3.0부터 querier·query-frontend 기본. -querier.query-engine=prometheus로 복귀. 관련 flag는 도움말에서 experimental 표시Mimir 3.0 릴리스 노트, help-all, versioning 문서✓
MetricsQL 차이rate·increase 외삽 없음, 직전 샘플 포함, 창 생략 시 step과 스크레이프 간격 중 큰 값, NaN 제거, scalar 처리, offset·WITH 확장VictoriaMetrics MetricsQL 문서✓
Cortex 다운샘플링로드맵 항목뿐. thanosconvert가 Thanos 다운샘플 블록을 건너뜀Cortex roadmap, 마이그레이션 문서✓
Mimir 다운샘플링웨비나 Q&A에서 미제공이라 답변. 2022년 잔여 코드 제거 PR #3024, 2023년 제안 PR #5028은 openGrafana 커뮤니티 Q&A, Mimir PRⓋ
VM 다운샘플링-downsampling.period, 다단계, tenant별. 마지막 샘플 유지라 gauge·summary 일부 손실. 다중 보존기간(-retentionFilter)도 EnterpriseVictoriaMetrics Enterprise 문서✓
LTS 범위문서 원문은 “LTS releases are published only for Enterprise versions”VictoriaMetrics LTS 문서✓
라이선스Cortex Apache-2.0, Mimir AGPL-3.0, VM OSS Apache-2.0(Enterprise는 상용)각 프로젝트 저장소✓
Cortex 거버넌스CNCF Incubating(2018-09-20 Sandbox, 2020-08-20 Incubating)CNCF 프로젝트 페이지✓
classic 이전 경로새 클러스터를 병행 구성하고 이중 쓰기 뒤 읽기 이전Grafana Mimir 3.0 블로그Ⓥ

2. 아키텍처와 배포 기본값

Grafana 문서는 Mimir ingest storage를 안정적이며 권장하는 방식으로 설명합니다. 바이너리의 -ingest-storage.enabled는 기본 꺼짐이고, Helm 차트 mimir-distributed 6.0은 ingest storage가 기본입니다. 차트에 포함된 Kafka는 데모용 단일 노드이며, 문서는 운영에 외부 Kafka 호환 클러스터를 쓰라고 안내합니다.

Cortex

Prometheus agent가 보낸 샘플은 distributor가 검증해 ingester에 쓰고, 2시간 블록이 오브젝트 스토리지로 올라갑니다. querier는 최근 구간은 ingester에서, 과거 구간은 store-gateway에서 읽습니다.
도식 텍스트
  • Prometheus — agent 모드
  • distributor — limit 검증
  • ingester — 메모리·WAL
  • 오브젝트 스토리지 — 2시간 블록
  • querier — frontend 경유
  • store-gateway — 블록 조회
  • ruler — 규칙·경보
  • write
  • 쿼럼
  • 블록
  • 읽기
  • 최근
  • 과거
  • 조회

Mimir ingest storage

ingest storage에서는 distributor가 Kafka 파티션에 먼저 쓰고, 파티션 하나를 소비하는 ingester가 블록을 만들어 올립니다. 읽기 경로는 Cortex와 같은 모양입니다.
도식 텍스트
  • Prometheus — agent 모드
  • distributor — limit 검증
  • Kafka — 파티션 복제
  • ingester — 파티션 소비
  • 오브젝트 스토리지 — 2시간 블록
  • querier — scheduler 경유
  • store-gateway — 블록 조회
  • ruler — 규칙·경보
  • write
  • 파티션
  • 소비
  • 블록
  • 읽기
  • 최근
  • 과거
  • 조회

VictoriaMetrics cluster

vminsert는 같은 샘플을 서로 다른 vmstorage 둘에 기록하고, vmselect는 모든 vmstorage에서 데이터를 받아 계산합니다. 해시 링과 외부 저장소는 없습니다. RF=2 예시입니다.
도식 텍스트
  • vmagent — scrape·buffer
  • vminsert — 해시 분배
  • vmstorage A — 로컬 디스크
  • vmstorage B — 로컬 디스크
  • vmselect — 조회 시 dedup
  • vmalert — 규칙·경보
  • write
  • 사본 1
  • 사본 2
  • 조회
  • 조회
  • 조회

VictoriaMetrics 문서는 초당 100만 데이터 포인트 미만이면 single-node를 권합니다.

근거와 측정 조건
항목값·조건출처근거
Cortex 쓰기·읽기 경로distributor, ingester(메모리+WAL, 2시간 블록 업로드), query-frontend(선택), querier, store-gateway, compactorCortex 아키텍처 문서✓
Mimir 두 아키텍처3.0부터 ingest storage와 classic 지원. 문서에 “stable and the preferred way”Mimir 아키텍처 문서✓
Mimir 기본값바이너리 -ingest-storage.enabled는 기본 꺼짐. Helm 차트 6.0은 기본 ingest storage이고 데모용 단일 노드 Kafka를 함께 띄움Mimir 3.2.4 flag 도움말, Helm 6.0 릴리스 노트✓
ingest storage 쓰기Kafka가 복제·영속화를 확인하면 응답. 기본은 시리즈 하나가 파티션 하나. ingester는 파티션 하나 소비Mimir ingest storage 문서✓
VM 컴포넌트vminsert(consistent hashing), vmstorage(stateful), vmselect. -storageNode 목록 직접 지정, 자동 발견은 EnterpriseVictoriaMetrics cluster 문서✓
single-node 권고초당 100만 데이터 포인트 미만이면 single-node 권장VictoriaMetrics cluster 문서✓

3. 공개 벤치마크·지표

지표CortexMimirVictoriaMetrics측정자·조건
CPU (2019)1.08코어—cluster 1.14코어
single 0.49코어		adidas, PromCon EU 2019
DynamoDB 청크 저장 시절 Cortex
약 430K·900K 시리즈, 약 88K samples/s
메모리 (2019)24.15GiB—cluster 13.4GiB
single 11.94GiB		위 측정
샘플당 바이트 (2019)3.68B
DynamoDB 1133 WCU 별도		—1.20B위 측정
할당 CPU·RAM—43.2 CPU·283GiB44 CPU·208GiBVictoriaMetrics 측, 2022-09-09
Mimir 2.2.0(RF 3)·VM 1.80.0(RF 2), GKE e2-standard-16
약 550만 active series·36만 samples/s·24시간
평균 CPU 사용량——Mimir보다 약 1.7배 적음위 시험
평균 RAM 사용량——Mimir보다 약 5배 적음위 시험
저장 용량—로컬 369GiB + 오브젝트 스토리지 149.7GiB49GiB위 시험
instant 쿼리 p99—약 47초약 20초위 시험; range 쿼리 미측정
대규모 시험—10억 active series
약 1500 레플리카·7000 CPU 코어·30TiB RAM		—Grafana Labs, 시험 2021·발표 2022
단일 tenant
Mimir 3.0 발표 수치—리소스 최대 15% 감소
MQE 쿼리 최대 메모리 최대 92% 감소		—Grafana Labs 자체 주장
리소스는 대형 내부 클러스터 기준
샘플당 바이트약 0.7~3.5바이트
구버전 예시 환산		2바이트
산정 가정		압축 후 평균 1바이트 안팎
공식 안내값		Cortex chunks 시절 자료
Mimir compacted block·실측 아님
VM은 churn 증가 시 압축 악화
최근 52주 커밋4622,6481,546gh api 집계, 2026-11-01
최근 52주 고유 작성자44137104같은 집계, 봇 제외

위 표의 CPU·RAM·디스크·쿼리 수치는 2022년 9월 시점의 Mimir 2.2.0과 VictoriaMetrics 1.80.0을 VictoriaMetrics가 직접 잰 값입니다. 복제 계수도 3과 2로 달랐고, Cortex는 시험 대상이 아니었습니다. Cortex와 VictoriaMetrics를 직접 잰 공개 수치는 2019년 PromCon에서 adidas가 발표한 측정 하나입니다. 이때의 Cortex는 청크를 DynamoDB에 쓰던 구조라 지금의 blocks storage와 다르고, CPU는 비슷했으며 차이는 메모리와 샘플당 바이트에서 났습니다. VictoriaMetrics README의 “Cortex보다 RAM 최대 7배 적다"는 문구는 Prometheus와 VictoriaMetrics를 비교한 벤치마크 글을 링크하고 있어 Cortex 측정치로 볼 수 없습니다. 2022년 이후 둘 이상을 같은 조건에서 다시 잰 공개 벤치마크는 찾지 못했으므로, 지금도 이 시험이 유일한 직접 비교입니다. 샘플당 바이트는 구버전 환산값·산정 가정·공식 안내값이라 실측 순위로 읽을 수 없습니다.

2022년 이후 제품별 개선

그 뒤 각 프로젝트가 밝힌 개선은 아래와 같습니다. 대부분 벤더가 자기 제품을 잰 값이고 “최대"가 붙은 수치가 많아서, 2022년 격차가 얼마나 줄었는지 이 표로 계산할 수는 없습니다.

제품버전·시점개선공개 수치조건
Mimir2.7 (2023)store-gateway 스트리밍 기본값OOM 약 90% 감소Grafana 운영 환경 비교
Mimir2.9 (2023)넓은 매처 쿼리의 인덱스 조회 생략store-gateway 메모리 request 평균 30% 감소
일부 클러스터 최대 64%		Grafana 클러스터 적용 결과
Mimir2.10 (2023-09)라벨 자료구조 변경ingester 메모리 약 15% 감소라벨 패턴·테넌트 수에 따라 다름
Mimir2.13 (2024-07)OTLP 네이티브 변환distributor 메모리 최대 30%·CPU 최대 8% 감소OTLP 수집 경로
Mimir2.17~3.0 (2025)MQE 기본 엔진최대 메모리 92% 감소·39% 빠름Prometheus 엔진 대비, 쿼리 1종·입력 10만 시리즈
Mimir3.0 (2025-11)ingest storage(Kafka)Grafana Cloud TCO 25% 감소메인테이너 팟캐스트 발언, CPU·RAM 단독 수치 아님
VictoriaMetricsv1.82.0 (2022-10)MetricsQL regex 필터쿼리 최대 4배 빠름단순하지 않은 regex 필터 쿼리
VictoriaMetricsv1.92.0 (2023-07)TSID 인덱스를 일별로 전환메모리 최대 5배 감소churn이 높고 보존 기간이 긴 환경
VictoriaMetricsv1.133.0 (2026-01)파티션별 indexDB수치 없음, indexDB 디스크 감소기존 인덱스가 보존 밖으로 나간 뒤 효과
Cortex1.15 (2023-04)Thanos PromQL 엔진수치 없음실험 기능
Cortex1.20~1.21 (2025-11~2026-06)Parquet 저장·조회수치 없음실험 기능

Mimir는 2022년 시험에서 문제가 됐던 영역을 직접 다룬 수치를 가장 많이 냈습니다. 2022년 시험의 Mimir는 RF 3이었는데, Grafana는 3.0의 ingest storage가 RF 3·쿼럼 2 구조를 없앴다고 설명합니다. VictoriaMetrics의 저장 경로 개선 중 수치가 붙은 것은 v1.92의 “최대 5배"뿐이고, 그것도 churn이 높고 보존이 긴 환경에 한정됩니다. Cortex는 1.14~1.21.1의 공식 자료에서 자원·쿼리 성능 개선 수치를 찾지 못했습니다.

근거와 측정 조건
항목값·조건출처근거
adidas Cortex·VM 측정PromCon EU 2019. Cortex는 distributor 2·ingester 4, 청크 저장 DynamoDB. VM cluster는 insert 2·storage 4, single 2노드. 약 430K·900K 시리즈, 15초, 약 88K samples/s. CPU 1.08/1.14/0.49코어, 메모리 24.15/13.4/11.94GiB, 바이트/샘플 3.68/1.20/1.20B, DynamoDB 1133 WCU. 버전 미기재adidas 발표 슬라이드 23쪽Ⓑ
VM README의 Cortex 비교 문구“up to 7x less RAM than Prometheus, Thanos or Cortex"의 링크 대상은 “Prometheus vs VictoriaMetrics benchmark on node_exporter metrics” 글. “7x less storage” 문구도 같은 글을 링크VictoriaMetrics READMEⓋ
VM 측 Mimir 비교GKE e2-standard-16, Mimir 2.2.0(RF 3) vs VM 1.80.0(RF 2), node_exporter 6000타깃, 15초, 약 550만 active series, 36만 samples/s, 10분마다 타깃 1% churn, 24시간VictoriaMetrics 블로그(2022-09-09)Ⓑ
위 벤치마크 결과할당 Mimir 43.2 CPU/283GiB, VM 44 CPU/208GiB. 평균 CPU 약 1.7배, RAM 약 5배 차이. 디스크 VM 49GiB vs Mimir 369GiB+149.7GiB. instant p99 약 47초 vs 약 20초. 5배 부하에서 Mimir ingester OOMVictoriaMetrics 블로그(2022-09-09)Ⓑ
위 벤치마크 한계저자 명시: 24시간이라 compaction 미완 가능, active series 계산법 상이, range 쿼리 미측정, 저자가 Mimir에 익숙지 않음, 복제 계수 상이. Mimir 2.2 기준이라 MQE·ingest storage 이전같은 글Ⓑ
Grafana 10억 series 시험단일 tenant 10억 active series, 약 1500 레플리카·7000 CPU 코어·30TiB RAM, 20초 기준 약 5000만 samples/s 추정. SLO는 쓰기 요청 99.9%가 10초 미만Grafana Labs 블로그(2022-04-08)Ⓥ
Mimir 3.0 자체 주장대형 내부 클러스터 리소스 최대 15% 감소, MQE로 쿼리 최대 메모리 최대 92% 감소Grafana Mimir 3.0 블로그Ⓥ
Cortex 샘플당 바이트12시간·15초 간격에 약 2KB~10KB 예시를 환산하면 약 0.7~3.5바이트. 문서가 out of date로 표시Cortex 용량 계획 문서(구버전)≈
Mimir 샘플당 바이트compacted block 2바이트 가정. 15초 스크레이프, 1년 보존, 100만 active series당 13GB. 실측 아님Mimir 용량 계획 문서✓
VM 샘플당 바이트“less or around 1 byte after compression”VictoriaMetrics 용량 산정 가이드✓
52주 활동량커밋 462/2,648/1,546, 병합 PR 453/2,815/882, 고유 작성자(봇 제외) 44/137/104, stars 5,877/5,270/17,990. 2026-11-01 집계gh api 직접 집계✓
현행 버전 중립 벤치마크찾지 못함. VM이 prometheus-benchmark 도구를 공개(Cortex·Mimir·Thanos 대상 지원)VictoriaMetrics GitHub?
2022 이후 비교 벤치마크둘 이상을 비교한 새 측정은 찾지 못함. 2024 SlideShare는 2022 시험의 재발표. Criteo(2023-09) 평가는 원문 미열람. 2025~2026 비교 글은 자체 측정 없음검색·원문 대조?
Mimir 2.7 store-gateway“The streaming store-gateway reduced out-of-memory errors by about 90%”Grafana 블로그(2023-07-06)Ⓥ
Mimir 2.9 인덱스 조회 생략“reduce the store-gateway memory requests by 30%”, “in some clusters by up to 64%”Grafana 블로그(2023-08-21), Mimir 2.9.0 릴리스Ⓥ
Mimir 2.10 라벨 구조“Expect ingesters to use around 15% less memory with this change, depending on the pattern of labels used, number of tenants, etc.”Mimir 2.10.0 릴리스✓
Mimir 2.13 OTLP“reduces memory usage in the distributor by up to 30% and CPU usage by up to 8%”Mimir 2.13.0 릴리스✓
MQE“92% lower peak memory utilization and runs 39% faster than Prometheus’ PromQL engine”. 쿼리 sum by (group) 1종, 입력 10만 시리즈, 하드웨어·버전 미기재Grafana 블로그(2025-09-17)Ⓥ
Mimir ingest storage TCO“In Grafana Cloud, we reduced the Mimir TCO by 25% moving from the old architecture to the new architecture.” RF 3·쿼럼 2 제거 설명 포함Grafana 팟캐스트 전사(2026-01-02)Ⓥ
VM v1.82.0 regex“improve performance by up to 4x for queries containing non-trivial regex filters”VictoriaMetrics v1.82.0 CHANGELOG✓
VM v1.92.0 일별 인덱스“reduce memory usage by up to 5x for setups with high churn rate and long retention”VictoriaMetrics v1.92.0 CHANGELOG✓
VM v1.133.0 파티션별 indexDB“This should reduce disk space occupied by indexDBs as they get deleted along with the corresponding partitions”. 수치 없음VictoriaMetrics v1.133.0 CHANGELOG✓
Cortex 1.14~1.21.1Thanos 엔진(1.15)·Parquet(1.20~1.21)은 실험 기능, 공식 자료에 자원·쿼리 성능 수치 없음Cortex CHANGELOG, Parquet 문서✓

4. Thanos와 비교한 보존(retention) 설정

‘—‘는 공식 문서에서 해당 설정을 확인하지 못한 칸입니다.

항목ThanosCortexMimirVictoriaMetrics OSSVictoriaMetrics Enterprise
전역 보존 설정compactor의 해상도별 설정
기본 0d = 영구 보관		compactor_blocks_retention_period-compactor.blocks-retention-period 또는 compactor_blocks_retention_period-retentionPeriod
기본 1M·최소 24h		-retentionPeriod가 필터 보존 기간의 상한
해상도별 보존--retention.resolution-raw
--retention.resolution-5m
--retention.resolution-1h		——보존 하나만 지원—
테넌트별 보존—테넌트 overridesruntime overrides
compactor_blocks_retention_period·0이면 삭제 안 함		보존 하나만 지원—
시리즈별 보존——시리즈 단위 보존·삭제 미지원보존 하나만 지원-retentionFilter=filter:duration
-retentionPeriod 이하
여러 필터 일치 시 가장 짧은 값
삭제 방식컴팩션·다운샘플링 루프 직후
루프 실패 시 삭제 안 함		—compactor보존 밖 파티션은 새 달 첫날
완전히 보존 밖인 part는 백그라운드 병합 중 삭제		—

Thanos를 붙이는 방식은 Prometheus · Thanos · VictoriaMetrics 조립에서, 보존 기간에 따른 구성은 메트릭 장기보관 아키텍처 비교에서 따로 다룹니다.

근거와 측정 조건
항목값·조건출처근거
Thanos 보존compactor --retention.resolution-raw·--retention.resolution-5m·--retention.resolution-1h, 기본 0d = 영구 보관. 보존은 컴팩션·다운샘플링 루프 직후 적용되며 그 루프가 실패하면 삭제되지 않음Thanos Compactor 문서✓
Mimir 전역 보존compactor가 담당. -compactor.blocks-retention-period 또는 limits의 compactor_blocks_retention_periodMimir 보존 설정 문서✓
Mimir 테넌트별 보존runtime configuration의 overrides로 테넌트마다 compactor_blocks_retention_period 지정, 0이면 삭제 안 함Mimir 보존 설정 문서✓
Mimir 시리즈별 보존시리즈 단위 삭제·보존과 Prometheus Delete series API를 지원하지 않음Mimir 보존 설정 문서✓
Cortex 보존설정 레퍼런스의 limits에 compactor_blocks_retention_period가 있음(Mimir와 같은 이름, 테넌트 overrides 대상)Cortex 설정 파일 레퍼런스✓
VM 보존(OSS)-retentionPeriod 하나, 단위 h·d·w·M·y, 단위 없으면 월(31일), 기본 1M, 최소 24hVM single-server 문서 Retention✓
VM 삭제 시점데이터는 월 단위 파티션. 보존 밖 파티션은 새 달 첫날 삭제, 보존 밖 part는 백그라운드 병합 중 결국 삭제(part가 보존 밖으로 완전히 나가야 삭제)VM single-server 문서 Retention✓
VM 다중 보존(OSS)커뮤니티판은 보존 하나만 지원. 여러 보존이 필요하면 -retentionPeriod·-storageDataPath·-httpListenAddr를 달리한 인스턴스를 여러 개 띄움VM 문서 Multiple retentions✓
VM retention filtersEnterprise. -retentionFilter=filter:duration, -retentionPeriod 이하만 가능, 여러 필터에 걸리면 가장 짧은 값 적용VM 문서 Retention filters✓

5. 확인하지 못한 것

  • Mimir classic 아키텍처의 폐기 계획
  • Mimir ingest storage에서 ingester를 늘리고 줄이는 세부 절차
  • VictoriaMetrics vmstorage의 active series당 RAM 공식 수치
근거와 측정 조건
항목값·조건출처근거
classic 폐기 계획3.1·3.2 릴리스 노트와 versioning 문서에서 일정을 찾지 못함Mimir 릴리스 노트?
ingest storage 확장 절차파티션 수 조정과 묶임. 세부 절차는 조사하지 못함Mimir 문서?
VM 메모리현재 문서에 active series당 RAM 수치 없음. series ID 캐시 부족 시 성능 급락, 여유 RAM 50% 권장VictoriaMetrics FAQ, cluster 문서✓

참고 자료

마지막 수정 일자
ECS·EKS 타깃 자동 발견Cortex vs Thanos