TICKscript 开发状态

导航至

为了充分利用 KapacitorTICK Stack 的“K”)及其提供的监控和警报功能,您和您的团队需要编写 TICKscript。TICKscript 是一种简单而强大的方法,用于聚合、分析和警报流经 InfluxDB 的数据。在本文中,我将介绍用于编写 TICKscript 的各种可用工具,并重点介绍我看到的一些用于组织脚本开发过程的常见模式。让我们首先重点介绍一些可用于编写 TICKscript 的开发工具。各种编辑器和 IDE 的插件由社区贡献,InfluxData 不维护。如果您有喜欢的编辑器,但可能缺少 TICKscript 编辑器,我们鼓励您创建一个并在社区页面中分享。

开发环境

每个开发者都有自己喜欢的 IDE,用于编写和部署代码。下面简要概述了我们了解的开发者正在用于编写 TICKscript 的各种工具。

Chronograf Web UI

开始编写 TICKscript 最快的方法之一是通过 Chronograf UI 中的内置编辑器进行。要开始使用,请确保您可以访问在某处运行的完整 TICK Stack。如果您想在您的机器上试用,请查看本教程,了解如何设置所有内容并进行连接。TICKscript 编辑器可以在创建子菜单的“警报”选项卡下找到。

从那里,您有两个选择:您可以使用 UI 中的向导创建警报规则,或者您可以创建和编辑自定义 TICKscript 来执行您喜欢的任何操作。在幕后,警报向导将生成一个 TICKscript,然后您可以进入并稍后手动编辑。这作为一个起点非常有用,然后您可以将其用于进一步的自定义。需要记住的一件事是,Chronograf UI 仅与您选择的链接 Kapacitor 实例交互。它将从那里提取脚本列表以及显示的实际代码。如果您在 Kapacitor 机器上本地存储了文件,如果您通过此 UI 进行更改,则需要手动同步它们。此外,在 Chronograf 1.4 版本中,我们引入了一个新的 Kapacitor 日志查看器,允许您在浏览器中查看任何 log() 命令的输出。这对于调试脚本非常有帮助。

Vim 集成

对于那些不喜欢离开终端的人来说,还有一个 Vim 插件,由 InfluxData 自己的 Nathaniel Cook 维护。它可以在 vim-tickscript GitHub 仓库中找到。使用您喜欢的 Vim 插件管理器可以快速安装,但在 README 文件中提供了 Pathogen 和 vim-plug 的说明。安装后,您可以运行  :TickInstallBinaries 命令,这将把  tickfmt 添加到您的路径,用于格式化您的脚本。当我安装这个时,由于我不使用 Vim 进行开发,我也需要安装 vim-go 插件,否则当我尝试运行脚本来安装  tickfmt 时,我看到了一堆错误。默认情况下,此插件将在您每次保存时自动格式化您的脚本,但这可以在首选项中更改。

Emacs 主要模式

当然,如果我们谈论 Vim,我们需要给 Emacs 同等的时间。Marc Sherry 整理了一个非常棒的 用于 TICKscript 文件的 Emacs 主要模式,并与社区分享。除了语法高亮和格式化之外,它还允许您通过 Emacs 命令运行常见的 Kapacitor 函数。您可以在 README 文件中找到命令列表。

Atom 集成

Atom 是一个极其灵活的开源文本编辑器,许多开发者喜欢使用。Bubba HinesTICKscript 语法高亮构建了一个不错的 Atom 包。通过 Atom 包安装程序可以快速轻松地安装,只需搜索  language-tick 即可完成设置。它不会自动格式化您的脚本,但语法高亮有助于快速查找问题。如果您正在寻找在一个屏幕上显示所有内容,您可以安装  platformio-atom-ide-terminal 插件,并使用它来测试和安装 Kapacitor 中的脚本。

Jetbrains 插件

Jetbrains Intellij 平台也支持 TICKscript 编辑,这要归功于 Vladislav Rassokhin 和他的 intellij-kapacitor 插件。这可以用于任何基于 Intellij 的 IDE,包括 GoLandIDEA。与 Atom 插件一样,它具有语法高亮,并且内置终端面板使在同一窗口中更新 Kapacitor 中的脚本变得容易。您还可以使用命令点击快速跳转到变量定义,就像编写 Java 或 Go 代码一样。

Visual Studio Code 插件

