如何低成本实现 Prometheus 数据的长期存储？
Prometheus 作为一个在可观测性领域中起着至关重要作用的监控系统，为运维团队提供了一整个对整体网络状态进行监控的平台。Prometheus 提供了数据模型、时序数据库、轮询机制，以及大量的开源工具生态系统，以便开发者们利用这些工具来完成追踪、监控网络状态这一具有挑战性但至关重要的任务。
虽然 Prometheus 的轻量级和模块化架构让其庞大的生态系统得以发展，但同时也导致了一些明显的问题，其中一个最显著的挑战就是数据的长期存储问题。Prometheus 对其收集的指标提供的存储能力有限，无法满足开发和运维的需求。
Prometheus 仅为其收集的指标提供本地存储。直接在 Prometheus 服务器上运行的查询只能访问有限的历史数据。Greptime 可以解决这一问题。
尽管业界已有如 Thanos、Cortex 和 Mimir 等解决方案来提供长期存储，Greptime 以更高效的方式更完美地解决了这一需求，且仅用少量计算资源就能实现，不会牺牲实践者依赖的生态系统兼容性。
为什么需要长期存储？
Prometheus 一直以来聚焦于打磨其主要产品价值，也就是提供一个可靠且可预测的系统来抓取服务器上产生的指标数据。这一选择的结果是，Prometheus 仅提供了其部署服务器的本地存储。对于那些每天传输数百 GB 指标或使用多个 Prometheus 服务器的大规模部署，它们只能保留其中一小部分想要捕获的数据。由于报告和告警通常对比一些长期数据，而这些长期数据的存储超出了单个 Prometheus 服务器提供的短期数据存储方案，通常无法满足许多场景的需求。
Prometheus 有一个简单的方法来支持这些用例。
Prometheus 开放了一个关键的远程写入协议接口，该接口将报告的指标数据推送到远程服务器以进行长期保存。
远程服务器负责存储 Prometheus 的所有长期数据，因此，当下游的消费者需要查询数据来生成报表时，下游存储服务将提供长期数据。由于对处理 Prometheus 指标的压缩、存储和查询等长期存储任务的需求不断增加，近年来在这一竞争激烈的领域中不断涌现出各种工具。
传统的行业解决方案
由于可靠地监控大型网络所需的数据量巨大，利用全球云供应商提供的便宜高效的对象存储来储存长期数据已成为一种行业共识。对象存储并非结构化的，因此需要精心设计的工程技术来在较短时间内将这些数据重新读取出来用于分析和报告。现代软件工程实践对分布式系统和可扩展性的需求影响了随后出现的大量组件和设计的发展。
📍长期存储解决方案必须在成本、性能和可维护性之间取得平衡，同时解决存储大量数据供下游系统查询的艰巨任务。
这句话的意思是：Sidecars、Receivers、Compactors、Gateways、Rulers 这些术语看起来像是一个很长的购物清单，但实际上它们是许多长期存储解决方案中常见的组件，用来应对前面提到的挑战。一些人认为，将不同功能分区化可以让团队根据用例定制整体部署的规模。例如，如果操作要求需要较少的数据写入量但更多的数据读取量，则部署可以减少对写入器的资源投入，而将更多资源投入到查询器中。Cortex、Mimir 和 Thanos 的解决方案基本上都围绕着将类似的解决方案合并在一起，以解决这些可扩展性挑战。
（图 1 ：微服务框架图）
从以上图表以及最新更新的一些长期存储解决方案中可以看出，微服务框架往往过于复杂：每增加一项服务，就需要维护 ACL、端口、DNS、路由表、监控等，导致维护这些高级网络的复杂性呈指数级增长。
从架构图中可以看出，所有这些组件都可以映射到以下关键功能：
压缩和存储数据
查询历史数据
管理工作负载的分配
用户如何在这些微服务框架的复杂性和单体部署的局限性之间取得平衡？ GreptimeDB 给你提供了解决办法：仅通过三个组件就能以简单且可扩展的方式处理所有长期存储的关键功能：
Metasrv: 部署控制器，托管数据库、表和集群信息，以帮助路由请求
Frontend: 类似代理的服务，接受和翻译传入请求，并使用 Metasrv 中存储的信息将正确格式化的请求转发到目标位置
Datanode: 根据存储在对象存储中的数据，执行 Frontend 传入的请求
📍Greptime 的三组件架构在构建一个强大且可扩展的架构同时，保持复杂性在可接受的水平。
这一架构广受好评，Mimir（该领域的一个重要解决方案提供商）已经在实验模式中部署了类似的架构。Victoria Metrics（另一位表现出色的参与者）也有类似的三叉架构。
Greptime 是否为了达到这种简单性而牺牲了性能或成本呢？实际上恰恰相反。
Greptime 专注于效率和兼容性
GreptimeDB 是长期存储领域 CPU 效率最高的领先方案之一，与行业标准相比，Greptime 可将内存利用率降低 80-90%。以下是不同集群种类处理每百万活跃的时间线所需的 CPU 和内存：
长期存储的部署通常需要每天处理数百万个有效时间线，每年花费数万美元甚至更多。以处理一千万个有效时间线的典型情况为例，一个 Thanos 部署可能会使用 100-120GiB 内存来处理该过程。这相当于在 Google Cloud 上使用 8 个 c4-standard-4 实例，在撰写本文时，其每年的成本为 15,000 美元。
通过切换到 GreptimeDB 部署，每年可以节省超过 10,000 美元。随着部署规模的扩大，用户将节省更多计算成本。
📍切换到 Greptime 可以提高资源效率，显著降低 80-90%的 Prometheus 指标数据存储成本。
得益于 GreptimeDB 超强的兼容性，这些成本节省几乎不会对用户其他可观测性 pipeline 和组件造成任何干扰。GreptimeDB 的同构表结构可以很顺畅地映射到一组 Prometheus 指标上，使得用 GreptimeDB 替换用户原有的计算密集型存储变得非常简单。我们已经收到一些用户反馈，他们在 30 分钟内就从 Thanos 切换到了 GreptimeDB。
GreptimeDB 提供了远程写入协议的兼容性，以及用于下游应用程序（如 Grafana 仪表板、PagerDuty 告警等）的 PromQL 和 Prometheus API 数据兼容 API。
此外，GreptimeDB 还可以解析非结构化日志，以在可观测性 pipeline 中创建结构化事件。对指标、日志和事件的高效联合存储有助于 GreptimeDB 力求实现的统一可观测性数据库愿景。所有从 Prometheus 捕获的数据都可以轻松地与其他数据源（例如写入 GreptimeDB 的日志）进行联接和查询，避免了不必要的上下文切换，并省去了管理和配置多个系统（如 Loki 和 Mimir）的麻烦，实现了在 GreptimeDB 中对整个观测数据链路的综合监测。
📍GreptimeDB 的两个主要优势：更快、更高效的运行时，以及兼容性强，更易于集成的解决方案。
Greptime 可以为可观测从业者在 Prometheus 后端的长期存储服务上节省大量计算资源和成本，同时提供了符合行业标准的工具，便于无缝迁移。
如果您有兴趣尝试开源的 GreptimeDB 来提高您可观测数据管道的资源效率，欢迎阅读文档、下载使用！联系我们了解企业版详细功能和报价~
附
关于 Greptime
Greptime 格睿科技专注于为可观测、物联网及车联网等领域提供实时、高效的数据存储和分析服务，帮助客户挖掘数据的深层价值。目前基于云原生的时序数据库 GreptimeDB 已经衍生出多款适合不同用户的解决方案，更多信息或 demo 展示请联系下方小助手（微信号：greptime）。
欢迎对开源感兴趣的朋友们参与贡献和讨论，从带有 good first issue 标签的 issue 开始你的开源之旅吧～期待在开源社群里遇见你！添加小助手微信即可加入“技术交流群”与志同道合的朋友们面对面交流哦~
Star us on GitHub Now: https://github.com/GreptimeTeam/greptimedb
Twitter: https://twitter.com/Greptime
Slack: https://greptime.com/slack
专注于 Infra 技术分享 2022-09-23 加入
分布式、高性能、存储计算分离的开源云原生时序数据库
评论