利用Prometheus 打造企业分布式监控平台(7)--Thanos和VictoriaMetric

本文主要从数据写入和数据查询作为切入点，对比Thanos和VictoriaMetrics，包括以下几个维度：

• 安装和运维复杂性
• 可靠性和可用性
• 一致性
• 性能表现
• 可扩展性

关于Thanos和VictoriaMetrics的架构，大家可以参考利用Prometheus 打造企业分布式监控平台(3)--远程读写之战。这里就不再重复讲述了。

数据写入

安装和运维复杂性

Thanos需要以下步骤来在Prometheus中设置数据写入的链路：

• 禁用每个Prometheus实例的本地数据压缩：
  必须将--storage.tsdb.min-block-duration和--storage.tsdb.max-block-duration设置为相等的值，才能禁用局部压缩，才能使用Thanos Sidecar上传
  在Prometheus中启用本地数据压缩后，Thanos可能无法将数据块上传到对象存储中。有关更多详细信息，请参阅此问题。如果--storage.tsdb.retention.time远远高于2小时，则禁用数据压缩可能会损害Prometheus查询性能。
• 在每个Prometheus实例旁边安装Sidecars，以便他们将Prometheus数据上传到对象存储。
• 设置Sidecars监控。
• 为每个对象存储桶安装压缩器。

VictoriaMetrics需要在Prometheus配置中设置remote_write部分，因此Prometheus会将所有已抓取的数据复制到VictoriaMetrics远程存储中。

可靠性和可用性

Thanos Sidecar以2小时为单位上传本地Prometheus数据，这意味着如果本地磁盘损坏或意外删除数据，则可能会丢失每个Prometheus实例上近添加的数据多2个小时。

从查询组件到Sidecar的传入查询可能会对数据上载过程产生负面影响，因为这些任务是在单个Sidecar进程中执行的。理论上，可以运行单独的Sidecar来将数据上载到对象存储和查询。

VictoriaMetrics：每个Prometheus实例都会通过remote_write API立即将所有已抓取的数据复制到远程存储（例如VictoriaMetrics），在将数据抓取和写入到远程存储之间可能会有几秒钟的延迟，这意味着Prometheus可能会丢失几秒钟的数据本地磁盘损坏或意外删除数据，因为其余数据已被复制到远程存储。

Prometheus v2.8.0 +从预写日志（WAL）将抓取的数据复制到远程存储中，这意味着它不会因与远程存储的临时连接错误或远程存储的临时不可用而丢失数据。

因此，如果端点出现问题，我们只需要停止在预写日志中的位置并尝试重新发送失败的样本批次，就不会丢失数据或引起内存问题，因为它不会继续读取写入数据-ahead log，直到成功发送数据为止。2.8更新有效地使用了恒定数量的内存，并且缓冲区实际上是不确定的，仅取决于磁盘的大小。