Grafana Tempo 感知可用区的 live-store 复制（Zone-aware live-stores）配置指南

Grafana Tempo 感知可用区的 live-store 复制Zone-aware live-stores配置指南【免费下载链接】tempoGrafana Tempo is a high volume, minimal dependency distributed tracing backend.项目地址: https://gitcode.com/GitHub_Trending/tempo1/tempoZone awareness区域感知/故障域感知是 Tempo 用于保证数据在多个故障域下称区域 zone之间冗余复制、从而提升整体可用性的关键能力。本指南聚焦于 live-store实时存储场景下的 zone-aware 复制配置它将 Tempo 的分区partition所有权按每个区域一个 live-store进行分配使任一区域中的 live-store 不可用时其他区域的 live-store 仍能继续为该分区提供查询服务。读完本文你将理解 zone-aware live-stores 的工作原理RF2 复制、读仲裁为 1 的机制、如何在 Tempo 中为 live-store 与查询端配置感知可用区的路由以及与此相关的 ring、partition ring 配置参数的含义与作用。一、Zone awareness 是什么Zone awareness 是一项确保数据跨故障域复制、从而提供更高可靠性的功能。这里的故障域failure domain完全由你自行定义常见的有云厂商的可用区availability zone如 AWS 的us-east-1a数据中心data center服务器机架server rack。对 Grafana Tempo 而言配置 zone awareness 后系统会把 ring 中的每个实例标记到它所属的区域并将数据副本放置到不同区域从而避免整个区域故障时所有副本同时不可用的最坏情况。Tempo 是一个高吞吐、最小依赖的分布式链路追踪后端参见 README.mdzone awareness 与它的 ring 机制深度绑定每个参与服务的实例会通过 key-value 存储默认 memberlist向 ring 注册自己的身份、地址与区域归属。二、Zone-aware live-stores 的核心设计每个分区由每个区域一个 live-store持有当为 live-stores 开启 zone awareness 后Tempo 的每个分区partition将由每个区域中的一个 live-store 持有owned。也就是说若你部署了 3 个区域那么每个分区会有 3 个 live-store 同时持有它——分别位于 3 个不同的区域。这样做的好处是当某个区域中的 live-store 不可用时其他区域中持有同一分区的 live-store 可以继续为该分区提供查询服务查询不会中断。RF2 复制与读仲裁为 1在这种设计下数据跨区域复制副本数为 2RF2每个分区在两个不同区域中保有数据副本读仲裁read quorum为 1查询端querier只需获得每个分区的一个live-store 的响应即可返回结果。也就是说虽然数据写入了两份但查询只需要一份响应即可成功。这带来了一个重要收益读路径无需进行数据去重data deduplication因为查询只依赖单一副本的结果不会对来自多个副本的响应做合并比对。这一点同时降低了查询延迟等待最少响应即可返回与实现复杂度。设计要点小结设计维度行为分区所有权每个分区在每个区域中恰有一个 live-store 持有复制因子跨区域 RF2数据写入两个区域读仲裁每分区仅需 1 个 live-store 响应quorum 1读路径去重不需要查询只取单副本结果故障场景单一区域 live-store 不可用时其余区域副本继续服务查询三、live-store 在 Tempo 中的角色与 ring 机制live-store 模块概览live-store 是 Tempo 的 livestore 模块提供的能力负责从 Kafka 消费 trace 数据、在内存中维护实时数据分片live traces、并按块block完成与刷新到后端存储。与其相关的重要源文件包括live_store.go核心服务同时管理分区 ringpartition ring与读 ringread ringpartition_ring.go分区 ring 的配置与生命周期器lifecycler参数partition_reader.go按分区消费 Kafka、计算滞后lag并提交 offset 的读取器config.golive-store 全部配置项及其默认值。两个 ring分区 ring 与读 ring从源码 live_store.go 可以看到LiveStore 启动时会同时搭建两套 ring分区 ringpartition ring基于ring.NewPartitionInstanceLifecycler构建用于管理谁持有哪个分区的所有权关系。每个分区可以有多位 owner不同区域的 live-store 各占其一这正是 zone-aware 复制的基础读 ringread ring / membership ring基于ring.NewBasicLifecycler构建用于服务发现——live-store 实例注册到 ring 中让查询端可以发现并连接。从 live_store.go 的实现可以看到该 ring 的实例注册为ring.ACTIVE状态且不需要 token注释明确说明我们只需要在 ring 里以做服务发现。关键配置项instance_zone源码定义于 pkg/ring/config.go正是用于在 ring 中标记实例所属区域BasicLifecyclerConfig中的Zone字段取自cfg.InstanceZone参见 pkg/ring/config.go。每个 live-store 实例只要配置了不同的instance_zone就会被 ring 归属到不同区域从而实现每分区每区域一个 owner的布局。此外分区读取器还通过tempo_live_store_partition_owned指标带有partition与zone两个标签暴露当前实例对分区的持有状态方便运维直接观察每个分区在每个区域的所有权情况见 partition_reader.go。四、如何配置 zone-aware live-stores配置区域归属instance_zone要让 zone awareness 生效第一步是给每个 live-store 实例设置区域标识。Tempo 的统一配置结构模块livestore的ring段中对应字段为livestore: ring: # 必填定义当前实例所属的故障域。 # 可以是可用区、数据中心或机架名例如 us-east-1a、dc1、rack-a。 instance_zone: us-east-1a该配置的源码定义位于 pkg/ring/config.goRegisterFlagsAndApplyDefaults中通过 flag-prefix.instance-availability-zone注册例如-livestore.ring.instance-availability-zone默认值为空字符串即默认不感知区域。它最终会被写入BasicLifecyclerConfig.Zonepkg/ring/config.go随心跳上报到 ring供查询端按区域选择实例。务必确保同一分区副本所在的多个 live-store 实例必须配置互不相同的instance_zone否则它们会落入同一故障域区复制RF2的容灾效果将大打折扣。分区 ring 的 KV 存储分区 ring 的状态共享依赖于 KV 存储。从 partition_ring.go 可以看到其默认 store 为memberlist默认前缀collectors/一般无需改动livestore: partition_ring: kvstore: store: memberlist完整的最小配置示例结合 config.go 中RegisterFlagsAndApplyDefaults的默认值如HeartbeatPeriod 5s、HeartbeatTimeout 1m一个开启 zone-aware 的最小配置如下livestore: ring: heartbeat_period: 5s # 默认 5sring 心跳周期 heartbeat_timeout: 1m # 默认 1m心跳超时判定实例不健康 instance_zone: us-east-1a # 关键本实例所属区域各副本实例必须互不相同 partition_ring: kvstore: store: memberlist # 默认 memberlist无需手动指定也可 min_partition_owners_count: 1 # PENDING 分区转为 ACTIVE 所需的最少 owner 数 min_partition_owners_duration: 10s # 满足最小 owner 数后需持续的时间 delete_inactive_partition_after: 13h # INACTIVE 分区被删除前的等待时长其中min_partition_owners_count、min_partition_owners_duration、delete_inactive_partition_after三个参数在 partition_ring.go 中均有注释说明其映射关系MinOwnersCount→PartitionInstanceLifecyclerConfig.WaitOwnersCountOnPendingMinOwnersDuration→WaitOwnersDurationOnPendingDeleteInactivePartitionAfter→DeleteInactivePartitionAfterDuration。对于 zone-aware 场景建议min_partition_owners_count至少设为你的区域数量例如 2 或 3确保分区只有在每个区域都有 owner 之后才转为 ACTIVE 对外服务。五、查询端如何感知区域PreferredZone 与 zone sorter仅让 live-store 感知区域还不够查询端querier也需要按区域组织请求尽量在本地/优先区域内完成查询。这一逻辑实现在 querier/partition_ring.goqueryQuorumConfigForReplicationSets构造ring.DoUntilQuorumConfig并通过queryPartitionRingZoneSorter(q.cfg.PartitionRing.PreferredZone)注入一个区域排序器querier/partition_ring.go排序器逻辑querier/partition_ring.go为若preferredZone非空则把该区域排到最前优先尝试其余区域打乱顺序以均衡负载。这样在最小化请求 按区域优先的配合下querier 会优先访问同区域副本区域不可用时再退回到其他区域副本。querier: partition_ring: preferred_zone: us-east-1a # 优先查询该区域内的 live-store 副本 minimize_requests: true # 达到仲裁每分区 1 个响应后即停止多余请求minimize_requests与minimize_requests_hedging_delay直接映射到DoUntilQuorumConfig的对应字段querier/partition_ring.go用于控制达到 quorum1 后是否立即终止其余 in-flight 请求。六、zone-aware 复制的收益与适用场景收益高可用单个区域可用区/数据中心/机架故障不会中断对应分区的查询另一区域的副本继续服务低查询开销读仲裁为 1querier 只需等待一个副本响应不会因为等待多个副本而放大延迟实现简单读路径无需数据去重省去多副本结果合并的复杂性与额外 CPU/内存开销负载均衡zone sorter 在多个区域间随机打散请求顺序避免查询全部打在单一区域副本上。适用场景多可用区部署的云原生环境如 EKS/GKE/ACK 上跨 AZ 部署 Tempo 微服务形态需要保证 trace 查询在基础设施局部故障期间仍可用的生产集群追求读写路径低复杂度、同时具备跨域冗余能力的高吞吐 tracing 后端。注意事项instance_zone必须按故障域真实布局填写并保持一致错误配置会导致所有副本落入同一区域失去容灾意义复制因子与仲裁关系是固定的RF2 quorum 1不要尝试通过修改ReplicationFactor等底层 ring 参数去改变该语义pkg/ring/config.go 中ToRingConfig固定设置ReplicationFactor 1因为真正承担复制的语义由分区所有权与区域分配实现部署新区域或下线区域时注意delete_inactive_partition_after默认 13h对分区状态转换的影响避免分区长期滞留 INACTIVE。七、进一步阅读完整配置参考frontend/docs/config-reference.md其中包含livestore.ring.instance_zone、querier.partition_ring.preferred_zone等字段的 YAML 示例live-store 配置与默认值config.go分区 ring 配置partition_ring.go查询端 zone sorter 实现querier/partition_ring.goring 配置instance_zone、heartbeat_period、heartbeat_timeoutpkg/ring/config.go。【免费下载链接】tempoGrafana Tempo is a high volume, minimal dependency distributed tracing backend.项目地址: https://gitcode.com/GitHub_Trending/tempo1/tempo创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考