最后但并非最不重要的一点是,对于那些爱上 Microsoft 的 Visual Code 工具的人来说,Matt Jones 也为此编写了一个 TICKscript 语法高亮插件。一旦您安装了 Visual Code,就可以通过浏览器中的安装按钮轻松安装。与其他 IDE 一样,Visual Code 配备了一个集成的终端面板,可用于向 Kapacitor 发送命令。

推荐的开发工作流程

如您所见,用于编写 TICKscript 的工具种类繁多。但是拥有合适的工具只是解决方案的一部分。您需要标准化一个流程,将 TICKscript 从本地开发者机器移动到生产系统。

让我们从部署环境开始。TICKscript 的开发应像组织中的任何其他类型的代码一样处理,并且您永远不应直接在生产环境中编辑脚本。我们的大多数大型用户至少有三个正在运行的环境:本地开发环境、集成环境和生产环境。您可能有更多环境,但如果少于这些环境,您将大大增加推出无法正常运行或监控的脚本的几率。所有新脚本或更改都从左向右流动,绝不相反,无论多么小。

源代码控制是必须的

我们的许多客户将他们的 TICKscript 签入某种源代码控制系统,通常是 Git 或 SVN。我们建议围绕负责监控的不同团队组织存储库。单个存储库应包含单个团队在其 Kapacitor 实例或集群上部署的所有 TICKscript。这不仅使部署脚本更容易(存储库根目录中的一个 shell 脚本可以快速扫描存储库中的所有 TICKscript 并通过 Kapacitor API 加载它们),而且还使查找、添加和修复它们更容易,因为每个团队都管理自己的脚本。

我们看到的另一种常见模式是,当有一个集中的基础设施团队负责跟踪部署到公司中每个 Kapacitor 实例的核心 TICKscript 集时。然后,每个单独的团队也可以拥有自己的存储库和自己的脚本集。这里的想法是确保团队不必相互请求权限进行更改,因为每个团队都有自己的存储库,他们可以使用自己的 TICKscript 进行管理。

存储库结构

有许多不同的方法来构建包含您的 TICKscript 的存储库,从将所有脚本放在根目录中到将它们整齐地分类到文件夹中。如果您计划利用 Kapacitor 中基于文件的脚本加载,您将需要维护预定义的结构。无论它们是如何组织的,当它们被发送到 Kapacitor 时,每个脚本都仅通过其名称引用,因此我们建议将有用的关键字编码到文件和脚本的实际名称中。例如,如果数据团队有一个用于监控 Kafka 集群上高 CPU 使用率的警报,则脚本文件名可能是  data-team-kafka-high-cpu.tick ,并带有相应的脚本名称。当然,您可以自由选择您喜欢的任何格式,但我们的建议是在每个 Kapacitor 实例上保持一致,并将尽可能多的可搜索信息编码到其中。还要记住,结果是从 Kapacitor API 按字母顺序返回的。

测试和部署更改

更改 TICKscript 的过程也应遵循标准的开发最佳实践。开发者应首先从源代码控制中检出存储库,进行更改(可能在不同的分支上),并在将更改合并回主分支之前让另一个团队成员对更改进行代码审查。您还可以使用 Gonçalo Pestana 的这个很棒的库为您的 TICKscript 编写单元测试。使用此单元测试框架,您可以定义应触发警报的示例数据,并验证它是否按预期工作。这些单元测试应与您的 TICKscript 位于同一存储库中。

一旦您的代码合并回主分支,它应该使用自动化脚本部署到您的测试环境进行集成测试。您的集成环境应尽可能地模拟您的生产环境,以便可以在此处而不是生产环境中发现任何问题或与其他脚本或警报的冲突。您应该能够使用示例数据生成在集成环境中模拟您尝试警报的问题。

最后,一旦您的 TICKscript 在您的集成环境中被验证为工作正常,它应该使用部署脚本自动加载到您的生产环境中。

所有这些听起来一开始可能需要做很多工作来设置,但前期的少量投入将多次回报,提高敏捷性并为您的生产系统提供适当的警报。

结论

对于那些刚开始使用 TICKscript 的人,我希望我能够就工具和开发流程方面为您指明正确的方向。如果您已经部署了大量 TICKscript,请在评论中告知我们,如果您有一些用于开发和维护脚本的有用技巧和窍门。