InfluxDB Cloud 2.0发布，成为时序数据无服务器平台

作者：Paul Dix / 用例，产品，开发者
2019年9月10日

导航到

今天，我们很高兴宣布InfluxDB Cloud 2.0的正式发布。InfluxDB 2.0将存储、UI和可视化（以前称为Chronograf）、处理、监控和警报（以前称为Kapacitor）整合为一个整体。它是TICK Stack的演变，以InfluxDB 2.0为中心，Telegraf数据收集器在边缘，提供单一统一的体验。它共享了开源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 地区，并在 Google Cloud 和 Azure 上提供服务。如果您想在其他地区和云服务提供商支持推出时收到通知，请在此处注册。

如果您急于开始使用 InfluxDB Cloud 2.0，可以点击这里。否则，在本文的其余部分，我将讨论我们为什么决定为 2.0 版本构建全新的 API。除了 API 之外，我们还创建了一种全新的查询、分析和数据处理语言 Flux。最后，我将通过一些使用核心 API 概念和 Flux 语言进行监控和警报功能开发的新近工作，来突出 InfluxDB 2.0 作为构建复杂时序应用平台的强大功能。

使用平台创建监控和警报功能

InfluxDB 2.0 的重要目标之一是为整个平台提供一个统一的 API 和语言。我们希望创建一组构建块，可用于构建更复杂的应用程序。编写和查询数据，由 InfluxDB 1.x 表示的功能，只是平台的一部分。为了表示后台处理，即 Kapacitor 的用途，我们定义了一个创建任务的 API。为了使用户能够定义我们不内置到声明式查询语言中的复杂逻辑，我们创建了新的语言 Flux，它可以用于交互式查询或后台处理。

Flux 和任务的结合使 InfluxDB 2.0 成为一个无服务器平台，用于处理时序数据。通过使用这种组合和内置的时序存储，我们能够创建一个具有自己观点的监控和警报应用程序，这也是本次发布的核心。

我们的监控应用程序将问题分解为五个不同的概念：检查、状态、通知规则、通知端点和通知。检查通过某些 Flux 查询定义输入数据，根据某些 Flux 逻辑定义的标准进行检查，然后生成不同级别的状态（正常、信息、警告、错误和未知）。检查的 Flux 逻辑和运行频率在后台的 Task 中定义。状态只是存储在 TSDB 中的更多时序数据。

通知规则定义了查询标准，以确定在什么频率和级别下查找哪些状态，以确定何时向特定端点发送通知。端点是可能发送通知的地方，如 Slack、PagerDuty 或 HTTP 目标。每当发送通知时，该操作都会记录到另一个时序中。通知规则包含用户配置的格式化信息，用于确定发送到通知端点的内容。

在用户界面中，这一切都是通过通过我们的点选式数据探索器构建基本查询来驱动的，选择触发特定级别状态的条件阈值，并配置通知规则以查找特定级别的状态（如错误）。要使用此系统，用户无需了解 Flux、我们的 API、Task 系统或其他底层组件。以下是体验的几张截图。

InfluxDB Cloud 2.0 无服务器平台 UI - 构建检查<figcaption> 构建检查</figcaption>

InfluxDB Cloud 2.0 无服务器平台 - 检查、通知端点和通知规则<figcaption> 检查、通知端点和通知规则的视图</figcaption>

InfluxDB Cloud 2.0 服务器端平台状态历史视图<figcaption> 状态历史视图</figcaption>

高级监控和自定义代码

尽管使用基本监控和警报功能用户不需要了解 Flux、任务以及状态时间序列数据，但他们可以利用这些概念来扩展我们的监控和警报系统，创建更复杂的监控。例如，这里有一个使用监控包中 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 data so there is a "usage_idle" column
    |> mean(column: "usage_idle")
    |> monitor.check(
        data: additional_status_data,
        messageFn: 	(r) => "${r._check_name} is at level ${r._level} with ${r.usage_idle}",
        warn: (r) => r.usage_idle < 10.0,
        crit: (r) => r.usage_idle < 5.0,
    )

我们查询的逻辑是基本的，但您可以看到在将数据传递给 check 函数之前可以进行更复杂的筛选或转换的部分。check 函数负责转换数据并将其写入一个具有符合我们期望的状态模式的已知桶中。《strong>monitor.check 函数本身是用纯 Flux 编写的，您在这里可以看到

