Promscale-普罗米修斯的分析平台和长期存储

在这篇文章中，我们介绍了Promscale，这是一个新的开放源码的长期存储Prometheus数据的存储库，专为分析而设计。

Promscale是适用于Prometheus数据的水平可扩展且操作成熟的平台，提供PromQL和SQL的组合功能，使开发人员能够提出任何问题、创建任何仪表板，并实现对其系统的更高可见性。Promscale构建在TimscaleDB之上，TimscaleDB是领先的时间序列关系数据库。

Promscale是Timscale的一个工程团队一年来致力于开发的结果。它结合了来自用户和普罗米修斯社区的反馈，并建立在我们之前的普罗米修斯读写适配器用户3.5年的反馈基础上(有关更多信息，请参阅此相关设计文档)。因此，尽管Promscale是一个年轻的项目，但它已经拥有一个活跃的用户社区，包括艺电(Electronic Arts)、陶氏化学(Dow Chemical)和许多其他组织。这个最新版本标志着Promscale脱离测试版。

(“Promscale”这个名字本身是由我们的用户和普罗米修斯社区通过GitHub投票选出的。尽管我们中的一些人暗地里支持“Promy McPromFace”😂。)。

要立即开始，请访问我们的GitHub资源库，通过Helm Charts、Docker等安装Promscale。而且，如果你喜欢我们正在建设的东西，请给我们一个⭐️on giHub🤗。

如果您的Kubernetes集群安装了Helm，我们建议您使用TOBS在5分钟内安装完整的指标集合和可视化解决方案，包括Prometheus、Grafana、Promscale和PromLens预览版(演示视频)。

注：虽然Mat、Josh和Harkishen被列为这篇文章的作者，但整个Promscale团队的功劳都要归功于整个Promscale团队：Ante KrešIć、Blagoj Atanasovski、David Kohn、Harkishen Singh、Josh Lockerman和Mat Arye。

今天，每个行业都在将其计算转移到云端。这些基于云的现代应用程序的复杂性和规模需要复杂的系统来监控软件应用程序运行状况和管理软件基础设施。与过去所有系统都是使用专有软件构建的情况不同，新一轮的现代基础设施正在使用免费、开放的组件(如Kubernetes和Prometheus)构建。这种转变的两大原因是：灵活性和成本。与专有的SaaS解决方案不同，开放式工具将用户的需求放在首位，使他们能够定制自己的堆栈来满足自己的需求，而且价格低廉。在这个世界上，决定使用哪些工具的不是销售合同，也不是RFP，也不是企业销售团队，而是开发人员。

Prometheus是一款开源系统监控和警报工具包，可用于轻松且经济高效地监控基础设施和应用程序。在过去的几年中，普罗米修斯已经成为现代软件系统的监控解决方案。普罗米修斯成功的关键是其基于拉式的架构与服务发现相结合，能够无缝地监控(微)服务频繁启动和关闭的现代动态系统。

随着组织使用普罗米修斯从越来越多的基础设施中收集数据，挖掘这些数据带来的好处也会增加。分析对于审计、报告、容量规划、预测、根本原因分析等变得至关重要。普罗米修斯的建筑理念是简单性和可扩展性。因此，它本身并不提供持久、高度可用的长期存储或高级分析，而是依赖于其他项目来实现此功能。

存在持久存储普罗米修斯数据的现有方法，但是虽然这些选项对于长期存储很有用，但它们只支持普罗米修斯数据模型和查询模型(仅限于PromQL查询语言)。虽然这些工具非常适用于仪表板、警报和监控中的简单、快速分析，但它们不具备更复杂的分析功能，也不具备使用洞察力生成横切分析所需的其他来源丰富其数据集的能力。

输入Promscale。我们创建Promscale是为了克服一个我们和其他开发人员都非常熟悉的挑战：如何在我们的监控数据中轻松地找到复杂问题的答案？

Promscale构建在TimscaleDB和PostgreSQL之上，同时支持PromQL和SQL，提供每秒1000万米以上的水平可扩展性和PB级存储，支持本机压缩，处理高基数，提供坚如磐石的可靠性等。它还提供其他本机时间序列功能，如数据保留策略、连续聚合视图、下采样、数据缺口填充和插值。Grafana已经通过Prometheus和PostgreSQL/TimscaleDB数据源对其进行了本机支持。

