Prometheus 문서/스토리지

1 개요

STROAGE

스토리지

Prometheus에는 로컬 온디스크 시계열 데이터베이스가 포함되어 있지만 선택적으로 원격 스토리지 시스템과도 연계됩니다.

2 로컬 스토리지

Prometheus의 로컬 시계열 데이터베이스는 로컬 스토리지에 매우 효율적인 맞춤형 포맷으로 데이터를 저장합니다.

2.1 온디스크 레이아웃

인제스트된 샘플은 2시간 단위로 그룹화됩니다. 각 2시간 블록은 해당 시간 윈도우에 대한 모든 시계열 샘플이 포함된 Chunks 하위 디렉터리, 메타데이터 파일 및 인덱스 파일(지표 이름 및 레이블을 청크 디렉터리의 시계열에 색인화함)이 포함된 디렉터리로 구성됩니다. 청크 디렉터리의 샘플은 기본적으로 각각 최대 512MB의 하나 이상의 세그먼트 파일로 그룹화됩니다. API를 통해 시리즈가 삭제되면 삭제 기록은 별도의 삭제 표시 파일에 저장됩니다(청크 세그먼트에서 데이터를 즉시 삭제하는 대신).

들어오는 샘플의 현재 블록은 메모리에 보관되며 완전히 저장되지 않습니다. Prometheus 서버가 다시 시작될 때 재생할 수 있는 WAL(미리 쓰기 로그)을 통해 충돌로부터 보호됩니다. 미리 쓰기 로그(WAL) 파일은 128MB 세그먼트로 wal디렉토리에 저장됩니다. 이러한 파일에는 아직 압축되지 않은 원시 데이터가 포함되어 있습니다. 따라서 일반 블록 파일보다 훨씬 더 큽니다. Prometheus는 최소 3개의 미리 쓰기 로그 파일을 보관합니다. 트래픽이 많은 서버는 최소 2시간의 원시 데이터를 보관하기 위해 3개 이상의 WAL 파일을 보관할 수 있습니다.

Prometheus 서버의 데이터 디렉터리는 다음과 같습니다.

./data
├── 01BKGV7JBM69T2G1BGBGM6KB12
│   └── meta.json
├── 01BKGTZQ1SYQJTR4PB43C8PD98
│   ├── chunks
│   │   └── 000001
│   ├── tombstones
│   ├── index
│   └── meta.json
├── 01BKGTZQ1HHWHV8FBJXW1Y3W0K
│   └── meta.json
├── 01BKGV7JC0RY8A6MACW02A2PJD
│   ├── chunks
│   │   └── 000001
│   ├── tombstones
│   ├── index
│   └── meta.json
├── chunks_head
│   └── 000001
└── wal
    ├── 000000002
    └── checkpoint.00000001
        └── 00000000

로컬 스토리지의 한계는 클러스터링되거나 복제되지 않는다는 것입니다. 따라서 드라이브 또는 노드 중단 시 임의로 확장 가능하거나 내구성이 없으며 다른 단일 노드 데이터베이스처럼 관리되어야 합니다. 스토리지 가용성을 위해 RAID 사용이 권장되며, 백업을 위해 스냅샷이 권장됩니다. 적절한 아키텍처를 사용하면 수년간의 데이터를 로컬 스토리지에 보관할 수 있습니다.

또는 원격 읽기/쓰기 API를 통해 외부 저장소를 사용할 수도 있습니다 . 이러한 시스템은 내구성, 성능 및 효율성이 크게 다르기 때문에 신중한 평가가 필요합니다.

파일 형식에 대한 자세한 내용은 TSDB 형식을 참조하세요 .

3 압축(compaction)

초기 2시간 블록은 결국 백그라운드에서 더 긴 블록으로 압축됩니다.

압축은 보존 시간의 최대 10% 또는 31일 중 더 짧은 기간에 해당하는 데이터를 포함하는 더 큰 블록을 생성합니다.

4 운영 측면

Prometheus에는 로컬 스토리지를 설정하는 여러 플래그가 있습니다. 가장 중요한 것은 다음과 같습니다:

