You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/architecture.md
+9-13Lines changed: 9 additions & 13 deletions
Original file line number
Diff line number
Diff line change
@@ -28,7 +28,7 @@ The two engines mostly share the same Cortex architecture with few differences o
28
28
29
29
### Chunks storage (default)
30
30
31
-
The chunks storage stores each single time series into a separate object called _Chunk_. Each Chunk contains the timestamp-value pairs for a given period (defaults to 12 hours) of the series. Chunks are then indexed by time range and labels, in order to provide a fast lookup across many (over millions) Chunks.
31
+
The chunks storage stores each single time series into a separate object called _Chunk_. Each Chunk contains the samples for a given period (defaults to 12 hours). Chunks are then indexed by time range and labels, in order to provide a fast lookup across many (over millions) Chunks.
32
32
33
33
For this reason, the chunks storage consists of:
34
34
@@ -53,7 +53,7 @@ The current schema recommendation is the **v10 schema** (v11 is still experiment
53
53
54
54
The blocks storage is based on [Prometheus TSDB](https://prometheus.io/docs/prometheus/latest/storage/): it stores each tenant's time series into their own TSDB which write out their series to a on-disk Block (defaults to 2h block range periods). Each Block is composed by few files storing the chunks and the block index.
55
55
56
-
The TSDB chunk files contain the timestamp-value pairs for multiple series. The series inside the Chunks are then indexed by a per-block index, which indexes metric names and labels to time series in the chunk files.
56
+
The TSDB chunk files contain the samples for multiple series. The series inside the Chunks are then indexed by a per-block index, which indexes metric names and labels to time series in the chunk files.
57
57
58
58
The blocks storage doesn't require a dedicated storage backend for the index. The only requirement is an object store for the Block files, which can be:
59
59
@@ -64,7 +64,7 @@ For more information, please check out the [Blocks storage](operations/blocks-st
64
64
65
65
## Services
66
66
67
-
Cortex has a service-based architecture, in which the overall system is split up into a variety of components that perform a specific task, run separately, and in parallel.
67
+
Cortex has a service-based architecture, in which the overall system is split up into a variety of components that perform a specific task, run separately, and in parallel. Cortex can alternatively run in a single process mode, where all components are executed within a single process. The single process mode is particularly handy for local testing and development.
68
68
69
69
Cortex is, for the most part, a shared-nothing system. Each layer of the system can run multiple instances of each component and they don't coordinate or communicate with each other within that layer.
70
70
@@ -79,11 +79,11 @@ The Cortex services are:
79
79
80
80
### Distributor
81
81
82
-
The **distributor** service is responsible for handling incoming series from Prometheus. It's the first stop in the write path for series samples. Once the distributor receives samples from Prometheus, each series is validated for correctness and to ensure that it is within the configured tenant limits, falling back to default ones in case limits have not been overridden for the specific tenant. Valid samples and then split into batches and sent to multiple [ingesters](#ingester) in parallel.
82
+
The **distributor** service is responsible for handling incoming samples from Prometheus. It's the first stop in the write path for series samples. Once the distributor receives samples from Prometheus, each sample is validated for correctness and to ensure that it is within the configured tenant limits, falling back to default ones in case limits have not been overridden for the specific tenant. Valid samples are then split into batches and sent to multiple [ingesters](#ingester) in parallel.
83
83
84
84
The validation done by the distributor includes:
85
85
86
-
- The metric name is formally correct
86
+
- The metric labels name are formally correct
87
87
- The configured max number of labels per metric is respected
88
88
- The configured max length of a label name and value is respected
89
89
- The timestamp is not older/newer than the configured min/max time range
@@ -107,18 +107,14 @@ For more information, please refer to [config for sending HA pairs data to Corte
107
107
108
108
#### Hashing
109
109
110
-
Distributors use consistent hashing, in conjunction with a configurable replication factor, to determine which ingester instances should receive a given series.
110
+
Distributors use consistent hashing, in conjunction with a configurable replication factor, to determine which ingester instance(s) should receive a given series.
111
111
112
112
Cortex supports two hashing strategies:
113
113
114
114
1. Hash the metric name and tenant ID (default)
115
-
2. Hash the metric name, labels and tenant ID (recommended, enabled with `-distributor.shard-by-all-labels=true`)
115
+
2. Hash the metric name, labels and tenant ID (enabled with `-distributor.shard-by-all-labels=true`)
116
116
117
-
The trade-off associated with the latter is that writes are more balanced across ingesters but each query needs to talk to any ingester since a metric could be spread across any ingester given different label sets. The first hashing strategy (default) was originally chosen to reduce the number of required ingesters on the query path, but running Cortex in production showed that an evenly distributed write load on the ingesters is preferable at the cost of always querying all ingesters.
118
-
119
-
The trade-off associated with the latter is that writes are more balanced across ingesters, but requires each query to look across all ingesters, since a metric could be spread across any ingester given different label sets.
120
-
121
-
The first hashing strategy (default) was originally chosen to reduce the number of required ingesters on the query path, but running Cortex in production showed that an evenly distributed write load on the ingesters is preferable at the cost of always querying most of the ingesters.
117
+
The trade-off associated with the latter is that writes are more balanced across ingesters but each query needs to talk to any ingester since a metric could be spread across multiple ingesters given different label sets.
122
118
123
119
#### The hash ring
124
120
@@ -197,7 +193,7 @@ Queriers are **stateless** and can be scaled up and down as needed.
197
193
198
194
### Query frontend
199
195
200
-
The **query frontend** is an **optional service** providing the same querier's API endpoints and can be used to accelerate the read path. When the query frontend is in place, incoming query requests should be directed to the query frontend instead of the queriers. The querier service will be still required within the cluster, in order to execute the actual queries.
196
+
The **query frontend** is an **optional service** providing the querier's API endpoints and can be used to accelerate the read path. When the query frontend is in place, incoming query requests should be directed to the query frontend instead of the queriers. The querier service will be still required within the cluster, in order to execute the actual queries.
201
197
202
198
The query frontend internally performs some query adjustments and holds queries in an internal queue. In this setup, queriers act as workers which pull jobs from the queue, execute them, and return them to the query-frontend for aggregation. Queriers need to be configured with the query frontend address - via the `-querier.frontend-address` CLI flag - in order to allow them to connect to the query frontends.
0 commit comments