使用InfluxDB监控Jenkins

作者：Anais Dotis-Georgiou / 产品，用例，开发者
2019年9月18日

DevOps的关键部分是持续集成/持续部署。Jenkins是最受欢迎的持续集成工具。Jenkins是一个开源的基于Java的自动化工具，能够帮助组织持续构建、测试和部署软件。Jenkins插件（其中超过14,000个）简化了各种开发任务的自动化。监控Jenkins对于管理Jenkins节点和执行自动化愿景至关重要。

InfluxData的Telegraf Jenkins插件可为您提供以下关于您的Jenkins节点和作业的洞察

• Jenkins_node
  • 磁盘可用空间
  • 温度可用空间
  • 内存可用空间
  • 内存总量
  • 交换空间可用空间
  • 交换空间总量
  • 响应时间
• Jenkins_job
  • 持续时间
  • 结果代码（0 = SUCCESS，1 = FAILURE，2 = NOT_BUILD，3 = UNSTABLE，4 = ABORTED）

InfluxDB的免费云版本和开源版本使InfluxDB成为任何想要监控Jenkins的人的选择，但Flux帮助它脱颖而出。Flux是一种轻量级的脚本语言，用于查询数据库和处理数据。包括InfluxDB在内的几种监控工具允许您设置对重要构建失败的警报，或将构建与性能指标关联起来以解决问题。然而，Flux使对Jenkins事件的复杂分析成为可能，以在问题发生之前预见问题。

在本教程中，我们将学习如何使用Jenkins插件与InfluxDB Cloud 2.0和开源InfluxDB 2.0。接下来，我们将发现如何使用UI轻松识别任何作业失败。最后，我们将编写一个Flux脚本来隔离持续时间大于类似作业平均持续时间两倍标准差的作业。

配置InfluxDB Cloud 2.0中的Jenkins Telegraf插件

首先，注册一个免费的InfluxDB Cloud 2.0账户。登录后，生成一个Telegraf配置以获取Jenkins指标

telegraf --config jenkins_cloud.conf --input-filter jenkins --output-filter influxdb_v2.0

现在，将适当的配置变量放入配置的输出部分

[[outputs.influxdb_v2]]
 ## The URLs of the InfluxDB cluster nodes.
 ##
 ## Multiple URLs can be specified for a single cluster, only ONE of the
 ## urls will be written to each interval.
 urls = ["https://us-west-2-1.aws.cloud2.influxdata.com"]

 ## Token for authentication.
 token = "$token"

 ## Organization is the name of the organization you wish to write to; must exist.
 organization = "[email protected]"

 ## Destination bucket to write into.
 bucket = "Jenkins"

您可以在https://us-west-2-1.aws.cloud2.influxdata.com的“加载数据”标签页中创建存储桶、查找令牌和设置权限。

接下来，填写配置的输入部分

[[inputs.jenkins]]
 ## The Jenkins URL
 url = "https://127.0.0.1:8080"
 username = "admin"
 password = "$jenkins"

最后，使用适当的配置运行Telegraf

telegraf -config jenkins_cloud.conf

有关设置和使用UI的更详细说明，请参阅2.0文档。

一目了然地找到失败

使用InfluxDB 2.0可视化Jenkins作业和节点非常简单。我可以进入数据探索标签页，在4次点击之内，我可以可视化200个成功作业的持续时间

我也可以立即可视化任何失败

在按结果代码“FAILURE”过滤作业后，我看到我的名为“Test”的作业失败了。我可以深入了解，隔离作业状态以确定失败的时间。

我还可以在仪表板标签页中创建包含所有这些信息的自定义仪表板，这样我就可以一目了然地查看任何查询。

使用Flux脚本识别可能存在问题的作业

能够查看作业持续时间和工作状态很有用，但我们可以用Flux做得更多。我将把我的分析推进一步。我将找到持续时间大于平均作业持续时间两倍标准差的作业。然后我可以按节点对这些作业进行分组，以识别可能存在问题的节点。

首先，让我们看一下我们的数据。以下查询让我可以看到所有作业的构建持续时间。

duration = 
  from(bucket: "Jenkins")
  |> range(start: v.timeRangeStart, stop: v.timeRangeStop)
  |> filter(fn: (r) => r._measurement == "jenkins_job")
  |> filter(fn: (r) => r._field == "duration")
  |> toFloat()
  |> keep(columns: ["_value", "name", "_time"])
  |> set(key: "mykey", value: "myvalue")

