使用 Telegraf 进行综合监控

作者 Noah Crowley / 产品, 使用案例, 开发者
2019年9月16日

有两种主要的模式来收集关于您的系统和软件的数据：第一种是从应用程序内部收集数据，通常称为白盒监控；第二种是从外部查询系统并收集关于响应的数据。

谷歌的 SRE 书籍将白盒监控定义为“基于系统内部暴露的指标进行监控”，将黑盒监控定义为“测试用户所见的外部可见行为”。综合监控是黑盒监控系统的一种实现，它涉及创建模拟用户活动的请求。

通过综合监控，目的是暴露用户可能在使用系统时遇到的任何活动问题，例如网站无法访问。由于它代表了真实的用户痛点，因此这些数据作为寻呼的警报信号特别有用。

这补充了白盒方法，该方法允许开发人员和运维人员深入了解系统的内部运作，从而深入了解可能对用户隐藏的问题，例如导致成功重试的故障，并为调试目的提供宝贵的信息。

Telegraf 可以使用特定于应用程序的插件（例如 NGINX 或 MySQL 的插件）收集许多白盒指标，您可以使用 InfluxDB 客户端库来检测您的应用程序，但我们也可以使用 Telegraf 作为综合监控工具，从外部监控我们系统的状态。

HTTP 响应输入插件

Telegraf 的 http_response 输入插件通过使用自定义请求轮询端点来检查 HTTP 和 HTTPS 连接的状态，然后记录关于结果的信息。插件的配置允许您指定要查询的 URL 列表，定义请求方法，并发送自定义请求正文或标头来模拟外部用户和系统可能采取的操作。它还允许您通过验证对这些请求的响应是否与使用正则表达式的某些预定义字符串匹配来验证这些端点的行为。这些选项在如何监控我们的应用程序方面给了我们很大的灵活性。

对于正在轮询的每个目标服务器，插件将向 InfluxDB 发送一个度量，其中包含服务器（目标 URL）、请求方法、状态代码和结果的标签，以及包含关于响应时间、响应字符串是否匹配、HTTP 响应代码以及结果的数值表示（称为结果代码）的数据字段。

我们可以在 Telegraf 配置中为我们要监控的每个端点创建一个新块。Telegraf 将在每个收集间隔为每个配置块收集一次数据。

监控 influxdata.com

让我们看一个简单的例子：我们将创建一个简单的综合监控检查，它将告诉我们 influxdata.com 是否启动并运行。因为我们希望这些监控检查来自系统外部，所以我们需要建立某种独立的基础设施，与我们系统的其余部分分开，用于运行 Telegraf。这可能意味着在 AWS 上在不同的可用区运行，或者完全使用不同的云提供商。由于对于这个例子我实际上不需要长期存在的基础设施，我将配置 Telegraf 在我的 Mac 上运行，它位于 influxdata.com 基础设施之外。

我已经使用 Homebrew 安装了 Telegraf，所以下一步将是创建一个新的配置文件，其中包含我们的 http_response 设置。以下是 inputs.http_response 块的外观片段

# HTTP/HTTPS request given an address a method and a timeout
[[inputs.http_response]]
  ## List of urls to query.
  urls = ["https://influxdb.org.cn"]

[...]

  ## Optional substring or regex match in body of the response (case sensitive)
  response_string_match = "InfluxDB is the open source time series database"

这会查询 InfluxData 主页，并查找是否匹配短语“InfluxDB is the open source […]”。

需要注意的一点是，Telegraf 的收集间隔对于此插件尤为重要，因为它决定了向相关端点发出请求的频率。各个插件可以通过在相应的配置块中包含  interval  参数来定义自己的收集间隔。为了示例的缘故，我们将使用 Telegraf 默认值，但您需要决定适合您自己系统的适当间隔。您可以在此 gist 中找到完整的配置文件。

然后我们可以使用新配置启动 Telegraf 的副本，并且应该看到一些输出，如下所示

$ telegraf --config synthetic-telegraf.conf --debug
2019-07-01T11:51:52Z I! Starting Telegraf 1.10.4
2019-07-01T11:51:52Z I! Loaded inputs: http_response
2019-07-01T11:51:52Z I! Loaded aggregators: 
2019-07-01T11:51:52Z I! Loaded processors: 
2019-07-01T11:51:52Z I! Loaded outputs: influxdb
2019-07-01T11:51:52Z I! Tags enabled: host=noah-mbp.local
2019-07-01T11:51:52Z I! [agent] Config: Interval:10s, Quiet:false, Hostname:noah-mbp.local", Flush Interval:10s
2019-07-01T11:51:52Z D! [agent] Connecting outputs
2019-07-01T11:51:52Z D! [agent] Attempting connection to output: influxdb
2019-07-01T11:51:52Z D! [agent] Successfully connected to output: influxdb
2019-07-01T11:51:52Z D! [agent] Starting service inputs
2019-07-01T11:52:10Z D! [outputs.influxdb] wrote batch of 1 metrics in 9.118061ms
2019-07-01T11:52:10Z D! [outputs.influxdb] buffer fullness: 0 / 10000 metrics. 
2019-07-01T11:52:20Z D! [outputs.influxdb] wrote batch of 1 metrics in 7.672117ms
2019-07-01T11:52:20Z D! [outputs.influxdb] buffer fullness: 0 / 10000 metrics.

后续步骤

http_response 插件在创建监控请求方面提供了很大的灵活性，您可以使用这些请求更准确地模拟用户和应用程序可能如何与您的站点交互。例如，在 influxdata.com 上，您可能希望通过提交 POST 请求并验证响应是否包含来自搜索结果页面的文本，而不是仅仅检查页面是否加载，来验证您的搜索页面是否正常工作。由于综合监控旨在模拟用户体验，因此您的检查的具体数量、频率和实现将取决于您产品的设计和功能，但总的来说，您正在寻找诸如响应时间缓慢或错误率高等影响用户满意度的事情。

由于黑盒监控通常会暴露已经影响用户的问题，因此您还需要基于这些数据创建合理的警报策略。这可能意味着呼叫工程师，或在 Slack 中发送通知，此时他们将不得不转向更适合调试的数据：白盒指标和事件。

黑盒监控不能替代从您的应用程序捕获的数据，但它提供了端到端的覆盖，这在最灾难性的情况下非常有用。当与白盒工具结合使用时，它可以让您对软件的运行更有信心，使其成为监控系统的关键组件。