// Check performs a check against its input using the given ok, info, warn and crit functions
// and writes the result to a system bucket.
check = (
    tables=<-,
    data={},
    messageFn,
    crit=(r) => false,
    warn=(r) => false,
    info=(r) => false,
    ok=(r) => true
) =>
    tables
        |> experimental.set(o: data.tags)
        |> experimental.group(mode: "extend", columns: experimental.objectKeys(o: data.tags))
        |> map(fn: (r) => ({r with
            _measurement: "statuses",
            _source_measurement: r._measurement,
            _type: data._type,
            _check_id:  data._check_id,
            _check_name: data._check_name,
            _level:
                if crit(r: r) then levelCrit
                else if warn(r: r) then levelWarn
                else if info(r: r) then levelInfo
                else if ok(r: r) then levelOK
                else levelUnknown,
            _source_timestamp: int(v:r._time),
            _time: now(),
        }))
        |> map(fn: (r) => ({r with
            _message: messageFn(r: r),
        }))
        |> experimental.group(mode: "extend", columns: ["_source_measurement", "_type", "_check_id", "_check_name", "_level"])
        |> experimental.to(bucket: "_monitoring")

在上面的定义中，您可以看到一些“实验性”命名空间的使用。由于我们已经有用户在生产环境中运行 Flux，我们需要一个区域来测试不会破坏以前函数定义的新功能。在任务和 Flux 之上开发监控和警报推动了 Flux 功能的新需求。我们将随着时间的推移将这些建议带入实验性命名空间之外的语言中，而不会破坏当前用户。

_monitoring 桶是存储所有检查生成的状态的地方。它们也是保存发送到第三方服务的任何通知日志的地方。由于所有这些都是在另一个桶中的更多时间序列数据，因此它们可以在仪表板上或其他数据中进行可视化。

高级用户可以定义自己的自定义任务，连接到第三方系统，在 InfluxDB 中的数据上进行复杂查询，并将这些数据作为状态写入。然后，这些数据将根据他们之前在 UI 中定义的通知规则被捕获。但用户也可以使用任务系统和查询 _monitoring 桶来创建自己的自定义通知逻辑。

随着我们添加更多像用户定义的包和更多连接到第三方系统的连接器这样的 Flux 功能，它将为完全由我们的用户驱动的监控、警报和 ETL 功能打开大门。同时，我们已尝试通过使用我们的平台原语构建的简单易用的 UI 来让用户走得更远，这样高级用户就可以比通过点击式 UI 走得更远。

仍然致力于开源

尽管这个发布公告是关于我们的 InfluxDB Cloud 2.0 产品，但我们仍然坚定不移地致力于开源。InfluxDB 2.0 目前是开源的，处于 alpha 阶段。我们的理念是将尽可能多的内容以不受限制的 MIT 许可证放入开源中。对于商业用途，您永远不需要猜测，因为它不会与我们的开源代码混合。对于开源的代码，它是无限制的。这是一份没有互惠要求或对您如何使用它的限制的礼物。作为开发者，没有什么比看到有人使用我们的代码来工作于他们的项目、改善他们的生活或在世界创造新事物更让我们开心的了。

为了实现这一目标，我们继续在公开场合开发平台的大部分功能。例如，我们的用户界面是使用Chronograf背后的相同技术构建的，并且我们已经将它们以MIT许可证开源，作为Giraffe，一个基于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 2.0可以像InfluxDB 1.x服务器一样进行写入和查询。这意味着支持InfluxQL，它将是我们2.0版本提供的一部分，并将标志着我们从alpha版本过渡到beta版本。我们还将构建迁移工具，将InfluxDB 1.x时间序列存储转换为InfluxDB 2.0。在beta阶段，我们将回归我们的根源，专注于一流的性能，并根据社区反馈继续完善用户界面。

今天开始使用

虽然监控和警报是这次发布的主要焦点，但我们将持续推出Cloud 2.0产品并不断改进它。我们非常希望听到您对InfluxDB 2.0、Flux或我们的云产品反馈。注册免费访问InfluxDB Cloud 2.0，或在我们的社区论坛上加入我们。