Prometheus 문서/스토리지 편집하기

==개요==
;STROAGE
;스토리지

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

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

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

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

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

<syntaxhighlight lang='text'>
./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
</syntaxhighlight>

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

또는 [https://prometheus.io/docs/operating/integrations/#remote-endpoints-and-storage 원격 읽기/쓰기 API]를 통해 외부 저장소를 사용할 수도 있습니다 . 이러한 시스템은 내구성, 성능 및 효율성이 크게 다르기 때문에 신중한 평가가 필요합니다.

파일 형식에 대한 자세한 내용은 [https://github.com/prometheus/prometheus/blob/release-2.51/tsdb/docs/format/README.md TSDB 형식]을 참조하세요 .

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

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

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

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

<syntaxhighlight lang='text'>
needed_disk_space = retention_time_seconds * ingested_samples_per_second * bytes_per_sample
</syntaxhighlight>

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

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

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

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

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

==원격 스토리지 통합==
===개요===
===기존 통합===
==OpenMetrics 형식에서 백필==
===개요===
===용법===
==기록 규칙 채우기==
===개요===
===용법===
===제한점===

==참고==
* https://prometheus.io/docs/prometheus/latest/storage/

[[분류:Prometheus 문서]]
@@ 78번째 줄: / 78번째 줄: @@
 만료된 블록 정리는 백그라운드에서 수행됩니다. 만료된 블록을 제거하는 데 최대 2시간이 걸릴 수 있습니다. 블록은 제거되기 전에 완전히 만료되어야 합니다.
-==원격 스토리지 연동==
+==원격 스토리지 통합==
-Prometheus의 로컬 스토리지는 단일 노드의 확장성과 내구성으로 제한됩니다. Prometheus 자체적으로 클러스터형 스토리지를 해결하려고 시도하는 대신, Prometheus는 원격 스토리지 시스템과 통합할 수 있는 인터페이스 세트를 제공합니다.
 ===개요===
-Prometheus는 세 가지 방법으로 원격 스토리지 시스템과 연동됩니다:
-* Prometheus는 표준화된 형식으로 원격 URL에 수집되는 샘플을 작성할 수 있습니다.
-* Prometheus는 표준화된 형식으로 다른 Prometheus 서버로부터 샘플을 받을 수 있습니다.
-* Prometheus는 원격 URL에서 표준화된 형식으로 샘플 데이터를 읽을 수 있습니다.
-[[파일:prometheus_remote_integrations.png]]
-읽기 및 쓰기 프로토콜은 모두 HTTP를 통해 인코딩되는 매우 압축된 프로토콜 버퍼를 사용합니다. 프로토콜은 아직 안정적인 API로 간주되지 않으며, Prometheus와 원격 스토리지 간의 모든 홉이 HTTP/2를 지원하는 것으로 안전하게 가정될 수 있게 되면, 향후 HTTP/2를 통해 gRPC를 사용하도록 변경될 수 있습니다.
-Prometheus에서 원격 스토리지 연동을 구성하는 방법에 대한 자세한 내용은 Prometheus 설정 문서의 원격 쓰기 및 원격 읽기 섹션을 참조하세요.
-빌트인 원격 쓰기 리시버는 <code>--web.enable-remote-write-receiver</code> 명령줄 플래그를 설정하여 활성화할 수 있습니다. 활성화된 경우, 원격 쓰기 리시버 엔드포인트는 <code>/api/v1/write</code>입니다.
-요청 및 응답 메시지에 대한 자세한 내용은, 원격 스토리지 프로토콜 버퍼 정의를 참조하세요.
-읽기 경로 상에서, Prometheus는 원격 엔드에서 레이블 셀렉터와 시간 범위 집합에 대한 원시(raw) 시리즈 데이터만 가져옵니다. 원시 데이터에 대한 모든 PromQL 평가는 여전히 Prometheus 자체에서 수행됩니다. 이는 필요한 모든 데이터를 먼저 쿼리하는 Prometheus 서버에 로드한 다음 그곳에서 처리해야 하기 때문에, 원격 읽기 쿼리에는 어느 정도 확장성 제한이 있음을 의미합니다. 그러나, PromQL의 완전한 분산 평가 지원은 당분간 어려울 것으로 보입니다.
 ===기존 통합===
 ==OpenMetrics 형식에서 백필==
 ===개요===