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

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

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

选择存储后端

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

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

部署查询前端

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

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

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

设置我们的缓存

这个缓存包括:

• 查询缓存（整个的查询缓存）

针对 块 存储

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

Cassandra

设置本地的 Cassandra

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

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

docker exec -it <container_id> cqlsh

为 Cortex 创建新的 Cassandra 空间:

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

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

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

# 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 .

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