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。在这个共享 API 的基础上，我们构建了一个全新的 UI，用于构建仪表板和探索您的数据、定义数据收集配置、监控和警报规则、后台处理和管理功能。

InfluxDB 2.0 是我们愿景的演进，旨在创建一个完整的平台来解决基于时间序列数据的问题。我们一如既往的目标是优化开发人员在使用 InfluxDB 创建时间序列应用程序时的生产力和幸福感。这些应用程序可能用于服务器监控、传感器数据和监控、实时分析、应用程序性能指标、网络监控、金融市场数据以及几乎任何您可能想要检查、研究、监控和及时采取行动的事项。此版本代表了我们构建全新功能和能力的基础。它还引入了一个易于使用的应用程序，用于创建基于时间序列数据的监控和警报规则。

InfluxDB Cloud 2.0 是一个用于处理时间序列数据的无服务器平台，无论您是存储和查询、在后台处理、与第三方系统集成、配置收集代理还是创建仪表板。我们称之为 InfluxDB，但它与传统数据库或 DBaaS 完全不同。它采用付费的基于使用量的定价模式，或具有速率和数据保留限制的免费层级。付费使用模式基于您消耗的存储、计算和网络资源，并且可以向上扩展，无需任何重新配置或联系销售人员。这意味着您不再需要花费时间猜测您的实际项目之前需要多大尺寸的 InfluxDB 服务器或集群。

尽管今天的公告是关于我们的云产品，但我们仍在开源中继续开发许多这些组件。我将在本文稍后介绍特定的库、项目和 InfluxDB 2.0 开源版本。

今天，我们发布时支持 AWS 俄勒冈区域，未来几周将在 AWS 欧盟区域进行 beta 测试。我们将在未来几个月内推广到其他 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 逻辑和频率在后台任务中定义。状态只是更多的时间序列数据，保存在 TSDB 中。

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

在用户界面中，这一切都是通过构建基本查询（通过我们的点击式数据浏览器）、选择触发特定级别状态的阈值以及配置通知规则来查找特定级别（如严重）的状态来驱动的。要使用此系统，用户无需了解任何关于 Flux、我们的 API、任务系统或其他底层组件的知识。以下是一些体验截图。

<figcaption> 构建检查</figcaption>

<figcaption> 检查、通知端点和通知规则视图</figcaption>

<figcaption> 状态历史视图</figcaption>

高级监控和自定义代码

即使基本监控和警报功能的用户不需要了解 Flux、任务和状态时间序列数据，他们也可以利用这些概念来扩展我们的监控和警报系统，以创建更复杂的监控。例如，这是一个 Flux 脚本，它使用了 monitor 包中的 check 函数

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 函数负责转换数据并将其写入一个众所周知的存储桶，其模式符合我们对状态的期望。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")

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

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

高级用户可以定义自己的自定义任务，这些任务连接到第三方系统，对 InfluxDB 中的数据执行复杂查询，并将该数据作为状态写出。然后，这些状态将被他们在 UI 中先前定义的通知规则拾取。但是用户也可以使用任务系统和查询 _monitoring 存储桶来创建自己的自定义通知逻辑。

随着我们添加更多 Flux 功能（如用户定义的包和更多第三方系统连接器），它将完全由我们的用户驱动，从而打开监控、警报和 ETL 功能。与此同时，我们已尝试通过使用我们的平台原语构建的易于使用的 UI，让我们的用户完成大部分工作，以便高级用户可以比我们通过点击式 UI 驱动走得更远。

仍然致力于开源

即使此版本公告是关于我们的 InfluxDB Cloud 2.0 产品，我们仍然坚定地致力于开源。InfluxDB 2.0 目前是开源的，并且处于 alpha 阶段。我们的理念是将尽可能多的东西以不受限制的 MIT 许可证开源。对于商业化的东西，您永远不必猜测，因为它不会与我们的开源代码混在一起。对于开源的代码，它是没有限制的。这是一份礼物，不要求互惠或限制您可以用它做什么。作为开发人员，当有人使用我们的代码来处理他们的项目、改善他们的生活或在世界上创造新事物时，没有什么比这更让我们高兴的了。

为此，我们继续在开源中开发平台的大部分内容。例如，我们的 UI 是使用 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 1.x 服务器一样写入和查询 InfluxDB 2.0。这意味着对 InfluxQL 的支持，这将是我们 2.0 中提供的一部分，并将标志着我们从 alpha 过渡到 beta。我们还将构建迁移工具，以将 InfluxDB 1.x 时间序列存储转换为 InfluxDB 2.0。在 beta 阶段，我们将回归本源，专注于一流的性能，并根据社区反馈继续改进用户界面。

立即开始

虽然监控和警报是此版本的主要重点，但我们将不断发布我们的 Cloud 2.0 产品并不断改进它。我们很乐意听取您对 InfluxDB 2.0、Flux 或我们的云产品的反馈。注册 免费访问 InfluxDB Cloud 2.0，或 加入我们的社区论坛。