为什么我们选择 Thanos 进行长期指标存储？

指标好坏的常见 3 个问题：

• 您的用户满意吗？
• 你的应用满意吗？
• 你的服务开发者开心吗？

应用程序开发人员根据用于态势感知或识别长期趋势的指标创建仪表板。他们希望衡量他们的增长并将今天的每日活跃用户与一年前的价值进行比较。

Prometheus——首批毕业生 CNCF 项目之一——是收集应用程序和平台指标以及短期存储的首选解决方案。如果您的应用程序已经容器化，那么 Prometheus 和 Kubernetes 是 BFF。对于长期指标存储，Prometheus 集成了 28 个解决方案https://prometheus.io/docs/operating/integrations/#remote-endpoints-and-storage。你应该选择哪一个？

在这篇文章中，我们讲述了我们如何在众多项目中选择用于长期指标存储的故事。这篇博文是 3 次全体会议和 200 多个工时的实践工作的结果，我们的工程师在其中挑选了每个候选项目并将其插入Elastisys Compliant Kubernetes。我们希望我们的故事能为您节省时间，或者至少告诉您类似的评估过程。

标准 1：长期健康

我们的架构决策过程更倾向于关注未来而不是现在。可以添加和删除功能，但更改项目所有权和调整利益要困难得多。许多人还记得 Istio 治理讨论将这种风险提上了议事日程。因此，长期健康比项目今天具有的确切功能更重要。

只有社区驱动的治理才能真正确保项目不依赖于任何一家公司的利益或资产负债表，无论大小。此外，社区驱动的开源有利于业务连续性，让您的 CISO 面带微笑。

最后，我们把自己的东西拿出来，问候选项目明年是否还在。迁移成本不是我们想经常支付的。不幸的是，明星项目还没有被发明出来，在此期间，我们倾向于求助于虚荣的指标：GitHub 贡献者的数量、提交量、星级和分叉；以及其他人在使用什么。

标准 2：必须具备自己的特点

没有以下内容，我们就无法生存。Prometheus remote_read 集成或 PromQL 支持：这允许应用程序开发人员和平台工程师重用并为流行的仪表板做出贡献，例如在Grafana Labs 的网站上发布或与Prometheus Operator一起提供的仪表板。我想我们不是重新发明轮子的忠实拥护者。

在长期存储方面，大小确实很重要。不仅因为......良好的存储成本......而且因为它使异地复制和查询更快。两种互补的技术可以实现这一点。

首先，压缩——一些项目需要，但不是全部——以更紧凑（可能查询速度较慢）的格式存储指标。压缩——正如我们在这里理解和使用的术语——意味着不会丢失信息。

然后，聚合意味着通过降低数据的分辨率来丢失信息。这可以发生在“时间”或“空间”中。随着时间的推移，时间分辨率会降低，例如，以 15 分钟而不是 15 秒的时间分辨率存储值。在空间中，标签被删除，例如，您可以检索应用程序的所有 Pod 的平均 CPU 使用率，但您不再可以访问各个 Pod 的时间序列。

最后，重复数据自动删除：常识认为，您的监控堆栈需要比您的监控系统更具弹性一个数量级。如您所料，这意味着运行多个 Prometheuse，以便可以在工作时间处理凌晨 2 点失败的节点。但是有些地方需要对冗余收集的指标进行重复数据删除，除非您的产品经理要求您对每个用户进行两次计数。重复数据删除确保指标仅显示一次，尽管它们被收集和存储两次。

标准 3：易于操作

功能很重要，但第 2 天会发生什么？

作为我们评估的一部分，我们还想“感受”新项目将如何支持我们的数据安全实践。应用安全补丁会感觉像“待办事项”吗？设置高可用性怎么样？

灾难恢复呢？我们甚至需要执行灾难恢复，还是项目可以将所有关键数据存储在仅附加的 S3 兼容对象存储中？换句话说，“灾难恢复”——请注意，丢失提供者的对象存储将是非常灾难性的——就像从异地副本中进行rclone一样简单。最后，该项目的产能需求如何？该平台的目的是为应用程序服务，但它最好不需要比应用程序本身需要更多的 CPU 和内存……

顶级竞争者的比较

在对所有 28 个 Prometheus 集成进行粗略筛选后，我们继续对 6 个候选者进行了更彻底的分析。

在前六名（InfluxDB、TimescaleDB、M3DB、Victoria Metrics、Thanos 和 Cortex）中，让我们看看它们各自的比较。

荣誉奖：InfluxDB

