为什么我们需要在Prometheus中进行服务发现？

Question

要告诉Prometheus要监视什么，我们将为它提供Node导出程序详细信息。在那种情况下，我无法得知在这种情况下为什么需要服务发现的真正原因？

Answer 1

在这种情况下，您提供的详细信息是服务发现，大概是通过静态或file_sd。

Answer 2

如果问题是为什么普罗米修斯需要发现，那很容易。

假设您在gcp（GKE）上拥有一个Kubernetes集群，计算实例的节点数可以改变很多。

发现服务将允许我们仅使用gcp特定的带有标签或其他内容的发现项来提供特定的详细信息。

这样，您不必在计算机后面检查实例的集群号是否正在移动。

Answer 3

为什么不只使用本地配置？ （而不是服务发现）

如今，人们不想管理要手动监视的服务列表：服务太多，服务更改太频繁等等。

此外，如今我们通常拥有适当的配置管理工具（选择您喜欢的任何工具... docker，kubernetes，Puppet，Ansible ...），这些工具通常具有服务的中央清单（实际上，不仅是清单，但说明配置和自上而下的管理工具。

所以选项是：

1. 手动管理代理列表
2. 该监视解决方案具有一个要监视的服务数据库：必须实施一种解决方案以使中央清单与监视解决方案同步。
3. 该监视解决方案没有要监视的服务数据库：监视仅从中央清单（kubernetes，Puppet ...或CMDB）中获取最新服务列表，以获取最新服务）。

注意：Prometheus并不打算本地支持每个可能的服务注册表。相反，建议通过查询您喜欢的服务注册表来生成YAML或JSON。

服务发现与Push-vs-Pull困境

有人主张监视代理程序应该简单地将指标推送到服务器上本地配置的监控平台（即推送指标，而不是从监控平台考虑）。我不会在这里重新讨论整个讨论（请参见Push needs Service Discovery和Why do you pull rather than push?）

（来自Robust-Perception的Brian Brazil）的观点之一是监视通常是关于CHECKING：检查您知道已部署的内容，部署的原因，行为方式，为什么应以某种方式运行（哪个应用程序，哪个模式使用...）。因此，必须为监视平台配置服务列表和预期状态。