3
Spring Boot Admin 从指标端点（例如process.uptime）获取各种时间计量器。不幸的是，执行器输出中没有给出时间单位，并且时间单位可能会根据底层千分尺注册表而变化。因此，如果时间单位固定在指标端点中或包含在输出中，那就太好了。目前时间单位只能猜测。
Q
[spring-projects/spring-boot]在指标端点的输出中包含计量表 ID 的基本单位和描述
A
回答
6
/抄送@jkschneider
8
对我来说这看起来像是一个微米错误。两者都Statistic.TOTAL_TIME表示Statistic.DURATION它们“总是以纳秒为单位报告”。Statistic.MAX当它代表一个时间时也有同样的说法。MetricsEndpoint句柄Measurements是一个Statistic和 值对。对于TOTAL_TIME、DURATION或MAX统计量的测量，我希望该值始终以纳秒为单位，无论MeterRegistry返回Meter.
@joshiste 你能打开一个千分尺问题吗？我现在将关闭此窗口，但如果毕竟需要在启动中进行更改，我们可以重新打开它。
7
@wilkinsona javadocs 是错误的，已被更改。我想我之前已经提到过，如果 Spring Boot Admin 不依赖于指标端点会更好。我认为它应该提供一个仪表注册表实现，以一种特有的方式公开指标。
如果我们标准化指标端点中的基本时间单位，有人会抱怨这些值与他们在监控系统中看到的值不同。如果我们与监控系统（我们正在做的事情）保持一致，有人会抱怨实施情况的不一致。这是一种双输的情况，凸显了这样一个事实：指标端点只是一个诊断工具。
2
@jkschneider
我认为它应该提供一个仪表注册表实现，以一种特有的方式公开指标。
我们尝试支持 Spring Boot 应用程序，而无需用户对其进行修改。
如果我们标准化指标端点中的基本时间单位，...
同意。另一个选项怎么样：在端点的输出中包含仪表的基本时间单位？这样我们就不会与其他实现不一致，并且 SBA 可以重新计算。 （顺便说一句：在端点中也有仪表的描述会很棒）
@wilkinsona 你能重新打开这个问题吗？
5
谢谢，@jkschneider。
即使它只是一个诊断工具，并且暂时将 Spring Boot Admin 放在一边，我也可以在端点中看到一些值，这些值公开了底层注册表的基本时间单位。您认为值得公开，getBaseTimeUnit()以便MeterRegistry我们可以将该信息包含在端点的响应中吗？
0
@wilkinsona 你能重新打开这个问题吗？
如果/当我们同意需要进行更改时，我们可以重新打开它。现在，Boot 束手无策，因为 Micrometer 不公开注册表的基本时间单位。
4
@wilkinsona 恕我直言，我们不应该获得 MeterRegistry 的基本时间单位，而是获得仪表的基本时间单位，Meter.getId().getBaseUnit()以防它与注册表的不同。
3
@wilkinsona 更新了我的最后一条评论...Meter.getId().getBaseUnit()不在包范围内。所以现在就有可能。如果您需要的话，我可以提供 PR。
1
无论如何，添加描述文本和基本单元都是对指标端点的有用增强，如果这有助于 Spring Boot Admin 缩放值，那么我认为这是一个可行的解决方案。
好建议@joshiste！
6
@jkschneider 我们可以使用仪表 ID 中的基本单位吗？从更新的 javadoc 来看，统计值将采用注册表的基本单位，而计量 ID 则没有做出这样的承诺。这让我认为我们需要的是注册表。无论如何，我更愿意处理TimeUnit注册表中的强类型而不是StringId 中的强类型，因为它将为端点客户端提供一组固定的可能值来处理。
6
@jkschneidermeter.getId().getBaseUnit()适用null于process.uptime.快速查看千分尺来源告诉我，它始终是null为了TimeGauge...所以这个问题仍然取决于千分尺的变化...
5
太好了，Github API 问题导致同一问题被打开 6 次。
1
TimeGaugeMicrometer 1.0.6 已解决该问题。
0
谢谢，乔恩。关于使用注册表的基本时间单位与 id 的基本时间单位有什么想法吗？
0
IMO 使用 ID。虽然它们应该始终与 Micrometer 提供的仪表类型上的注册表基本时间单位相匹配，但人们可以自由地对自定义仪表类型执行任何他们想要的操作。
1
再次感谢@jkschneider。
@joshiste 我认为我们已经拥有了实现这一目标所需的一切。拉请求将不胜感激。
3
结束有利于 PR #13813。