试用了 Prometheus 的 Agent 模式

1 年 ago

科, 颖

2 minutes

首先

我尝试了新添加的Prometheus Agent模式。
关于Agent模式，Prometheus官方博客中的《引入Prometheus Agent模式，一种高效且原生于云的指标转发方式》可能是最详细的内容，建议您一并参考。

关于Prometheus的远程写入功能，请说明。

Prometheus的本地存储有一些限制，如果需要可扩展性和长期持久性，就需要使用远程存储。
为了与远程存储进行交互，Prometheus提供了Remote Read/Write接口。
远程存储并不一定需要同时实现Remote Read/Write。
一些支持这些功能的远程存储包括Thanos、Cortex、Google Cloud Managed Prometheus和Amazon Managed Service for Prometheus。
虽然“Remote Storage”这个术语有些过时，但在@kkohtaka的“Prometheus の Remote Storage とは?”一文中提及，建议一并参考。

在使用Remote Write时，Prometheus的功能/用途。

正如前面所述，远程存储不一定需要同时实现读和写的功能，例如Thanos只实现了远程写入功能。那么要如何访问已写入的指标数据呢？可以通过实现了Prometheus的查询API的Thanos Query组件进行访问。因此，即使Thanos没有实现远程读取的API，也可以通过Thanos来访问指标数据，例如通过Grafana。

在这种情况下，Prometheus不再需要接受度量查询请求。由于警报也可以在Thanos的组件中进行评估，因此不再需要在Prometheus中进行评估。此外，当使用Remote Write时，数据几乎实时地传输给Thanos，因此可以将Prometheus视为无状态应用程序。

就像Thanos一样，通过远程存储，用户可以不再需要Prometheus的查询功能和存储功能。可能除了Thanos之外的其他远程存储也会出现类似的情况（我记得很久以前Cortex也是如此）。由于Prometheus往往消耗相当多的资源，所以这次的代理模式是为了在这种使用场景下进行优化。这是我个人非常高兴的功能增加。

Prometheus的代理模式是什么？

Agent模式是Prometheus中的一种新的运行模式，专门用于目标的发现、指标的抓取和远程写入。启用Agent模式将禁用查询、警报和本地存储，并使用定制的TSDB WAL。在这个定制的TSDB WAL中，当远程写入成功后，将删除该数据；如果失败，则将数据暂时保存在本地存储中，直到远程存储恢复为止（与通常启动的Prometheus缓冲区类似，最长保留2小时）。据说，Agent模式在将来可能会取消这个限制。由于查询功能被禁用，因此不再需要建立完整的索引，并且在这些方面也进行了优化。

Grafana Agent这个工具能够实现类似的功能，看起来已经将其实现移植到了Prometheus上。
这个功能的提案在这里，PR在这里。

在代理模式下运行

由于没有正式版本中运行Agent模式的选项可用，所以在2021年12月1日目前，我尝试使用quay.io/prometheus/prometheus:v2.32.0-beta.0进行测试。
要在Agent模式中运行Prometheus，您可以通过启用 –enable-feature=agent 标志来使用。
抓取逻辑、服务发现以及相关配置等似乎都是相同的。
然而，如果包含一些在Agent模式下不使用的Prometheus配置，则它将无法启动。
当我尝试直接使用以前的配置文件时，我注意到存在一些在Agent模式下不使用的配置项，导致它无法启动。
我发现了以下两个问题：如果存在与警报和规则相关的配置项，它将引发错误，导致无法启动（希望它们可以被忽略）。

ts=2021-12-01T09:23:35.070Z caller=main.go:195 level=info msg="Experimental agent mode enabled."
ts=2021-12-01T09:23:35.073Z caller=main.go:437 level=error msg="Error loading config (--config.file=/etc/prometheus/config/prometheus.yml)" err="field alerting is not allowed in agent mode"

ts=2021-12-01T09:25:06.150Z caller=main.go:195 level=info msg="Experimental agent mode enabled."
ts=2021-12-01T09:25:06.153Z caller=main.go:437 level=error msg="Error loading config (--config.file=/etc/prometheus/config/prometheus.yml)" err="field rule_files is not allowed in agent mode"

本次是在Kubernetes上运行，只通过以下args参数进行特殊的代理模式设置，其他选项没有改变。

--config.file=/etc/prometheus/config/prometheus.yml
--web.external-url=XXXXXXXXXXXXXXXXXX
--web.enable-lifecycle
--web.enable-admin-api
--enable-feature=agent

顺便提一下，当查看启用Agent模式的prometheus二进制文件的帮助时，可以看到只能与Agent模式一起使用的选项写着“仅限于Agent模式使用”，而对于以前的模式（服务器模式），则写着“仅限于服务器模式使用”。由于Agent模式没有与查询或警报相关的功能，所以这些选项似乎仅适用于服务器模式。没有提及的标记可以在Agent和服务器的两种模式下使用。

我在一个适当的集群上大致比较了以Server模式和Agent模式运行时CPU和内存的消耗差异。它们几乎同时开始运行，并且放置了大约30分钟后得到以下结果。测量开始时的系列数为126493个，我认为在此期间它们可能没有发生很大变化。

代理模式相比服务器模式确实减少了资源消耗，尤其是内存消耗量减小了。虽然我没有调查过资源消耗量在时间序列数据等方面的差异如何产生，但至少在我的环境中，优化效果是明显的。

Prometheus的水平规模

如果想在不使用远程存储的情况下水平扩展Prometheus，可以通过例如在relabel_config中使用hashmod等方式来分散抓取目标，然后提供类似Promxy的多个Prometheus的全局视图，以实现水平扩展。但是，当要减少副本数时，可能会困惑于如何处理要删除的Prometheus的本地磁盘指标数据。在Agent模式下，不会引用本地磁盘的指标数据，因此将Prometheus视为无状态的应用程序，可以相对容易地实现水平扩展。（当然，即使不使用Agent模式，只需简单地不引用本地的TSDB，也是一样的）关于Prometheus的水平扩展，@watawuwu先生在其Prometheus水平分割数据的尝试中介绍了一些方法，您可能也可以参考。

最終

通过Prometheus的Agent模式，明显看到了远程写入的优化效果。
Grafana Agent作为Agent模式的基础，似乎有用于水平扩展的设置，可能实现将Agent分布到所有节点（尽管我没试过）。这样的功能也许会根据Grafana Agent的成熟度逐渐集成到Prometheus中。
此外，据说Prometheus Operator也在不断推进Agent模式的支持。
期待着Prometheus的进一步发展！

请参考

Why we created a Prometheus Agent mode from the Grafana Agent