InfluxDB云2.0作为时间序列数据的无服务器平台推出
通过保罗迪克斯/ 2019年9月10日/社区，InfluxDB云，开发人员，通量
今天我们很高兴地宣布InfluxDB云2.0．InfluxDB 2.0将存储、UI和可视化(以前是Chronograf)、处理、监控和警报(以前是Kapacitor)整合为一个整体。它将TICK堆栈发展为一个单一的统一体验，中心是InfluxDB 2.0，边缘是Telegraf数据收集器。有一个通用的API在开源的InfluxDB 2.0和InfluxDB Cloud 2.0之间共享。在这个共享API的基础上，我们构建了一个全新的UI，用于构建仪表板和浏览数据、定义数据收集配置、监控和警报规则、后台处理和管理功能。
InfluxDB 2.0是我们为解决基于时间序列数据的问题而创建一个完整平台的愿景的演进。与以往一样，我们的目标是在使用InfluxDB创建时间序列应用程序时优化开发人员的工作效率和幸福感。这些可能是服务器监控、传感器数据和监控、实时分析、应用程序性能指标、网络监控、金融市场数据，以及几乎任何您可能想要检查、研究、监控和随着时间的推移采取行动的内容。这个版本代表了我们构建一套全新特性和功能的基础。它还介绍了一个易于使用的应用程序，用于基于时间序列数据创建监视和警报规则。
InfluxDB Cloud 2.0是一个用于处理时间序列数据的无服务器平台，无论您是存储和查询、在后台处理、与第三方系统集成、配置收集代理还是创建仪表板。我们称之为InfluxDB，但它与传统的数据库或DBaaS完全不同。它的特点是基于付费使用的定价模式，或带有费率和数据保留限制的免费层。付费使用模式基于您所消耗的存储、计算和网络资源，并且能够在不进行任何重新配置或与销售联系的情况下进行扩展。这意味着您不再需要在实际项目之前花时间猜测需要多大的InfluxDB服务器或集群。
尽管今天的公告是关于我们的云产品，但我们将继续以开源的方式开发这些组件。我将在本文后面介绍具体的库、项目和InfluxDB 2.0开源版本。
今天，我们将推出对AWS俄勒冈地区的支持，并在未来几周内在AWS欧盟地区进行测试。我们将在未来几个月内推广到其他AWS地区，并在谷歌Cloud和Azure上提供该服务。如果您希望在其他地区和云提供商支持启动时收到通知，可以这样做在这里注册．
如果你着急的话开始使用InfluxDB云2.0，你可以点击这里．否则，在这篇文章的其余部分，我将讨论为什么我们决定为2.0构建一个全新的API。除了API之外，我们还创建了Flux，这是一种用于查询、分析和数据处理的全新语言。最后，我将逐步介绍我们最近使用核心API概念和Flux语言开发的一些监视和警报功能，以强调InfluxDB 2.0作为构建复杂的基于时间序列的应用程序的平台的强大功能。
使用该平台创建监控和警报功能
InfluxDB 2.0更大的目标之一是为整个平台提供统一的API和语言。我们希望创建一组构建块，用于组合更复杂的应用程序。写入和查询数据，由InfluxDB 1表示的功能。X只是平台的一部分。为了表示后台处理，即Kapacitor的用途，我们定义了一个用于创建任务的API。为了让用户能够定义声明式查询语言中没有的复杂逻辑，我们创建了新语言Flux，它可以用于交互式查询或后台处理。
Flux和Tasks的组合使InfluxDB 2.0成为处理时间序列数据的无服务器平台。使用这种组合和内置的时间序列存储，我们能够创建一个独立的监视和警报应用程序，这是这个版本的重点。
我们的监视应用程序将这个问题分解为五个不同的概念:检查、状态、通知规则、通知端点和通知。检查获取由某些Flux查询定义的输入数据，根据某些Flux逻辑定义的标准检查它们，然后生成不同级别的状态(ok、info、warn、critical和unknown)。运行检查的Flux逻辑和频率定义在幕后的Task中。状态只是保存在TSDB中的更多时间序列数据。
通知规则定义了查询条件，用于确定何时向特定端点发送通知的频率和级别。端点是发送通知的地方，如Slack、PagerDuty或HTTP目标。每当发送通知时，该操作将被记录到另一个时间序列。通知规则包含用户配置的格式化信息，用于向通知端点发送内容。
在用户界面中，这一切都是由通过指向点击数据资源管理器构建基本查询、选择阈值以触发某个级别的状态以及配置通知规则以查找某个级别的状态(如critical)所驱动的。要使用这个系统，用户不需要了解Flux、我们的API、Task系统或其他底层组件。以下是这次体验的一些截图。
< fig标题>建立一个检查
< fig标题>检查、通知端点和通知规则视图 . /
< fig标题>状态历史视图 . /
高级监控和自定义代码
尽管基本监视和警报功能的用户不需要了解Flux、Tasks和Status时间序列数据，但他们可以利用这些概念来扩展我们的监视和警报系统，从而创建更复杂的监视。例如，下面是一个使用monitor包中的check函数的Flux脚本:
from(bucket: "foo") |> range(start: -1m) |> filter(fn: (r) => r._measurement == "cpu" AND r._field == "usage_idle" AND r.cpu == "cpu-total") |> v1.fieldsAsCols() // pivot数据所以有一个"usage_idle"列|> mean(列:"usage_idle") |> monitor。check(data: additional_status_data, messageFn: (r) => "${r。_check_name}的级别为${r。_level}和${r。usage_idle}”,警告:(r) = > r.usage_idle < 10.0,暴击:(r) = > r.usage_idle < 5.0,)我们正在查询的逻辑是基本的，但是您可以看到在将检查函数传递给数据之前可以对数据执行更复杂的选择器或转换的部分。check函数负责转换数据，并使用符合我们预期状态的模式将其写入一个已知的存储桶。的monitor.check函数本身是用纯Flux编写的，你可以在这里看到:
// Check使用给定的ok, info, warn和crit函数对其输入进行检查，并将结果写入系统桶。check =(tables=<-， data={}， messageFn, crit=(r) => false, warn=(r) => false, info=(r) => false, ok=(r) => true) => tables |> experimental。Set (o: data.tags) |> experimental。组(模式:“扩展”，列:实验。objectKeys(o: data.tags)) |> map(fn: (r) => ({r with _measurement: "status "， _source_measurement: r._measurement， _type: data. properties)_type， _check_id:数据。_check_id， _check_name:数据。_check_name， _level: if crit(r: r)那么levelCrit else if warn(r: r)那么levelWarn else if info(r: r)那么levelInfo else if ok(r: r)那么levelOK else levelUnknown， _source_timestamp: int(v:r._time)， _time: now()，}) |> map(fn: (r) => ({r with _message: messageFn(r: r)，}) |> experimental。组(模式:"extend"，列:["_source_measurement"， "_type"， "_check_id"， "_check_name"， "_level"]) |> experimental。(斗:“_monitoring”)在上面的定义中，您可以看到“实验性”名称空间的一些使用。由于我们已经有用户在生产环境中运行Flux，所以我们需要一个区域来测试不会破坏先前函数定义的新功能。在Tasks和Flux之上的监视和警报的开发推动了对Flux功能的新需求。随着时间的推移，我们将把这些更改引入实验性名称空间之外的语言，而不会影响当前用户。
的_monitoringBucket是存储检查生成的所有状态的地方。它们也是发送给第三方服务的任何通知日志保存的地方。由于所有这些只是另一个bucket中的更多时间序列数据，因此可以在仪表板上或与其他数据一起可视化。
高级用户可以定义自己的自定义任务，连接到第三方系统，对InfluxDB中的数据执行复杂的查询，并将数据作为状态写入。然后，它们将被之前在UI中定义的通知规则拾取。但是用户也可以使用任务系统创建自己的自定义通知逻辑_monitoring桶。
随着我们向第三方系统添加更多的Flux功能，如用户定义的包和更多的连接器，它将开放完全由用户驱动的监控、警报和ETL功能。与此同时，我们试图让我们的用户通过一个简单易用的UI，使用我们的平台原语构建，这样高级用户可以走得更远，而不是我们通过指向点击的UI。
仍然致力于开源
尽管这个发布公告是关于我们的InfluxDB Cloud 2.0产品的，但我们仍然坚定地致力于开源。InfluxDB 2.0目前是开源的alpha版本。我们的理念是在不受限制的MIT许可下，将尽可能多的东西公开。对于商业的东西，你永远都不需要猜测，因为它不会与我们的开放源代码混合在一起。对于公开的代码，它是不受限制的。这是一份礼物，不要求互惠，也不限制你可以用它做什么。作为开雷竞技有结算错误吗发人员，没有什么比有人使用我们的代码来完成他们的项目、改善他们的生活或在世界上创造新的东西更让我们高兴的了。
为此，我们将继续开放开发平台的大部分内容。例如，我们的UI是使用与Chronograf相同的技术构建的，我们在MIT的许可下开源了它们长颈鹿，一个基于react的可视化库和Clockface，一个React + Typescript UI工具包．这是除InfluxDB 2.0、它的用户界面和API都是公开的．
Telegraf，我们的数据收集器，仍然是我们最受欢迎的开源项目。它有数百个由活跃的开源社区提供的插件，这些插件不仅连接到InfluxDB，还连接到其他开源数据存储，甚至竞争激烈的SaaS提供商。我们的模型是构建一个具有最高贡献机会的收集器，因此我们有意地使它与其他数据存储可互换。
Flux:我们新的编程语言，查询计划器，引擎和优化器完全是在露天开发的。InfluxDB是运行它的一种方式，但我们也有一个CLI，我们已经设计了库，以便它可以导入到其他基于Go的项目中。我们使用Flux的目标是在贡献和与其他系统集成方面模仿Telegraf。也就是说，我们并不期望它只用于InfluxDB，我们正在积极支持与其他数据源和接收器的集成。
InfluxDB 2.0开源将继续进行功能开发。我们将更新Flux，用户界面，并添加到API中。我们还将添加一个兼容性层，以便可以像InfluxDB 1一样写入和查询InfluxDB 2.0。x服务器。这意味着对InfluxQL的支持，它将成为我们在2.0中提供的一部分，并标志着我们从alpha过渡到beta。我们还将构建从InfluxDB 1进行转换的迁移工具。x时间序列存储到InfluxDB 2.0。在测试阶段，我们将回归本源，专注于最佳性能，并根据社区反馈继续优化用户界面。
从今天开始
虽然监控和警报是这个版本的主要关注点，但我们将继续发布云2.0产品，并不断改进它。我们很乐意听到您对InfluxDB 2.0、Flux或我们的云产品的反馈。报名参加免费访问InfluxDB云2.0,或跳进我们的社区形式．