TICKscript开发状态

作者：Russ Savage / 产品，开发者
2018年4月9日

为了充分利用Kapacitor（TICK Stack中的“K”）以及它提供的监控和警报功能，您和您的团队需要编写TICKscripts。 TICKscript是一种简单而强大的方式，可以对通过InfluxDB流动的数据进行聚合、分析和警报。在这篇文章中，我将介绍编写TICKscripts的各种工具，并突出一些我在组织脚本开发过程中看到的常见模式。让我们从突出可用的TICKscripts开发工具开始。这些编辑器和IDE的插件是由社区贡献的，不是InfluxData维护的。如果您有喜欢的编辑器可能缺少TICKscript编辑器，我们鼓励您创建一个并分享到社区页面。

开发环境

每个开发者都有自己最喜欢的IDE，用于编写和部署代码。以下是关于开发者使用来编写TICKscripts的各种工具的简要介绍。

Chronograf Web UI

编写TICKscripts最快的办法之一是通过Chronograf UI内建的编辑器。要开始，请确保您可以在某处访问到完全运行的TICK Stack。如果您想在您的机器上试用，请查看此教程，了解如何设置和连接一切。TICKscript编辑器可以在创建子菜单中的警报选项卡下找到。

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

Vim集成

对于那些不喜欢离开终端的你们，InfluxData自己的Nathaniel Cook也维护了一个Vim插件。您可以在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 Hines为TICKscript语法高亮构建了一个很好的Atom包。通过Atom包安装器快速轻松安装，只需搜索language-tick即可。它不会自动格式化脚本，但语法高亮有助于快速查找问题。如果您希望在一页屏幕上查看所有内容，可以安装platformio-atom-ide-terminal插件，并在Kapacitor中使用它进行测试和安装脚本。

Jetbrains插件

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

Visual Studio Code插件

最后但同样重要的是，对于那些热爱Microsoft的Visual Code工具的您，Matt Jones也为其编写了一个TICKscript语法高亮插件。安装很简单，一旦您安装了Visual Code，只需通过浏览器中的安装按钮即可。像其他IDE一样，Visual Code包含一个集成的终端面板，这对于向Kapacitor发送命令非常有用。

推荐的开发工作流程

如您所见，编写 TICKscripts 可用的工具并不短缺。但拥有正确的工具只是解决方案的一部分。您还需要将 TICKscripts 从本地开发机器移动到生产系统的过程标准化。

让我们从部署环境开始。开发 TICKscripts 应像处理组织中任何其他类型的代码一样，您绝对不应该在生产环境中直接编辑脚本。我们的大多数大型用户至少有三种正在运行的环境：本地开发环境、集成环境和生产环境。您可能有更多，但如果没有这些，您将大大增加发布无法正常工作或监控的脚本的几率。所有新的脚本或更改都从左到右流动，而不会反过来，无论多么微小。

源代码控制是必需的

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

我们看到的另一个常见模式是，有一个集中的基础设施团队跟踪部署到公司每个 Kapacitor 实例的核心一组 TICKscripts。然后，每个团队也可以有自己的存储库和自己的脚本集。这里的想法是确保团队不需要互相请求许可来做出更改，因为每个团队都有自己的存储库，他们可以管理自己的 TICKscripts。

存储库结构

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

测试和部署更改

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

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

最后，一旦您的TICKscript在集成环境中验证为可工作，应使用部署脚本来将其自动加载到生产环境中。

所有这些可能一开始听起来需要做很多工作，但前期的一点点投资将会带来巨大的回报，提高敏捷性，并为您生产系统提供适当的警报。

结论

对于刚开始使用TICKscripts的大家，我希望我已经在工具和开发流程方面为您指明了正确的方向。如果您已经部署了大量的TICKscripts，请在评论中告诉我们，如果您有一些关于开发和维护脚本的有用技巧和建议。