Thanos Sidecar与Receiver：在实时性与存储可靠性之间如何选择？
对于追求高可用、可扩展的Prometheus长期存储方案，Thanos无疑是首选之一。但在实际部署中，Thanos的两种主要数据摄取模式——Sidecar和Receiver，常常让架构师们面临选择困境。它们在数据写入路径、查询新鲜度以及整体系统可靠性上各有侧重，理解这些差异是构建健壮监控系统的关键。
Thanos Sidecar 模式：贴身管家
工作原理： Sidecar模式是最早、也是最常见的Thanos部署方式。它与每个Prometheus实例一同部署，作为其“边车”。Sidecar的主要职责是读取Prometheus本地存储（TSDB）产生的历史数据块（block），并将其上传到对象存储（如S3、COS等）。同时，它也提供一个Store API，允许Thanos Query组件查询Prometheus的实时数据和上传到对象存储的历史数据。
数据写入路径：
- Prometheus正常抓取数据并写入本地TSDB。
- Prometheus每两小时（默认）完成一个数据块后，Sidecar会发现这个新的数据块。
- Sidecar将这个完整的数据块上传到对象存储。
查询新鲜度：
- 对于Prometheus本地还没生成数据块的“实时”数据（通常是最近2小时内的数据），Thanos Query会直接通过Sidecar查询对应的Prometheus实例。
- 对于已上传到对象存储的历史数据，Thanos Query则通过Sidecar访问对象存储中的数据块。
- 优点： 理论上能提供最高的查询新鲜度，因为直接查询Prometheus，延迟最低。
优点：
- 部署简单： 与现有Prometheus集成度高，改动小。
- 解耦存储： 将Prometheus短期存储与Thanos长期存储解耦。
- 查询新鲜度高： 实时数据直接从Prometheus获取。
缺点：
- Prometheus强依赖： Sidecar的生命周期与Prometheus绑定，Prometheus重启会影响Sidecar的功能。
- 数据丢失风险： 在数据块上传完成之前，如果Prometheus实例所在的节点发生故障，未上传的数据块可能丢失。
- 对象存储IO： 每个Sidecar都会直接与对象存储交互，连接数可能较多。
Thanos Receiver 模式：独立接收器
工作原理： Receiver模式利用Prometheus的远程写入（Remote Write）协议。Prometheus不再将数据写入本地磁盘（或只写入短时间），而是通过HTTP/gRPC将抓取到的指标实时发送给Receiver。Receiver接收数据后，将其写入自己的TSDB并最终上传到对象存储。通常，Receiver会部署为集群模式以保证高可用和扩展性。
数据写入路径：
- Prometheus抓取数据后，实时通过Remote Write协议将数据发送给一个或多个Thanos Receiver实例。
- Receiver接收到数据后，写入自己的TSDB（通常在本地磁盘）。
- Receiver定期将数据块上传到对象存储。
查询新鲜度：
- Thanos Query可以直接查询Receiver实例，获取刚写入的最新数据。
- Receiver通常会暴露一个Store API，允许Thanos Query直接获取其内部存储的实时数据，或者已上传到对象存储的数据。
- 优点： 能够实现更实时的全局视图，因为所有Prometheus的数据都汇聚到Receiver，然后可以立即被Query查询。
优点：
- Prometheus解耦： Prometheus不再需要大量本地存储，甚至可以配置为无持久化模式，提升弹性。
- 高可用写入： Receiver可以部署为高可用集群，即使单个Receiver实例故障也不会中断数据接收。
- 实时全局视图： 更好地支持全球范围内的实时数据查询。
- 集中式存储： 所有数据通过Receiver汇聚，管理更集中。
缺点：
- 部署复杂： 需要额外部署和管理Receiver集群，增加了运维成本。
- 网络压力： Prometheus与Receiver之间的远程写入会产生额外的网络流量。
- 写入瓶颈： Receiver集群自身可能成为写入瓶颈，需要精心规划和扩展。
实时性与存储可靠性的权衡点
对于追求实时性和长期存储可靠性的场景，两种模式的权衡点如下：
数据写入可靠性：
- Sidecar： Prometheus本地存储是第一道防线。数据只有在生成完整数据块并被Sidecar上传后才算安全。如果Prometheus实例在数据块上传前崩溃，可能导致最近2小时内的数据丢失。
- Receiver： Prometheus通过Remote Write将数据“推”给Receiver。只要Receiver集群是高可用的，并且Prometheus配置了重试机制，即使单个Prometheus或Receiver短暂故障，数据丢失风险也大大降低。Receiver将数据写入后，通常会立即提供给Query，进一步增强了新鲜度。
查询新鲜度：
- Sidecar： 对Prometheus实例的本地数据具有极高的新鲜度。但如果是聚合多个Prometheus的全局查询，Query组件需要分别向每个Sidecar查询最新数据，聚合过程可能引入微小延迟。
- Receiver： 所有数据都汇聚到Receiver，Thanos Query可以直接从Receiver集群查询最新的“全局”数据。这在构建跨地域、跨集群的统一实时监控视图时，具有明显优势。
操作与运维复杂度：
- Sidecar： 相对简单，主要维护Prometheus和Sidecar。适合现有Prometheus集群的渐进式改造。
- Receiver： 增加了Receiver集群的部署、扩容、高可用、数据一致性等运维挑战。更适合大规模、云原生环境下的全新部署。
如何选择最适合的部署架构？
选择Sidecar或Receiver模式，应基于您的具体业务需求、团队运维能力和规模：
以现有Prometheus部署为主，且对数据丢失容忍度较高，追求部署简单性：
- 首选Sidecar模式。 特别是当你的Prometheus实例数量适中，且每个Prometheus的本地数据新鲜度对业务更重要时。它能以最低的成本实现长期存储。
大规模、动态变化的云原生环境，对数据写入可靠性和全局实时查询新鲜度有强要求：
- 首选Receiver模式。 尤其适用于Prometheus实例数量庞大、需要频繁扩缩容，或需要快速淘汰旧Prometheus实例的场景。Receiver的写入高可用性可以大大降低数据丢失的风险，并提供更一致的全局实时视图。
对Prometheus实例的稳定性要求极高，希望其能无状态化：
- Receiver模式是最佳选择。 Prometheus可以配置为不保存或只短期保存本地数据，将其主要职责定位为数据采集器，将数据转发给Receiver，从而极大提高其弹性。
混合模式：
- 在某些场景下，也可以考虑混合模式。例如，对于核心、关键的Prometheus实例，使用Receiver模式以确保数据写入的高可靠性和实时性；而对于非关键、实验性的Prometheus实例，则继续使用Sidecar模式以简化部署。
总结：
Sidecar模式以其简洁性成为现有Prometheus集成Thanos的优秀起点，它在单个Prometheus层面上提供了良好的查询新鲜度。Receiver模式则提供了更强大的数据摄取可靠性、更优秀的全局实时查询能力，并解耦了Prometheus，但代价是更高的部署和运维复杂性。在做决策时，请务必权衡您的团队能力、业务对实时性的需求、数据丢失的容忍度以及未来的扩展规划。没有绝对的最佳选择，只有最适合您当前和未来场景的架构。
参考资源：