Telegraf 配置的持续部署
作者：Rick Brown / 用例，产品，开发者
2019年12月9日
导航至
在我将我的“使用 Telegraf 作为网关”文章分享给 Rawkode 后，他提到了一个他做的演讲，其中讨论了 Telegraf 的高级主题，包括他看到的需求：只需在 GitHub 中编辑配置文件就能自动配置正在运行的 Telegraf 实例。观看这个演讲在这里。
我对 Telegraf 重新加载其配置有一些疑问，他回答了这些问题，并想知道我是否已经在我的家庭局域网中运行了所有需要的工具组件来让这个工作正常。我可以考虑实施一个持续交付或发布自动化应用程序来做这件事，但我会看看是否可以使用我现有的。
我发现我已经使用了我需要的一切！所以这是一个 Telegraf 的持续部署机制。为了复制这个机制，你需要以下内容
- Telegraf
- 我主要使用 Linux 服务器，但我有几台 Windows 机器，我将在后面的文章中说明如何包括这些机器
- 对这些机器的 root 访问权限
- 以更改配置文件
- Node-RED
- 其他允许动态创建 HTTP 端点应用程序也会做得一样好，但我使用 Node-RED
- 嗯，就是这样！
当安装在 Linux 上（Debian - 其他发行版可能将配置位置放在其他地方），Telegraf 命令行选项读取 /etc/telegraf/telegraf.conf 和 /etc/telegraf/telegraf.d/*.conf。Telegraf 还包括从 HTTP 端点读取其配置的选项，如果你使用过 InfluxDB v2，你应该已经看到了这个选项。当你被提示使用 InfluxDB v2 配置 Telegraf 时，你会得到一个 API 令牌，你需要将其存储为环境变量在 Telegraf 运行的机器上，并会显示这个命令行
telegraf --config https://InfluxDBCloud2Instance/api/v2/telegrafs/NNN这个命令行会运行 Telegraf（假设它在你的 PATH 中），连接到指定的端点，从那里读取其配置。
那么，如果我使用这个配置会发生什么？
/usr/bin/telegraf -config http://192.168.1.8:1880/telegraf/myhost这应该会连接到那个 IP 地址（是我的 Node-RED 服务器）上的端口 1880（Node-RED 的端口），到端点 /telegraf/myhost。如果我可以让 Node-RED 响应 /telegraf/myhost 上的 Web 请求，我应该能够向 Telegraf 发送配置。
Node-RED 的 http-in 和 http-out 节点就是为了做这个而设计的。
下一个挑战是，我的每个Telegraf实例可能需要不同的配置集，所以我希望Node-RED能理解是哪个Telegraf实例在调用它，并根据需要更改配置。Telegraf将发送GET请求，因此它需要确保URL在某种方式下是唯一的。
之后，我希望Node-RED提供更新的配置，当我更改任何配置时，所以我需要让Node-RED定期刷新其配置。合理的刷新时间是多少？我选择10分钟。
然后我希望每个Telegraf实例都刷新配置，使一切自动化。这个合理的刷新时间是多少？我将尝试一小时。
当然，我希望所有这些操作都能在不暴露任何敏感配置信息的情况下运行，所以我需要让Node-Red修改检索到的配置，以添加个人信息，例如InfluxDB v2 API令牌。
这是一系列我需要完成的事情，让我们开始吧！
首先，Telegraf端
我在所有的LXC容器中使用systemd运行Telegraf，因此它会在启动时自动运行。因此，Telegraf的配置在systemd目录中。如果你是手动运行Telegraf，在sysvinit使用的系统上运行，或者从Docker运行，你需要相应地进行修改，但对我来说，我需要编辑位于这里的Telegraf服务文件
/lib/systemd/system/telegraf.service
将此文件复制到/etc，以便在Telegraf更新时保留
cp /lib/systemd/system/telegraf.service /etc/systemd/system现在编辑新文件。ExecStart行显示运行Telegraf的命令行，带有-config和-config-directory选项。将其更改为以下内容
ExecStart=/usr/bin/telegraf -config http://192.168.1.8:1880/telegraf/%H $TELEGRAF_OPTS注意%H。这是systemd中的一个特殊属性，意味着“用此机器的主机名替换”，因此每个机器将请求自己的配置集。这应该足以提供足够的唯一性——如果我想在单台机器上实现多个Telegraf实例，或者将此机制扩展到包括环境定义，我将研究systemd中的抽象来从EnvironmentFile条目中检索变量，而不是使用%H。
看看文件中的下一行
ExecReload=/bin/kill -HUP $MAINPID这表示“systemctl reload”命令将发送SIGHUP信号到Telegraf，这是设计用来使Telegraf刷新其配置的。我想要每小时执行一次。Linux机器运行cron用于定期自动任务，因此我们可以使用这个功能。创建文件/etc/cron.hourly/telegraf并将以下行放入其中
#!/bin/bash -e
# random sleep (max 5 min) to prevent clients from hitting the server at the same time
SLEEP=$[ ($RANDOM % 300) ] && sleep $SLEEP
systemctl reload telegraf这将使Telegraf每60-65分钟刷新一次其配置。
使该文件可执行
这将使Telegraf每60-65分钟刷新一次其配置。
使该文件可执行
chmod +x /etc/cron.hourly/telegraf注意
- 如果你的文件名使用标点符号，它将被cron拒绝。不能运行telegraf.runthis文件——只需保持文件名简单。
- 如果你想以不同的时间尺度刷新配置，cron系统的其他部分使这成为可能，因此你可以编辑crontab、cron.daily等。
现在运行两个命令
systemctl daemon-reload
systemctl restart telegraf然后Telegraf将在其日志文件中抱怨说它无法从任何地方获取配置。我们最好跳转到Node-RED并解决这个问题！
在离开之前，为在Windows上运行Telegraf的读者提供一个快速提示。编辑注册表，转到
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\telegraf将ImagePath更改为以下内容（将IP地址更改为自己的Node-RED服务器地址）
"C:\Program Files(x86)\Telegraf\telegraf.exe" --config
"http://192.168.1.8:1880/telegraf/%ComputerName%"重新启动，或运行“服务”并重启Telegraf。
这不会使Telegraf在Windows上定期重新加载其配置。只需重新启动PC或重启Telegraf服务即可。
现在，让我们转向Node-RED。
在Node-RED中创建一个新的选项卡。将该选项卡中所需节点添加到配置中。
第一个节点“时间戳”每10分钟更新一次配置。
下一个节点设置私有设置的属性。这些是“更改”节点，我将在此处添加所有个人信息以连接和验证我的InfluxDB云实例。它们看起来像这样
现在我们需要从它们存储的地方检索配置。我创建了这样的节点
这是您可以发挥创造力的时刻！您可能希望将配置存储在GitHub或GitLab中，或者您可能对软件定义网络（配置即服务）感兴趣，因此希望通过类似消息主题的东西发送更新。更新配置数据可以来自许多地方，而在Node-RED中唯一不同的是用于更新配置信息的节点类型。
我更喜欢直接使用Node-RED存储我的配置，因此我的配置节点看起来像这样
请注意“mustache”模板的选项urls、database、username和password。这些信息是从“更改”节点检索的，并插入到这里，因此数据始终是正确和最新的。
一个模板节点可以存在多个配置片段。根据您想要的最佳可读性、理解和适当的重用，创建每个模板节点，例如这个用于一组核心监控输入
在部署流程之后，我们所有的配置片段都会加载到Node-RED中，并且每10分钟刷新一次。最后的任务是提供一个Telegraf使用的网页。
此流程中的第一个节点是“http-in”节点。它监听对http://192.168.1.8:1880/telegraf/:hostname的GET请求。
:hostname自动成为Node-RED中的一个属性，我们将使用它来在“按主机名选择”切换节点中。记得我们配置Telegraf时用%H？这就是我们在这里使用的参数替换。
切换节点匹配主机名，并将请求发送到每个主机的特定路径。
为了跟随工作流程，让我们看看对于“mqtt”主机会发生什么。在切换节点选择“mqtt”路径后，它将进入一个“MQTT配置”模板节点，这使我能够为我的MQTT实现启用特定的监控配置。
该配置包含我的ActiveMQ和Jolokia-2配置信息（我使用ActiveMQ作为我的MQTT代理，因为它有监控钩子和所有我使用的主题的内置视图，以及有多少订阅者正在监听每个主题的指示）。然后工作流程将转到Linux配置节点，该节点插入我想要使用的所有标准Linux监控配置，并在末尾附加MQTT配置
最后一步是一个“http-out”节点，它响应原始请求者并返回所需的配置数据。
每隔几分钟，Node-Red会记录一个连接已被建立，并已提供新的配置。
从Telegraf端看起来如何？以下是名为“mqtt”的服务器中的telegraf.log部分，显示了向Telegraf发送重载命令时会发生什么，它如何在重启之前将所有缓冲点写入InfluxDB，并加载所有其更新的输入和输出。
请注意，重载后的第一个输出包含的点比重载前的输出更多。这是Telegraf在重载其配置时处理缓冲的输入。在测试中，我发现如果在Telegraf重载配置时通过HTTP写入Telegraf实例，HTTP端口将不打开，因此这可能是在确定配置重载频率时需要考虑的因素。
因此，现在我的所有Telegraf实例每小时都会更新其运行配置，这意味着我可以根据需要调整抖动和缓冲区，并且我可以像所需的那样更新我的配置，对于每个Telegraf实例、实例的子集或单个实例，而无需登录到服务器。
Node-RED甚至可以配置将您的标签提交到版本控制，这样所有的配置都安全可靠。
实际上，我已经配置了Node-RED到Telegraf，作为一个配置管理/变更管理/持续部署系统，全部通过UI元素使用基于模型的流程，无需一行代码。
我不知道我是否将继续使用这个机制来处理Telegraf配置，我是否会使用Telegraf网关机制，或者我是否会使用两者的组合。我现在会先使用两者的组合，并在以后的时间重新审视，以确定最适合我的用例的部署机制。