<figcaption>“持续时间”流的图形视图</figcaption>

<img class=”wp-image-237015 size-full” src=”https://w2.influxdata.com/wp-content/uploads/jenkins-table-view-of-duration-stream.png” alt=”Jenkins - “持续时间”流的表格视图” width=”1600” height=”385” /><figcaption>“持续时间”流的表格视图</figcaption>

通过视觉检查，我们发现大多数作业的平均构建持续时间大约为50ms。然而，也有一些作业构建时间很长。本练习的目标是隔离这些作业。《toFloat()`函数用于帮助应用后来的《map()`函数。《keep()`函数消除不需要的列，清理表格流。《set()`函数应用以使后续的连接成为可能。

首先，使用以下方法计算平均值：

mean = 
  from(bucket: "Jenkins")
  |> range(start: v.timeRangeStart, stop: v.timeRangeStop)
  |> filter(fn: (r) => r._measurement == "jenkins_job")
  |> filter(fn: (r) => r._field == "duration")
  |> group()
  |> mean(column: "_value")
  |> keep(columns: ["_value", "name", "_time"])

<figcaption>“平均值”流的表格视图</figcaption>

我们看到平均值接近50，正如预期的那样。

接下来，使用以下方法计算标准差：

duration_stddev = 
  from(bucket: "Jenkins")
  |> range(start: v.timeRangeStart, stop: v.timeRangeStop)
  |> filter(fn: (r) => r._measurement == "jenkins_job")
  |> group()
  |> stddev(column: "_value", mode: "sample")
  |> keep(columns: ["_value", "name", "_time"])

<figcaption>“duration_stddev”流的表格视图</figcaption>

接下来我们将计算一个“_limit”，我们的异常阈值，即平均值的两倍标准差。通过将标准差和平均值表连接起来，然后计算限制来实现此计算。

normal = 
  join(tables: {duration_stddev: duration_stddev , mean: mean}, on: ["name"])
  |> map(fn: (r) => ({r with _limit:(r._value_duration_stddev*2.0 + r._value_mean)}))
  |> keep(columns: ["_limit", "mykey"])
  |> set(key: "mykey", value: "myvalue")

<img class=”size-full wp-image-237022” src=”https://w2.influxdata.com/wp-content/uploads/Table-view-of-the-normal-stream.png” alt=”“normal”流的表格视图” width=”1600” height=”385” /><figcaption>“normal”流的表格视图</figcaption>

我们可以看到《set()`函数如何向表格流添加额外的列，就像应用在“持续时间”流上一样。

现在我们可以找到我们的异常作业。我们将“持续时间”和“正常”流连接起来，并将异常定义为任何大于限制的值。

anomaly = 
  join(tables: {duration: duration , normal: normal}, on: ["mykey"])
  |> map(fn: (r) => ({r with _anomaly:(r._value - r._limit)}))
  |> filter(fn: (r) => r._anomaly > 0)
  |> keep(columns: ["_anomaly", "name", "_time"])

<img class=”size-full wp-image-237023” src=”https://w2.influxdata.com/wp-content/uploads/scatter-plot-view-of-the-anomaly-stream.png” alt=”“anomaly”流的散点图视图” width=”1600” height=”758” /><figcaption>“anomaly”流的散点图视图</figcaption>

我们可以看到大约有20个作业的构建时间超过了我们的限制。符号形状和符号颜色已配置为按作业名称分组，因此我们可以轻松识别有问题的作业。

注意事项

请注意，本教程中使用的此数据是用于演示Flux功能的一些模拟数据。这有助于解释为什么似乎有如此多的作业具有“异常”的构建时间。我使用Jenkins UI创建了一个非常简单的作业，并使用Python-Jenkins CL将其复制了200次。Python脚本和Telegraf配置在此存储库中。

吞吐量和结论

InfluxDB UI 允许我们这些不擅长编程的人快速构建 Flux 脚本并可视化 Jenkins 指标。Flux 还允许我们对 Jenkins 指标进行复杂的分析，以便识别可能存在问题的节点并轻松隔离作业失败。InfluxDB Cloud 2.0 免费版可以让我们以非常好的吞吐量进行操作。考虑到限制，假设您已将 Telegraf 配置为node_exclude = ["*"]，您仍然可以每5分钟写入超过25000个包含作业指标的点，或每秒800个。希望您喜欢这个教程。如果您遇到障碍，请在我们社区网站或Slack频道上分享它们。