InfluxDB 是由 InfluxData 拥有和开发的专用时间序列数据库。它有两个版本，开源（MIT 许可）和企业版。其中，企业版带来了高可用性和水平可扩展性（集群）。InfluxDB 将数据存储在磁盘上，即 Kubernetes 术语中的 PersistentVolumes。InfluxDB 1 已弃用，建议用户尽快切换到 InfluxDB 2。

总的来说，InfluxDB 是一个了不起的项目，版本1 多年来一直为我们服务。感谢 InfluxDB 让我们走到这一步！

取消选择，因为一些原因，我们不得不告别 InfluxDB。首先，它不是社区驱动的。其次，开源版本缺乏必须具备的条件，例如高可用性和重复数据删除。第三，在我们的环境中，事实证明它相当消耗资源。在某些情况下，我们不得不将保留时间减少到 3 天，以保持在 16 GB RAM 预算内。

我们考虑了 InfluxDB2。但是，没有立即计划添加对 remote_read 的支持，所以我们不得不放弃。

铜牌：TimescaleDB

TimescaleDB 是 Timescale 拥有和构建的时间序列数据库。它被实现为 PostgreSQL 的扩展。使用 TimescaleDB 进行指标存储意味着您可以利用现有的内部关于操作 PostgreSQL 的知识，并重用您的访问控制、高可用性和灾难恢复过程。

TimescaleDB 有两个版本：开源 (Apache 2.0) 和 Timescale License (TSL)。后者类似于 2021 年 MongoDB 和 Elasticsearch 采用的备受争议的 Server-Side Public License (SSPL)。TSL 版本增加了压缩和聚合。

取消选择的原因：不幸的是，该项目不是社区驱动的。它的开源版本缺乏压缩。你肯定需要压缩！TimescaleDB 最初将每个值连同其时间戳和标签一起存储为一个数据库行，这非常耗费空间。压缩将相关值合并到一行中，以获得更类似于超高效 TSDB 文件格式的东西，存储在 PostgreSQL 数据库中。

关于 TimescaleDB 我在这里有自己的观点：关系数据库真的是度量标准的正确巢穴吗？指标几乎是仅附加的，因此 PostgreSQL 为确保事务性所做的所有努力都被浪费了。我们的 DBA 有点被 WAL 的数量吓坏了生成并发送到辅助节点，所以你应该完全看清楚它的真实情况在做选择。

银牌：M3DB 和 VictoriaMetrics

M3DB 和 VictoriaMetrics 是分别由 Uber+Chronosphere 和 VictoriaMetrics 支持的两个时间序列数据库。它们都是开源的 Apache 2.0 许可的。他们都有自己的 Kubernetes operator 来简化操作。在功能方面，他们勾选了所有选项。它们都将指标存储在磁盘上，具有高可用性，并且似乎能够处理大量指标。

总的来说，我们对它们与 Grafana 和 Prometheus 的集成程度、设置高可用性的容易程度以及它们处理大量指标的能力感到惊喜。

取消选择的原因：我们取消选择它们主要是因为它们不是社区驱动的。这是选择而不是评分，所以我们确实需要找到取消选择的原因。但除此之外，向他们背后的团队致敬！

金牌：Thanos and Cortex

Thanos 和 Cortex 都是 CNCF 孵化项目，因此社区驱动的开源检查。它们勾选了我们所有必须具备的功能，易于使用并且可以处理大量指标。Prometheus 和 Grafana 喜欢它们，我们的平台工程师也喜欢它们。

纵观全局，它们的设计相似。对于写入路径，指标首先以 TSDB 格式存储在磁盘上，然后定期将 TSDB 段上传到 S3 兼容的对象存储。读取路径看起来相当对称，磁盘充当一种缓存。对于像指标这样的仅附加数据很有意义！

灾难恢复？不用担心！所有重要数据都在对象存储中。随意将其重新克隆到另一个位置，Thanos 或 Cortex 的另一个实例将愉快地阅读它。我们已经将 S3 兼容的对象存储用于长期日志和备份，因此重用是非常简单的，基础设施服务可进一步简化操作并促进跨云的可移植性。

总而言之，这两个项目都很棒而且非常相似。它们似乎是共同进化的。我敢打赌，如果一个新功能登陆 Thanos，Cortex 也会很快加入，反之亦然。

好的，那么现在呢？虽然我们确实想要一个有弹性的监控堆栈，但我们并不像同时运行 Thanos 和 Cortex 那样狂热。最后，只能有一个，那就是 Thanos。

总结

虽然我们希望这种选择在许多情况下都有用，但绝不是绝对的。每个技术都是为特定的场景服务的，所以要尽职调查清楚，在做选择。