|
|
|
|
@ -11,13 +11,13 @@ Prometheus's local time series database stores data in a custom, highly efficien |
|
|
|
|
|
|
|
|
|
### On-disk layout |
|
|
|
|
|
|
|
|
|
Ingested samples are grouped into blocks of two hours. Each two-hour block consists |
|
|
|
|
of a directory containing a chunks subdirectory containing all the time series samples |
|
|
|
|
for that window of time, a metadata file, and an index file (which indexes metric names |
|
|
|
|
and labels to time series in the chunks directory). The samples in the chunks directory |
|
|
|
|
are grouped together into one or more segment files of up to 512MB each by default. When |
|
|
|
|
series are deleted via the API, deletion records are stored in separate tombstone files |
|
|
|
|
(instead of deleting the data immediately from the chunk segments). |
|
|
|
|
Ingested samples are grouped into two-hour blocks. Each block consists of a directory that |
|
|
|
|
contains a chunks subdirectory with all the time series samples for that time window, |
|
|
|
|
a metadata file, and an index file (which maps metric names and labels to the time series |
|
|
|
|
in the chunks directory). The samples in the chunks directory are organized into one |
|
|
|
|
or more segment files, each up to 512 MB by default. When series are deleted via the API, |
|
|
|
|
the deletion records are stored in separate tombstone files rather than being immediately |
|
|
|
|
removed from the chunk segments. |
|
|
|
|
|
|
|
|
|
The current block for incoming samples is kept in memory and is not fully |
|
|
|
|
persisted. It is secured against crashes by a write-ahead log (WAL) that can be |
|
|
|
|
|