在将组件更新到最新的2.5.12Spring boot 版本时，我们遇到了一个问题。从版本2.5.3到新版本和安全版本的“简单”小更新包含prometheus 客户端版本2.5.12中隐藏的重大更改，强制所有计数器现在都带有后缀。我们的第一种方法是尝试强制使用我们之前使用过的版本，没有问题，但现在，spring boot 执行器使用的方法仅在之后可用，因此不再可能使用旧版本的客户端。0.10.0_total0.9.00.10.0
已经有用户抱怨 prometheus 客户端问题 640存在同样的问题。问题是，目前，一些应用程序不受 Spring4Shell 漏洞的影响，但在不久的将来，可能会出现新的漏洞，甚至是 Spring4Shell 的扩展，表明其对其他类型的 Spring Boot 应用程序有效，许多人将面临此问题，并且无法更新以修复严重的安全问题。
我不太明白：Spring Boot 2.5.3 使用 Prometheus 0.10.0，就像 Spring Boot 2.5.12 一样。它们是同一个版本。更新已在 #27349 和 #25250 中完成。
从 Boot 2.5.3 到 2.5.12，与 prometheus 相关的唯一变化是
io.micrometer:micrometer-registry-prometheus:jar:1.7.2对比io.micrometer:micrometer-registry-prometheus:jar:1.7.10
Spring Boot 2.4.x 使用 prometheus 0.9.0，因此从 Boot 2.4.x 到 Boot 2.5.x 进行了重大更改。
您可以使用 CVE 缓解措施，仅更新spring-framework到固定版本并保留 2.5.3。详情请见此处。更好的方法是将使用它们的地方的度量名称修复为“新”prometheus 格式，然后使用最新的 Spring Boot 2.5.x（甚至 2.6.x）
问题是在 2.5.3 和 2.5.12 之间，不完全确定在哪里做出了改变，它开始使用org.springframework.boot.actuate.metrics.export.prometheus.TextOutputFormat.CONTENT_TYPE_OPENMETRICS_100
而不是org.springframework.boot.actuate.metrics.export.prometheus.TextOutputFormat.CONTENT_TYPE_004。
有没有办法覆盖默认设置？我一定会研究缓解措施，谢谢
啊，所以变化不是版本升级，而是 TextOutputFormat 的某个部分发生了变化。我会看看的。
该格式源自其出现的org.springframework.boot.actuate.metrics.export.prometheus.PrometheusScrapeEndpoint.scrape
版本，但对于它而言，它可能是一种更高级的东西。2.5.3CONTENT_TYPE_0042.4.12CONTENT_TYPE_OPENMETRICS_100
在两种情况下，发出请求的 Prometheus 服务器是相同的
我完全可以观察到 2.4.x、2.5.3 和 2.5.12 之间的计数器名称没有任何区别。您有可以重现此情况的样本吗？
2.4.13
# HELP foo_total
# TYPE foo_total counter
foo_total 1.0
2.5.3
# HELP foo_total
# TYPE foo_total counter
foo_total 1.0
2.5.12
# HELP foo_total
# TYPE foo_total counter
foo_total 1.0CONTENT_TYPE_OPENMETRICS_100仅当客户端（本例中为 Prometheus 服务器）可以接受时才应提供。除了示例之外，了解AcceptPrometheus 服务器发送的标头以及原因（假设它表明这是CONTENT_TYPE_OPENMETRICS_100可以接受的）接收该格式的内容是有问题的，这也是很有用的。
在#28130中，发生了变化。
发送时Accept: application/openmetrics-text; version=0.0.1,text/plain;version=0.0.4;q=0.5,*/*;q=0.1
Spring boot 2.5.3 回答
HTTP/1.1 200
Content-Type: text/plain;version=0.0.4;charset=utf-8
Content-Length: 7570
Date: Fri, 08 Apr 2022 12:49:42 GMT
# HELP bar_total
# TYPE bar_total counter
bar_total 2.0而 2.5.12 回答
HTTP/1.1 200
Content-Type: application/openmetrics-text;version=1.0.0;charset=utf-8
Content-Length: 7469
Date: Fri, 08 Apr 2022 12:50:21 GMT
# TYPE bar counter
# HELP bar
bar_total 2.0谢谢，莫里茨。这种行为与 Prometheus 自己的TextFormat类一致，所以我认为我们不应该改变它。@nandoFromSky 我认为我们真的需要知道你的服务器发送了什么接受标头，以及为什么结果响应是一个问题，才能在这方面取得进展。
@mhalbritter 可能是这样，我会调查我们的 prometheus 服务器在做什么，如果是这样，那么在我们尝试迁移指标以_total在所有系统中使用时，这应该是一个简单的解决方法
据我所知，Prometheus 不允许我们定义标头。但是，我们始终可以覆盖PrometheusScrapeEndpoint并TextOutputFormat强制使用TextFormat.write004。
这样我们仍然可以使用0.9.0prometheus客户端来避免_total并保持一切正常运行。
仍需要运行一些其他测试来查看是否有任何影响，但看起来它应该有效
谢谢，@nandoFromSky。我现在就关闭这个。如果它没有按预期工作，请告诉我们，我们可以再看看。
你好 @nandoFromSky 和 @wilkinsona，你们是否知道解决后缀的推荐方法_total？
据我所知，您应该能够发送不同的接受标头以不同格式获取指标。