使用推送与拉取进行监控：InfluxDB 通过 Kapacitor 增加拉取支持
作者：Paul Dix / 产品
2017 年 5 月 2 日
导航至
监控社区一直在争论关于推送与拉取监控的问题。一年前我坚定地站在推送阵营，但最近我开始欣赏拉取方法的优点，并且您需要推送和拉取两种方法。这就是为什么我很高兴今天我们发布了 Kapacitor 1.3 的 beta 版本，该版本增加了对服务发现和拉取（抓取）Prometheus 风格目标的支持。我们希望将监控和时序的最佳实践带给大家。请继续阅读，了解推送和拉取的定义、我对每种方法的优缺点的看法，以及如何使用 InfluxDB 和 Kapacitor 开始拉取监控和收集的示例。
澄清推送与拉取
在基于拉取的方法中，监控代理定期轮询被监控的目标，并根据这些数据发出警报。在推送方法中，遥测数据和指标被推送到监控代理（或更常见的是时序数据库），并且监控通过代理或其他查询数据库的进程完成。当检测您自己的应用程序代码时，需要在推送和拉取之间做出选择。您可以将指标通过客户端库发送到另一个服务，或者通过某些网络可寻址目标（例如 HTTP API）使它们可供他人使用。
与流行的看法相反，我认为对于您不控制和编写代码的服务和系统，所有监控和指标收集都始于拉取。例如，我们构建了 Telegraf 作为收集指标并将其推送到 InfluxDB 的代理。看起来像推送方法，对吧？有点像。它始于拉取。Telegraf 从目标（例如 Redis、MySQL）拉取数据，将指标格式化为 InfluxDB Line Protocol，然后将其发送到 InfluxDB。在 Telegraf 中，这发生在通过配置设置的定期轮询间隔中。
形式化拉取方法的真正优势在于，它为各种服务和应用程序提供了一种标准语言，以公开具有标准格式的目标，从中拉取指标数据。我认为这是 Prometheus 真正做对的地方。如果您想公开指标数据，这构成了一个标准，并且大大减少了编写收集器的精力。如果您查看 Telegraf 中的代码，每个插件（都是指标拉取器）都必须定义自定义代码来拉取数据并将其转换为正确的格式。
Prometheus 还添加了嵌入式数据库，使其不仅仅是一个像 Nagios 这样的简单监控代理。我认为数据库是人们在拉取和推送之间纠结的地方。当您想到数据库时，它始终是推送。
优点与缺点
两种方法都有优点和缺点。基于拉取的方法的主要缺点是它们不适用于事件驱动的时序数据（例如对 API 的单个请求或基础设施中的事件）。基于拉取的方法的优点是，任何外部系统都可以从您的应用程序收集遥测数据，而无需将数据发送到新服务。
虽然服务发现通常被列为拉取方法的优势，但这实际上只是谁与服务发现机制交互的区别。如果您使用推送方法，您可以让客户端库在启动时访问服务发现以找出它必须将指标和事件发送到哪里。您的目标不太可能更改，而您几乎肯定会启动新的服务和应用程序，这意味着您的指标拉取器必须定期轮询服务发现以查找新目标。
Kapacitor 与拉取
在此版本中，我们将 Prometheus 的服务发现和抓取代码集成到 Kapacitor 中。这意味着任何与 Prometheus 配合使用的服务发现目标都将与 Kapacitor 配合使用。结合 TICK 脚本，您可以使用 Kapacitor 监控 Prometheus 抓取目标，将数据写入 InfluxDB，并执行过滤、转换和其他任务。借助 Kapacitor 的用户定义函数 (UDF)，可以轻松引入高级异常检测和自定义逻辑。
示例
这是一个快速入门指南和示例，用于使 Kapacitor 将所有拉取数据写入 InfluxDB。首先，您需要运行 InfluxDB。安装 Kapacitor 1.3 版本的 beta 版
https://dl.influxdata.com/kapacitor/releases/kapacitor_1.3.0~beta2_amd64.deb
https://dl.influxdata.com/kapacitor/releases/kapacitor-1.3.0~beta2.x86_64.rpm
https://dl.influxdata.com/kapacitor/releases/kapacitor-1.3.0~beta2_windows_amd64.zip
https://dl.influxdata.com/kapacitor/releases/kapacitor-1.3.0~beta2_linux_amd64.tar.gz
https://dl.influxdata.com/kapacitor/releases/kapacitor-1.3.0~beta2_linux_i386.tar.gz
https://dl.influxdata.com/kapacitor/releases/kapacitor-1.3.0~beta2_linux_armhf.tar.gz您需要更新您的 Kapacitor 配置。这包括几个部分。首先是定义发现目标的配置。对于此示例，我们将从文件系统中的目录中发现抓取目标。使用以下部分更新您的 kapacitor.conf
[[file-discovery]]
enabled = true
id = "discover_file"
refresh-interval = "10s"
##### This will look for prometheus json files
##### File format is here https://prometheus.ac.cn/docs/operating/configuration/#%3Cfile_sd_config%3E
files = ["/Users/pauldix/prom/*.json"]您需要更新它查找文件的位置。在该目录中，它将查找与 prometheus 配置匹配的 JSON 文件。例如，如果我们在主机上的默认端口上运行 Prometheus Node Exporter，我们可以有一个 JSON 文件 prom.json
[{
"targets": ["localhost:9100"]
}]完成发现部分后，我们需要连接一个抓取器，它将抓取发现器拾取的所有目标。您可以通过将以下部分添加到您的 kapacitor.conf 来完成此操作
[[scraper]]
enabled = true
name = "node_exporter"
discoverer-id = "discover_file"
discoverer-service = "file-discovery"
db = "prometheus"
rp = "autogen"
type = "prometheus"
scheme = "http"
metrics-path = "/metrics"
scrape-interval = "10s"
scrape-timeout = "10s"
username = ""
password = ""
bearer-token = ""
ssl-ca = ""
ssl-cert = ""
ssl-key = ""
ssl-server-name = ""
insecure-skip-verify = false所有抓取的内容都将发送到 Kapacitor 中的 prometheus 数据库和 autogen 保留策略。这意味着任何在 Kapacitor 中启用的 TICK 脚本，这些脚本从该数据库和保留策略 (RP) 流式传输数据，都将在设定的抓取间隔从抓取器获取数据。
作为最后一步，让我们创建一个 TICK 脚本，该脚本获取抓取器的输出并将其写入我们的本地 InfluxDB。我们将使用相同的数据库和保留策略名称，因此首先我们需要更新 kapacitor.conf 中 influxdb 部分下的内容，以便我们将该数据从 Kapacitor 对所有 InfluxDB 数据的订阅中排除
[influxdb.excluded-subscriptions]
_kapacitor = ["autogen"]
prometheus = ["autogen"]完成这些操作后，我们应该在 InfluxDB 中看到所有抓取的数据。我们还可以添加 TICK 脚本来对抓取的数据发出警报，或者在将其写入数据库之前对其进行转换。查看我们在 github 中的prometheus TICK 脚本规范化器 repo。
即将推出
我们将更新并添加此内容。我们将与 Kubernetes 服务发现集成，在 Chronograf 中提供 UI 以使处理抓取器和发现目标更容易，以及一些预构建的 Chronograf 仪表板以配合更流行的 Prometheus 导出器。
