山间竹笋,嘴尖皮厚,腹中空
墙上芦苇,头重脚轻,根底浅
看完了整个Cortex 的水平扩展以及高可用,也看完了 Cortex 里面的架构分析,那现在就是要来看一下,在生产环境中的 Cortex 的一些相关配置。
选择存储后端
在架构分析里面有提到了,Cortex 的后端可以使用有三个:
- DynamoDB/S3
- BigTable/GCS
- Cassandra (我们这里用的)
部署查询前端
前面有提到,Cortex 作为一个微服务的架构体系,里面的各个组件都是可以独立的。我们在配置种配置如下:
1 | -querier.frontend-address string |
具体的内,我们还是要查看这个官方的配置了: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 | # Configuration for running Cortex in single-process mode. |
需要将我们自己的 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 .
后面的就不说了。。翻译不下去了