Prometheus使用REMOTE_WRITE API将数据写入Promscale连接器，并将数据存储在TimscaleDB中。Promscale连接器本机理解PromQL查询，并从TimscaleDB获取数据以执行它们，而SQL查询直接转到TimscaleDB。

Promscale是开源的，在Apache2下获得许可。TimscaleDB在完全免费的、源代码可用的Timscale许可下获得许可。

Promscale将数据存储在动态自动生成的架构中，该架构针对普罗米修斯指标进行了高度优化，这是彻底基准测试和社区讨论的结果(如本设计文档中所示)。具体地说，此模式将各个指标解耦，允许收集基数和保留期差异很大的指标。同时，Promscale公开了简单的、用户友好的视图，这样开发人员就不必理解这个优化的模式。

由于其关系基础，除了简单的度量数据之外，Promscale还支持各种数据类型(数字、文本、数组、JSON、布尔值)、连接和ACID语义。因为Promscale构建在PostgreSQL之上，所以它在操作上非常成熟，并且包括高可用性、流式备份、随时间升级、角色和权限以及安全性等功能。

Promscale还受益于TimscaleDB用户社区：数千万次下载量、50多万个活动数据库、5000多名成员的Slack频道。

虽然Promscale是一个相对较新的项目，但它已经被全球的开发人员使用：

我们有不同数据源(如Graphite、Datadog和CloudWatch)提供的游戏指标。我们将所有这些指标都存储在普罗米修斯中，使用Promscale进行长期存储。Promscale让我们可以从这些不同的来源整理指标，并在统一的视图中生成单一报告，这样我们就可以更好地了解游戏内部正在发生的事情。&Saket K.--电子艺术公司软件工程师萨克特·K。

我们的目标是使用普罗米修斯监控我们来自世界各地的所有网站，并以用户友好的方式查看结果数据。我们选择Promscale来存储我们的数据，因为它可扩展，提供灵活性(例如，在不同节点之间划分读写活动)，并且具有PostgreSQL的操作成熟度和坚如磐石的可靠性，包括流式备份和高可用性。"；-陶氏化学服务专家Adam B.。

一开始我非常怀疑(特别是从来没有使用Grafana w/Postgres)，但仍然能够使用#PromQL来对抗@TimscaleDB是件好事。

-Matt(@halfmatthalfcat)2020年8月13日。

立即通过Helm Charts、Docker等安装Promscale。有关GitHub的更多信息。(如果您喜欢我们正在构建的内容，请在GitHub⭐️上给我们一个🤗。)

如果您安装了安装了Helm的Kubernetes集群，我们建议您使用TOBS在5分钟内安装完整的指标集合和可视化解决方案，包括Prometheus、Grafana、Promscale和PromLens预览版(视频)。

