在奥斯汀监控聚会上 Prometheus + InfluxDB：会后思考

作者：Paul Dix / 产品，用例，开发者
2017年4月21日

在昨晚的奥斯汀监控聚会上，很高兴看到Prometheus和InfluxDB可以一起使用。我将突出介绍我演讲中的一些细节，但首先我想指出Julius Volz（Prometheus的创造者之一）昨晚展示的一些我认为非常令人兴奋的工作。

Julius做了一场关于Prometheus的演讲，介绍了项目、数据模型、其查询语言和警报系统。他还谈到了他们关于基于拉取的监控方法的哲学以及为什么Prometheus更喜欢这种方式。我同意他的很多观点。任何系统都可以连接并拉取指标（我的笔记本电脑、生产监控、预发布监控、新监控等）。很容易拉起/metrics端点来查看暴露的内容。服务不需要了解监控系统。我实际上已经对基于拉取的方法持积极态度，我们将在几周后引入对拉取的支持，并在此基础上继续我们的传统推送方法。但我在这里提前了。

Julius的演讲结束时，他展示了一个Prometheus和InfluxDB的演示——使用InfluxDB作为Prometheus的远程存储后端。Prometheus已经有一段时间能够将指标推送到其他存储后端，但通过这项新工作，它现在增加了从远程存储后端读取的能力。他连接好一切，然后展示了一个查询，返回了数据。然后他删除了本地的Prometheus数据存储并重新启动。再次查询时，它仍然显示了所有数据，因为它正在实时从InfluxDB中拉取数据。

InfluxDB的支持是如何实现的？我最近给Julius发了一封邮件，询问他几周前在CNCFCon上关于远程存储系统演讲的事情。经过一个周末的编码活动，Julius添加了这个功能。我对两个项目能一起工作感到兴奋，并且我们近期有一些事情可以做，以改善Prometheus + InfluxDB用户的使用体验。主要的是，我们将把远程网关引入InfluxDB，这样就可以配置和使用远程存储，而无需额外的软件来运行和管理。当我们着眼于InfluxDB 2.0的改进时，我们将关注那些能让Prometheus和InfluxDB更好地一起工作的功能和集成。

在昨天的演讲中，我介绍了Graphite、OpenTSDB、Prometheus和InfluxDB的数据模型看起来是什么样子。我将这些材料用作介绍我希望InfluxDB支持的新数据模型。我还讨论了每个项目的查询语言的一些高层次想法以及InfluxQL的未来发展。简而言之，我认为我们需要简化我们的数据模型，并暴露一个更强大、可扩展和易于表达的功能查询语言。我将发布一个PR，其中包含关于建议更新的详细文档和理由，以期在开始初步实施之前收集社区反馈和改进。

以下是演讲的幻灯片。在更详细的信息之前，这里是一些高层次的需求

• 必须能够支持InfluxDB 1.x数据模型
• 必须能够支持InfluxDB 1.x查询
• 支持Prometheus数据模型
• 新的功能查询语言
• 丰富的查询构建器UI（用户无需学习查询语言即可获得洞察和可见性）
• 查询完成CLI
• 可能支持PromQL查询？

我认为我们将在未来12个月内取得一些重大改进。我正在推动从0.8 InfluxDB到1.x的进步，但这次没有破坏性更改。新的InfluxDB将是1.x的替代品。可能需要进行数据迁移，但它应该支持InfluxDB 1.x用户，并为他们提供走向更高级功能的明确路径。这项工作可能需要一整年甚至更长时间才能准备好投入生产，但我们将在发布早期原型的同时，继续发布1.x版本，并继续推出新功能。