0%

Prometheus扩展在Cortex在生产环境中的使用

山间竹笋,嘴尖皮厚,腹中空
墙上芦苇,头重脚轻,根底浅

看完了整个Cortex 的水平扩展以及高可用,也看完了 Cortex 里面的架构分析,那现在就是要来看一下,在生产环境中的 Cortex 的一些相关配置。

选择存储后端

在架构分析里面有提到了,Cortex 的后端可以使用有三个:

  • DynamoDB/S3
  • BigTable/GCS
  • Cassandra (我们这里用的)

部署查询前端

前面有提到,Cortex 作为一个微服务的架构体系,里面的各个组件都是可以独立的。我们在配置种配置如下:

1
2
-querier.frontend-address string
Address of query frontend service.

具体的内,我们还是要查看这个官方的配置了:query-frontend

设置我们的缓存

这个缓存包括:

  • 查询缓存(整个的查询缓存)

针对 块 存储

  • 单个的 chunks
  • 每天对一个 label 的索引查找
  • 减少快存储的写入重复

Cassandra

设置本地的 Cassandra

1
docker run -d --name cassandra --rm -p 9042:9042 cassandra:3.11.6

执行我们的 Cassandra 的查询Cassandra Query Language (CQL)

1
docker exec -it <container_id> cqlsh

为 Cortex 创建新的 Cassandra 空间:

1
CREATE KEYSPACE cortex WITH replication = {'class':'SimpleStrategy', 'replication_factor' : 1};

配置Cortex在Cassandra上存储块和索引

这里,我直接拿案例过来看:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
# Configuration for running Cortex in single-process mode.
# This should not be used in production. It is only for getting started
# and development.

# Disable the requirement that every request to Cortex has a
# X-Scope-OrgID header. `fake` will be substituted in instead.
auth_enabled: false

server:
http_listen_port: 9009

# Configure the server to allow messages up to 100MB.
grpc_server_max_recv_msg_size: 104857600
grpc_server_max_send_msg_size: 104857600
grpc_server_max_concurrent_streams: 1000

distributor:
shard_by_all_labels: true
pool:
health_check_ingesters: true

ingester_client:
grpc_client_config:
# Configure the client to allow messages up to 100MB.
max_recv_msg_size: 104857600
max_send_msg_size: 104857600
use_gzip_compression: true

ingester:
lifecycler:
# The address to advertise for this ingester. Will be autodiscovered by
# looking up address on eth0 or en0; can be specified if this fails.
address: 127.0.0.1

# We want to start immediately and flush on shutdown.
join_after: 0
final_sleep: 0s
num_tokens: 512

# Use an in memory ring store, so we don't need to launch a Consul.
ring:
kvstore:
store: inmemory
replication_factor: 1
# Use cassandra as storage -for both index store and chunks store.
schema:
configs:
- from: 2019-07-29
store: cassandra
object_store: cassandra
schema: v10
index:
prefix: index_
period: 168h
chunks:
prefix: chunk_
period: 168h

storage:
cassandra:
addresses: LOCALHOST # configure cassandra addresses here.
keyspace: KEYSPACE # configure desired keyspace here.

需要将我们自己的 Cassandra 的地址以及 Keyspace 给到我们的实例

测试我们就不测试了。

WAL 的配置

目前,在块存储模式下运行的 inesters,将其所有数据存储在内存中。如果发生崩溃,则可能会丢失数据。WAL 有助于填补可靠性方面的空白。

这里面的概念有点慌,我还没捋清楚。目前所能确定的是,在我们进行 restart / rollout 操作的时候,intehers 需要有相同的 持久卷 , 同时 all the ingesters should be run on statefulset with fixed volumes. . 我着实是不知道怎么去翻译。

我们部署 WAL 的时候,需要做以下几点的修改:

  • --ingester.wal-dir: WAL 的目录地址;
  • --ingester.wal-enabled: 是否启用 WAL
  • --ingester.checkpoint-enabled: 启用我们的检查点,可以加快 replay process.
  • --ingester.checkpoint-duration: 检查点的创建时间间隔
  • --ingester.recover-from-wal: 从已经存在的 WAL 里面恢复数据

生命周期会发生改变

当我们启用 WAL 的时候,这个生命周期是会被修改的

在 rollouts 或者 scale sown 的时候,禁止将数据刷新到 chunks . 这是因为在推出statefulset的过程中,没有同时退出和加入的ingester,而是关闭了同一个ingester,并使用更新的配置再次将其 brought back。这句话的意思就是在一个状态集推出的时候 ,intagers 没有进也没有出,而是关闭了,他在等一个经过更新的配置唤醒。

在 integers 之间是没有转移的,所以在 rollout / restart 的时候,这个令牌将会被重新加载。

向上扩展

这个和 没有 WAL 以及状态集 的时候都一样。

缩小规模

这里比较麻烦,官方的说明太难了。不写了。还是写一下吧。

现在有 4 个 integers, 分别为: integer-1 , integer-2 , integer-3 ,integer-4 . 现在要缩小规模,根据规则,减少的是 integer-2 、 integer-3 .

后面的就不说了。。翻译不下去了

这是打赏的地方...

本文标题:Prometheus扩展在Cortex在生产环境中的使用

文章作者:Mr.Sun

发布时间:2020年04月09日 - 17:39:13

最后更新:2020年06月15日 - 10:05:35

原始链接:http://www.blog.sun-iot.xyz/posts/c97f9e79

许可协议: 署名-非商业性使用-禁止演绎 4.0 国际 转载请保留原文链接及作者。

---------Thanks for your attention---------