mirrors/prometheus
1
0
Fork 0
mirror of https://github.com/prometheus/prometheus.git synced 2025-12-01 23:51:01 +01:00
Code Issues Projects Releases Wiki Activity

I’ve proposed a slight rewording of this section to improve clarity and readability. (On-Disk Layout Paragraph)

Browse Source 
Signed-off-by: Raul Leite <sp4wn.root@gmail.com>
This commit is contained in:
Raul Leite 2025-11-14 15:31:21 -06:00
parent 1240402620
commit e022a727a8
1 changed files with 7 additions and 7 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

14
docs/storage.md
View File

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