[Prometheus] Data storage

Younghwan Cha·2023년 5월 18일
1

prometheus

목록 보기
2/5
post-thumbnail

prometheus storage 기본 구조


prometheus 의 폴더 구조는 아래와 같으며, 내부적으로 TSDB 를 사용한다.

prometheus
|-- 012345ABCDEF  -> 블록 Chunk 및 기타 메타데이터
|   |-- chunks
|   |   `-- 000001 -> 블록 Chunk 파일
|   |-- index      -> 색인을 위한 라벨 및 시간 inverted index 파일
|   |-- meta.json
|   `-- tombstones -> 삭제 여부를 나타내는 파일
|-- 012345ABCDEF
|-- 012345ABCDEF
|-- chunks_head
|-- lock -> 여러개의 prometheus 실행 방지를 위한 lock file
|-- queries.active -> 현재 실행 중인 쿼리를 저장. 쿼리 중 crash 시 확인 용도
`-- wal -> WAL (write ahead logging) 파일
	|-- 0000003
    |-- 0000004
    `-- checkpoint.0000002 -> 프로메테우스가 crash날 경우 복구를 위한 체크포인트 지점
        `-- 000000

데이터 저장 방식


prometheus 가 데이터를 저장하는 방식에는 크게 두가지가 존재한다

  1. local file system: 일반적인 chunk 블록 파일
  2. In memory: WAL (Write Ahead Logging) 파일 & 인메모리 버퍼

InfluxDB같은 DB와는 달리, 프로메테우스는 레코드를 수집하고 나서 해당 레코드 데이터를 즉시 스토리지에 저장하지 않는다. 일단 들어온 데이터를 인메모리 버퍼에 잔뜩 들고 있다가, 새로 들어온 레코드가 현재 메모리 페이지의 크기를 32KB가 넘어가게 만드는 경우 현재 페이지를 WAL 파일에 Flush 한다. 즉, 일차적으로 데이터를 메모리에 저장하는 것을 원칙으로 하되, 나름 주기적으로 WAL 파일에 백업하는 셈이다. 이렇게 저장되는 데이터 공간 (?) 을 일반적으로 "Head Block" 이라고 부른다.

Head Block의 데이터가 백업되는 WAL 파일은 최대 128MB를 차지할 수 있으며, 128MB가 넘을 경우 새로운 WAL 파일이 생성된다. 이 WAL 파일은 인메모리 데이터의 손실을 방지하기 위한 것인데, 프로메테우스가 비정상적으로 종료되는 crash가 발생할 경우 현재 존재하는 WAL을 다시 읽어들여 원래의 데이터를 복구하는 replay 작업을 수행한다 이 때, WAL 파일을 다시 읽어들이는 기준점은 wal 디렉터리에 존재하는 checkpoint.XXXXX가 된다.2

참고로 네트워크 스토리지를 쓰게 되면 checkpoint나 WAL 파일이 깨지는 corruption이 발생할 수도 있는데, 그러면 굉장히 골치아파진다. 프로메테우스의 재시작이 계속해서 실패할 수도 있고, 새로운 chunk 블록이 생성이 되지 않아서 이상하게 꼬여버릴 수도 있다. 이런 경우에는 어쩔 수 없이 눈물을 머금고 데이터를 삭제해야만 하는 듯 싶으니 (....) NVMe나 로컬 스토리지를 쓰는 것이 안정성 면에서 현명한 선택일 수도 있다.

[ref]

[prometheus storage] https://blog.naver.com/PostView.nhn?blogId=alice_k106&logNo=221829384846
[prometheus storage] https://prometheus.io/docs/prometheus/latest/storage/#operational-aspects

profile
개발 기록

0개의 댓글