1. 课程导论：为什么需要 etcd 压测沙盘？Loki 写入放大与查询限流的背景与挑战
在云原生可观测性体系中，Loki 作为日志聚合系统，以其“类 Prometheus”的标签索引和低成本存储著称。然而，生产环境中 Loki 的稳定性与性能，高度依赖底层元数据存储——etcd 的健康状态。本课程旨在构建一个 etcd 压测沙盘，专门模拟 Loki 在极端负载下的行为，揭示 写入放大 与 查询限流 两大核心挑战。
1.1 为什么需要 etcd 压测沙盘？
etcd 是 Loki 的“中枢神经系统”，负责存储所有 时序元数据（如日志流标签、索引条目、配置状态）。当 Loki 面临高并发写入或复杂查询时，etcd 的响应延迟和吞吐量直接决定整个日志平台的可用性。传统压测工具（如 benchmark、hey）无法模拟 Loki 特有的元数据访问模式，因此需要专用沙盘。
核心痛点： 生产环境中，Loki 的写入放大效应可导致 etcd 的
PUT 请求量飙升 5-10 倍，而查询限流则可能因 etcd 的 MVCC 版本堆积引发级联故障。
etcd 压测沙盘的价值体现在三个层面：
- 风险前置： 在非生产环境复现 Loki 的极端写入模式，提前暴露 etcd 的容量瓶颈。
- 参数调优： 验证
--max-txn-ops、--quota-backend-bytes等 etcd 关键参数对 Loki 负载的适配性。 - 限流策略验证： 测试 Loki 的
query-frontend限流配置与 etcd 的--max-request-bytes是否协同工作。
1.2 Loki 写入放大：背景与挑战
写入放大 是指 Loki 每接收一条日志行，在 etcd 中产生的元数据写入操作远超预期。其根源在于 Loki 的 流式索引 设计：
| 阶段 | 操作描述 | etcd 写入次数 |
|---|---|---|
| 日志摄入 | Ingester 接收日志行，提取标签（如 job、namespace） |
1 次 PUT（写入 chunks 元数据） |
| 索引构建 | 为每个标签组合创建或更新 倒排索引 条目 | N 次 TXN（N = 标签基数） |
| 流注册 | 新日志流（stream）首次出现时，注册流元数据 | 1 次 PUT + 1 次 TXN |
| 压缩合并 | Compactor 合并小 chunk，更新索引引用 | 2-3 次 TXN（删除旧 + 写入新） |
当标签基数（如 pod 标签有 10,000 个唯一值）较高时，写入放大系数 可达 8-12x。这意味着 1 MB/s 的日志写入速率，可能对 etcd 产生 8-12 MB/s 的元数据写入压力。
挑战： etcd 的
quota-backend-bytes 默认 2 GB，在写入放大场景下，元数据空间可能数小时内耗尽，导致集群进入 只读模式，所有日志写入失败。
1.3 查询限流：背景与挑战
Loki 的查询路径涉及 query-frontend、querier 和 store-gateway 三个组件，最终依赖 etcd 获取索引元数据。当并发查询量超过 etcd 的处理能力时，查询限流 机制被触发，但限流策略本身可能引入新的问题。
| 限流层级 | 触发条件 | 对 etcd 的影响 |
|---|---|---|
| query-frontend | 每秒查询数 (QPS) 超过阈值 | 减少 etcd 的 Range 请求，但可能造成查询排队 |
| querier | 单个查询的标签匹配数过多 | 降低 etcd 的 TXN 负载，但查询延迟增加 |
| store-gateway | 分片查询超时或失败 | etcd 的 Watch 连接数可能飙升 |
| etcd 自身 | --max-request-bytes 或 --max-txn-ops 超限 |
直接拒绝请求，导致 Loki 查询失败 |
关键洞察： 查询限流并非孤立问题。当 etcd 因写入放大导致 MVCC 版本堆积（如版本数超过 100 万），查询响应时间会从毫秒级恶化到秒级，进而触发 Loki 的查询超时重试，形成 限流-重试-加剧 的恶性循环。
1.4 沙盘的核心目标
本课程设计的 etcd 压测沙盘，将围绕以下三个目标展开：
- 复现写入放大： 通过模拟 Loki 的高标签基数写入模式，精确测量 etcd 的
PUT/TXN速率、存储空间增长和 MVCC 版本数变化。 - 触发查询限流： 构造并发查询场景，观察 etcd 的
--max-request-bytes和--max-txn-ops如何与 Loki 的query-frontend限流配置交互。 - 提供调优依据： 输出可量化的压测报告，指导 etcd 的
quota-backend-bytes、auto-compaction-retention以及 Loki 的ingester.max-chunk-age等参数的最佳实践。
沙盘输出示例： 在 1000 个唯一标签、100 QPS 写入负载下，etcd 的
db size 从 200 MB 增长到 1.8 GB（放大 9x），revision 从 10 万增长到 800 万，查询 P99 延迟从 5 ms 恶化到 2.3 s。
通过本课程，你将掌握如何构建这个沙盘，并利用它来诊断和预防生产环境中 Loki 与 etcd 的稳定性风险。