• --storage.tsdb.path: Prometheus가 데이터베이스를 작성하는 곳입니다. 기본값은 data/.
• --storage.tsdb.retention.time: 오래된 데이터를 제거할 시기. 기본값은 15d. storage.tsdb.retention이 플래그가 기본값이 아닌 다른 것으로 설정된 경우 재정의됩니다.
• --storage.tsdb.retention.size: 보유할 저장 블록의 최대 바이트 수입니다. 가장 오래된 데이터가 먼저 제거됩니다. 기본값은 0 또는 비활성화입니다. 지원되는 단위: B, KB, MB, GB, TB, PB, EB. 예: "512MB". 2의 거듭제곱을 기준으로 하므로 1KB는 1024B입니다. WAL 및 m 매핑 청크가 전체 크기로 계산되지만 이 보존을 유지하기 위해 영구 블록만 삭제됩니다. 따라서 디스크의 최소 요구 사항은 wal(WAL 및 체크포인트) 및 chunks_head (m-매핑된 헤드 청크) 디렉터리가 결합되어 차지하는 최대 공간입니다(2시간마다 최대).
• --storage.tsdb.retention: storage.tsdb.retention.time으로 대체되어 더 이상 사용되지 않습니다(deprecated).
• --storage.tsdb.wal-compression: 미리 쓰기 로그(WAL)의 압축을 활성화합니다. 데이터에 따라 추가적인 CPU 부하가 거의 없이 WAL 크기는 절반으로 줄어들 것으로 예상할 수 있습니다. 이 플래그는 2.11.0에서 도입되었으며 2.20.0에서는 기본적으로 활성화됩니다. 일단 활성화되면 Prometheus를 2.11.0 미만 버전으로 다운그레이드하려면 WAL을 삭제해야 합니다.

Prometheus는 샘플당 평균 1~2바이트만 저장합니다. 따라서 Prometheus 서버의 용량을 계획하려면 대략적인 공식을 사용할 수 있습니다.

needed_disk_space = retention_time_seconds * ingested_samples_per_second * bytes_per_sample

수집된 샘플의 비율을 낮추려면 스크레이핑하는 시계열 수를 줄이거나(타겟당 시리즈 수를 줄이거나) 스크레이핑 간격을 늘릴 수 있습니다. 그러나 시리즈 내 샘플 압축으로 인해 시리즈 수를 줄이는 것이 더 효과적일 수 있습니다.

어떤 이유로든 로컬 스토리지가 손상된 경우 문제를 해결하는 가장 좋은 전략은 Prometheus를 종료한 다음 전체 저장소 디렉터리를 제거하는 것입니다. 개별 블록 디렉터리나 WAL 디렉터리를 제거하여 문제를 해결할 수도 있습니다. 이는 블록 디렉터리당 약 2시간의 데이터가 손실된다는 것을 의미합니다. 다시 말하지만, Prometheus의 로컬 스토리지는 내구성이 뛰어난 장기 스토리지가 아닙니다. 외부 솔루션은 확장된 보존 및 데이터 내구성을 제공합니다.

주의:

주의: 복구할 수 없는 손상이 발생할 수 있으므로 POSIX와 호환되지 않는 파일 시스템은 Prometheus의 로컬 저장소에 대해 지원되지 않습니다. NFS 파일 시스템(AWS EFS 포함)은 지원되지 않습니다. NFS는 POSIX와 호환될 수 있지만 대부분의 구현은 그렇지 않습니다. 안정성을 위해 로컬 파일 시스템을 사용하는 것이 좋습니다.

시간 및 크기 보존 정책이 모두 지정된 경우 먼저 트리거되는 것이 사용됩니다.

만료된 블록 정리는 백그라운드에서 수행됩니다. 만료된 블록을 제거하는 데 최대 2시간이 걸릴 수 있습니다. 블록은 제거되기 전에 완전히 만료되어야 합니다.

8 참고

• https://prometheus.io/docs/prometheus/latest/storage/