如有任何技术问题需要帮助，请加入Timescale Slake(#普罗米修斯)和/或Promscale-Users Google Group。

要参与路线图和产品讨论并与工程团队会面，请参加每月的用户和社区会议。

要了解有关此项目的起源、状态和路线图的更多信息，请继续阅读。

在过去几年中，开源系统监控和警报工具包Prometheus已成为现代软件系统的监控解决方案，该工具包可用于轻松且经济高效地监控基础设施。

普罗米修斯公司成功的关键在于它是为现代的、动态的系统建造的，在这些系统中，服务频繁地启动和关闭。普罗米修斯收集数据的简单方式非常适合于现代软件体系结构的短暂、多变的本质，尤其是微服务，因为服务本身不需要了解任何关于监控系统的信息。任何希望被监视的服务只需通过HTTP端点公开其指标。普罗米修斯定期采集这些端点，并将其看到的值记录到本地时间序列数据库中。

普罗米修斯的解耦架构使整个系统更具弹性。服务不需要监视堆栈就可以完成工作，并且监视软件只需要在实际收集服务时了解各个服务。这使得监控系统很容易在服务失败和新服务出现时进行无缝调整。

此体系结构还能很好地响应过载。而基于推送的体系结构在高负载时往往会淹没在流量中。普罗米修斯号只是放慢了它的刮擦循环的速度。因此，虽然您的度量分辨率可能会受到影响，但您的监控系统将保持正常运行。

与弹性和简单性的主题保持一致，普罗米修斯没有试图长期存储数据，而是公开了一个接口，允许专用数据库这样做。普罗米修斯不断将数据推送到这个远程写入接口，确保指标数据持久存储。这就是外部长期存储系统的用武之地。

随着开发人员使用普罗米修斯从越来越多的基础设施中收集数据，挖掘这些数据的好处也随之增加。对于审计、报告、容量规划、预测、根本原因分析等，分析变得至关重要。

普罗米修斯本身开发时就清楚地意识到它是什么，而不是设计来做什么。普罗米修斯被设计成一个监测和警报系统；但它不是一个持久的、高度可用的长期数据存储，也不是其他数据集的存储，也不是一个复杂的分析引擎。然而，尽管这些功能不是由普罗米修斯本身提供的，但它们对于度量数据的更长持续时间和更密集的使用至关重要，包括审计、报告、容量规划、预测分析、根本原因分析等。因此，普罗米修斯提供了挂钩来将其数据转发到更适合这些任务的外部数据存储。

现有的外部存储普罗米修斯数据的选择虽然有用，但都侧重于长期存储，在某些情况下，聚合形式有限。这样的系统只能存储浮点数并执行PromQL查询，这使得它们在数据存储和查询模型中都太有限，无法执行复杂的分析。

此外，尽管普罗米修斯体系结构非常适合在高度动态的环境中记录数据，但其以不一致的间隔收集数据的方法在分析数据时会带来挑战，因为不同端点上多个“同时”场景的时间戳可能会有很大差异。

普罗米修斯设计了一种名为PromQL的语言，通过在查询时规范化数据来解决这些困难：按用户指定的间隔对齐数据，并丢弃多余的数据点。虽然这种分析方法非常适合于在仪表板、警报和监控中发现的简单、快速的分析，但对于更复杂的分析可能会缺少这种方法。

例如，PromQL不能跨系列和跨时间进行聚合，因此很难(如果不是不可能)获得特定标签键随时间的准确统计数据，这对于通过查看长时间跨度内按应用程序版本分组的90%内存使用量来确定何时引入内存泄漏这样的事情是必要的。这种向下钻取和重新聚合对于许多类型的分析都很重要，因为即使数据包含手头问题所需的信息，在收集数据时通常也不会考虑到这种分析。其他PromQL特性(如联接、筛选器和统计信息)也受到类似的限制，限制了其在发现趋势和开发洞察力方面的使用。

其他人也写了关于这些问题的文章：CNCF SIG-可观察性工作组已经在可观察性领域整理了一份用例列表，这些用例需要更好的度量分析工具。广受欢迎的科技博客作者Dan Luu也有一篇广为流传的博客文章，内容是如何从你的指标数据中获得更多价值。

我们说，市场缺乏对普罗米修斯数据进行深入分析的系统，因为我们在监控自己的基础设施时感受到了这种需求。我们创建Promscale是为了克服一个我们和其他开发人员都非常熟悉的挑战：如何在我们的监控数据中轻松地找到复杂问题的答案？

作为软件开发人员和运营商，我们是普罗米修斯的忠实粉丝-尤其是，3.5年前，当我们最初发布我们之前的普罗米修斯适配器(第一批读写适配器之一)时，我们开始参与普罗米修斯生态系统。

但在多年的使用和研究之后，我们意识到我们需要的功能超出了普罗米修斯及其相关工具目前提供的能力。

有关正在监视的系统的辅助数据，以使用有助于我们了解其含义的附加信息(例如节点硬件属性、用户/所有者信息、地理位置或工作负载正在运行的内容)来增强指标。

将指标与此附加辅助数据和元数据相结合，以创建系统的完整视图。

用于历史分析的高效长期存储，如报告过去的事件、容量规划、审计等。

灵活的数据管理，可处理生成的大量数据监控，并提供分层支持，如多租户、自动数据保留和缩减采样。

各种指标之间的隔离。由于不同的指标可以由完全不同的系统发送，我们希望不同指标的性能和数据管理都是独立的(例如，这样一个指标的下采样不会影响其他指标)。

日志和跟踪以及指标，以提供更好的系统全面视图。如果所有这三个医疗模式都在同一个数据库中，那么这些数据之间的连接可以带来有趣的洞察力。(需要明确的是，Promscale目前不支持日志和跟踪，但这是未来工作的一个领域。)。

SQL作为一种通用的查询语言，用于PromQL不适合的一般分析，以及各种数据分析和机器学习工具所使用的通用语言。

我们的基础设施团队真正想要的是一个位于普罗米修斯之上的分析平台，以便对我们自己的基础设施实现更有洞察力和更具成本效益的观察性。

体系结构该体系结构使用标准的Remote_Write/Remote_Read普罗米修斯API，干净利落地插入普罗米修斯堆栈中的该空间。

Prometheus使用REMOTE_WRITE API将数据写入Promscale连接器，并将数据存储在TimscaleDB中。Promscale本机理解PromQL查询，并从TimscaleDB获取数据以执行它们，而SQL查询直接转到TimscaleDB。

Promscale可以部署在任何运行普罗米修斯的环境中，以及任何普罗米修斯实例。我们提供Helm图表，以便更轻松地部署到Kubernetes环境。

SQL接口存储在Promscale中的数据可以用PromQL和SQL查询。虽然我们使用的数据布局在内部相当复杂(在本设计文档中有更多详细信息)，但是您不需要了解任何内容就可以通过我们易于使用的SQL视图分析指标。

每个指标都通过以该指标命名的视图公开，因此名为CPU_USAGE的度量按如下方式查询：

时间值标签2020-01-01 02：03：04 0.90{"；命名空间"；："；产品"；，"；pod“："；xyz"；}2020-01-01：03：05 0.98{"；命名空间"；："；dev"；，"；pod”："；ABC"；}2020-01-01 02：03：06 0.70{"；命名空间"；："；产品"；，"；Pod"；："；xyz"；}。

Label表示与测量关联的全套标签，并表示为标识符数组。在上面的查询中，我们使用jsonb()函数查看JSON表示形式的标签。

每行都有一个唯一标识测量标签集的Series_id。这实现了按系列的高效聚合。您可以使用labels(Series_Id)函数轻松地从Series_id检索标签数组。如下面的查询所示，它显示了我们每个系列中有多少个数据点：

标签计数{"；Namespace"；："；Prod"；，"；Pod“："；xyz"；}1{"；Namespace"；："；dev"；，"；Pod”："；ABC"；}7{"；Namespace"；："；Prod"；，"；Pod"；："；Pod"；："；XYZ"；}3。

每个标签键(在我们的示例中是名称空间和Pod)都展开到自己的列中，存储其值的外键标识符，这允许我们按照标签键和值进行连接、聚合和过滤。您可以使用val(Id)函数获取由标签id表示的文本。这提供了一些很好的可能性，比如使用特定的标签键跨所有系列进行聚合。例如，要确定过去一年报告的按名称空间分组的CPU使用率中值，您可以运行：

选择val(Nampace_Id)作为命名空间，选择group(按值排序)内的perentile_cont(0.5)作为medianFROM“CPU_Usage”where time>；'；2019-01-01'；group by namepace_id；

时间值标签Series_id名称空间_id pod_id2020-01-01 02：03：04 0.90{1，2}1 22020-01-01 02：03：05 0.98{4，5}2 4 52020-01-01 03：03：06 0.70{1，2)1 1 1。

为了简化按标签的过滤，我们创建了与PromQL中的选择器相对应的运算符。这些运算符用于形式LABEL？(<；LABEL_KEY>；<；Operator>；<；Pattern>；)的WHERE子句中。这四个运营商是：

这四个匹配器对应于PromQL中的四个选择器中的每一个，尽管它们的拼写略有不同，以避免与其他PostgreSQL操作符冲突。它们可以使用任何布尔逻辑和任意WHERE子句组合在一起。

例如，如果您只需要生产名称空间名称空间中的那些指标，或者pod以字母"；ab"；开头的那些指标，则只需将相应的标签匹配器进行OR运算即可：

从"；cpu_use"；中选择avg(值)，其中标签？('；命名空间'；=='；生产'；)或标签？('；pod'；==~'；ab*'；)。

结合起来，这些功能为分析打开了各种可能性。例如，您可以使用以下命令轻松获取默认名称空间中每个容器的第99个内存使用率：

从CONTAINER_Memory_Working_Set_Bytes Used中选择val(used.tainer_id)CONTAINER，PERCENTIAL_CONT(0.99)组(ORDER BY USED BY USED.VALUE)PERCENT_USED_P99 FROM CONTAINER_MEMORY_WORKING_SET_BUSES USED WHERE标签？('；NAMESPACE'。

或者，从Dan Luu的帖子中举一个更复杂的例子，您可以通过查找那些内存利用率为99%的容器来发现过度配置的Kubernetes容器：

Memory_Allowed为(SELECT Labels(Series_Id)作为标签，value，min(Time)start_time，max(Time)作为end_time from tainer_spec_memory_Limit_by。

.