与推送相比的拉取式监控：InfluxDB通过Kapacitor增加拉取支持
作者：Paul Dix / 产品
2017年5月2日
导航至
监控社区一直在就推送与拉取式监控进行辩论。一年前我坚定地站在推送阵营，但最近我开始欣赏拉取式监控的优点，你需要两者兼具。这就是为什么今天我们兴奋地发布Kapacitor 1.3的测试版，它增加了对服务发现和拉取（抓取）Prometheus风格目标的支持。我们希望将两者的优点都带给监控和时间序列。继续阅读，了解推送和拉取的一些定义，我对每个优缺点的看法，以及如何使用InfluxDB和Kapacitor实现拉取式监控和收集的示例。
澄清推送与拉取
在基于拉取的方法中，监控代理定期轮询监控的目标，并根据这些数据发出警报。在推送方法中，遥测和指标被推送到监控代理（或更频繁地推送到时间序列数据库），监控是通过代理或其他查询数据库的过程完成的。在为您的应用程序代码进行仪表化时，需要在推送和拉取之间做出选择。要么您通过客户端库将指标发送到另一个服务，要么通过某种网络可访问的目标（例如HTTP API）使它们可供他人使用。
与普遍看法相反，我认为对于您不控制和为编写代码的服务和系统，所有监控和指标收集都从拉取开始。例如，我们构建Telegraf作为一个收集指标并将其推送到InfluxDB的代理。看起来像是推送方法，对吧？有点像。它从拉取开始。Telegraf从目标（例如Redis、MySQL）拉取，将指标格式化为InfluxDB行协议，并将它们发送到InfluxDB。在Telegraf中，这通过配置中设置的常规轮询间隔发生。
正式化拉取方法的真正优势是，它为各种服务和应用程序提供了一个标准语言，以标准格式公开目标以拉取指标数据。这正是我认为Prometheus真正做对的事情。如果您想公开指标数据，这使它标准化，并且显著降低了编写收集器的努力。如果您查看Telegraf中的代码，每个插件（即指标拉取器）都必须定义用于拉取数据并将其转换为正确格式的自定义代码。
Prometheus 还添加了嵌入式数据库，使其不仅仅是一个像 Nagios 那样的简单监控代理。我认为数据库就是人们争论什么是拉取什么是推送的地方。当你想到数据库时，它总是推送的。
优缺点
这两种方法都有优缺点。基于拉取的方法的主要缺点是它们不适用于事件驱动的时序数据（如 API 的单个请求或基础设施中的事件）。基于拉取的方法的强大之处在于，任何外部系统都可以收集您的应用程序的遥测数据，而无需将数据发送到新的服务。
虽然服务发现通常被列为拉取的优点，但实际上它只是与哪个系统交互服务发现机制的差异。如果你使用的是推送方法，你可以让客户端库调用服务发现来找出它在启动时需要发送指标和事件的位置。你的目标不太可能改变，而你几乎肯定会在启动新的服务和应用程序，这意味着你的指标拉取器将不得不定期轮询服务发现以找到新的目标。
Kapacitor & 拉取
在这个版本中，我们将 Prometheus 的服务发现和抓取代码集成到 Kapacitor 中。这意味着任何与 Prometheus 工作的服务发现目标将与 Kapacitor 一起工作。结合 TICK 脚本，您可以使用 Kapacitor 监控 Prometheus 抓取目标，将数据写入 InfluxDB，并执行过滤、转换和其他任务。使用 Kapacitor 的用户定义函数（UDFs），拉入高级异常检测和自定义逻辑变得轻而易举。
示例
这里有一个快速入门指南和示例，说明如何让 Kapacitor 将所有拉取数据写入 InfluxDB。首先，您需要运行 InfluxDB。安装 Kapacitor 1.3 版本的测试版。
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，我们可以有一个名为 prom.json 的 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 中启用的从该数据库和保留策略（RP）中流数据的 TICK 脚本都将从抓取器处接收在设置的抓取间隔中的数据。
作为最后一步，让我们创建一个 TICK 脚本，它将抓取器的输出写入我们本地的 InfluxDB。我们将使用相同的数据库和保留策略名称，所以首先我们想要更新我们的 kapacitor.conf 中的 influxdb 部分，以便从 Kapacitor 对所有 InfluxDB 数据的订阅中排除该数据
[influxdb.excluded-subscriptions]
_kapacitor = ["autogen"]
prometheus = ["autogen"]有了这些，我们应该会在 InfluxDB 中看到所有抓取的数据。我们还可以添加 TICK 脚本来警告抓取数据或在我们将其写入数据库之前对其进行转换。请参阅我们在 GitHub 上的 prometheus TICK 脚本标准化存储库。
即将推出
我们将更新此文档并添加内容。我们将与 Kubernetes 服务发现集成，在 Chronograf 中添加一个 UI 以使与抓取器和发现目标的工作更简单，以及一些与更流行的 Prometheus 导出器一起使用的预构建 Chronograf 仪表板。
