2
Q
[spring-projects/spring-boot]自动配置 Micrometer 的 HumioMeterRegistry
A
回答
9
Map<String, String>具有默认值的属性为配置属性元数据带来了一个有趣的场景。我打开了https://github.com/spring-projects/spring-boot/issues/14813看看我们能做些什么。
5
正如我在该问题中指出的，如果有标准标签，我希望看到一个列出了这些标签的专用结构以及其他标签的地图。希望其中没有默认密钥。
5
AFAIK，没有标准标签。它们只是任意的键值对。我想知道如果没有默认值并且我们要求用户指定一个或多个标签，实际上是否会更好。
1
IMO 具有默认值的原始地图是一种味道，所以我同意我们应该在添加它之前做一些事情。
4
用户甚至不需要这样做，因为 Humio 将接受没有标签的事件。我不确定默认#name=micrometer标签是否会增加很多价值，因此，鉴于不需要标签，我认为我们应该清除默认标签。这对我来说似乎很合理，特别是考虑到我们sandbox默认使用存储库。
WDYT，@jkschneider？可以在 Micrometer 中更改标签的默认值吗？
9
需要保留默认值。 Humio 中的标签与其他监控系统中的标签含义不同。我们典型的标签概念映射到 Humio 中的属性。 Humio 中的标签用于唯一标识将添加所有指标的数据源。
它们粗略地表明，每个组织的数据源不应超过几个，而不会给我们带来硬性限制。添加单个键/值对标识符可以使所有 Micrometer 指标流向一个数据源，至少将它们与基于日志的摄取等区分开来。
我愿意接受建议，但在这种情况下，合约实际上是用于唯一标识数据源的任意一组键值对，并且应该标识数据源。
7
例如，这是一个 Humio 查询：
#name = "micrometer"
| name = http_server_requests
| eval(avg=sum/count)
| timechart(uri, function=[max(avg)])#name = "micrometer"选择数据源name = http_server_requests选择指标
如果没有默认的“标签”，就无法选择数据源。
4
谢谢，乔恩。我已经了解 Humio 中标签的用途。我仍然不太明白当前的默认设置以及我们是否认为它能满足大多数人的目的。
#name=micrometer感觉就像泄露了有关摄取事件来源的实现细节。因此，我想这是很多人都想要改变的。但这只不过是一种预感。无论哪种方式，对于那些确实想要配置自己的标签的人来说，事情变得更加复杂，因为必须了解通过属性或 yaml 配置的任何标签是否会添加或替换默认值。
如果我们认为需要至少配置一个标签，那么默认值是否可以不是一个空映射，然后在没有配置标签的情况下在启动时快速失败？这将引导用户朝着正确的方向前进，避免在替换或添加默认值时产生混淆，并且还可以处理用户提供HumioConfig没有标签的自定义的情况。
7
在之前的实验中，我观察到 Humio 会根据存储库的名称自动添加标签，因此即使应用程序端没有配置标签，也应该可以选择数据源。
5
通过环境配置的任何标签都将添加到默认值。这意味着您必须诉诸编程配置来摆脱名称标签。您在属性中可以做的最好的事情就是指定一个空值。
在启动上下文中，默认标签对我来说就像是不可能的。我们需要找出最好的替代方案。
6
理解，但是所有指标源都将数据转储到给定存储库中的同一数据源中，这感觉有点不对劲。
通过环境配置的任何标签都将添加到默认值。
我不明白为什么会这样。根据 的语义，如果根本没有设置，PropertiesConfigAdapter#get我们不是只使用默认映射吗？management.metrics.export.humio.tags
7
@wilkinsona这是一个测试，似乎证明了我的怀疑。
7
理解，但是所有指标源都将数据转储到给定存储库中的同一数据源中，这感觉有点不对劲。
我们还使用沙箱存储库，这对于任何严肃的使用来说也可能有点错误。但这似乎是一个合理的默认值。我认为没有标签或要求用户配置标签同样合理。
如果根本没有设置management.metrics.export.humio.tags，我们不是只使用默认地图吗？
事实并非如此。具有单个条目的默认映射位于HumioProperties（将其默认值与 对齐HumioConfig）。它由任何management.export.humio.tags.*属性添加到其中。也许我们可以做一些不同的事情，以便仅在没有配置其他标签时使用默认值，但这与所有其他配置属性的工作方式不一致。这是我们需要避免的混乱根源。
1
具有单个条目的默认映射位于 HumioProperties 中（以使其默认值与 HumioConfig 保持一致）。
我们可以简单地将这个默认地图放入吗HumioProperties？这似乎满足了所有的担忧。我认为无论如何我们都没有在 Spring Boot 中向配置 props 类普遍添加默认值，但只有在通过自动完成增强用户体验的情况下才会这样做？
2
不幸的是没有。除了默认的标签之外，它给我们留下了所有的担忧。剩下的问题是：
- 它有一个默认值，未反映在元数据中
- 与任何其他地图属性不同，一旦配置另一个条目，其默认值就会丢失
为了与 Boot 的其余部分保持一致，除了默认没有标签之外，我看不到其他方法。这意味着元数据是准确的，并且在配置另一个条目时不会出现默认条目丢失的异常行为。
假设没有其他方法，这就变成了一个问题：我们是否应该要求用户配置至少一个标签（如果不配置，很快就会失败），或者无论如何导出并依赖隐式标签。我想我倾向于后者。
5
我认为无论如何我们都没有在 Spring Boot 中向配置 props 类普遍添加默认值，但只有在通过自动完成增强用户体验的情况下才会这样做？
正因为如此，默认值（几乎）总是有用的。我说的几乎是由于默认情况下带有内容的地图属性的问题在这里引起了注意。除此之外，我们尝试在属性中使用默认值，并使用测试来使它们与所配置的任何内容保持同步。
1
好吧，我想我没有太多选择了。HumioConfig如果地图为空或为空，我将删除默认值并有条件地根本不发送标签。
我其实不太高兴。我确实认为，配置另一个默认条目时丢失默认条目的异常行为可以最好地保护用户，但与 Spring Boot 的集成比这种对可用性的小小的认可更重要。
0
2
我其实不太高兴。
这不好。
我确实认为配置另一个默认条目时丢失默认条目的异常行为可以最好地保护用户
也许有更好的中间立场。我想知道是否应该要求用户配置一个或多个标签？这将保护它们，同时保持一致的配置行为。它与其他具有一些强制配置的注册表没有太大区别。
2
难道我们不能tags在一个对象中提取该属性吗name String？该对象的属性默认为，然后为其他标签为micrometer空？Map这就是我之前提到的“已知标签”。这允许明确记录一些众所周知的标签，如果 Micrometer 决定它们应该有一个默认值，那么我们也可以记录它。
当然，这意味着“非 Spring Boot 端”的代码需要合并传入的映射，以使思想一致。
2
不，我不这么认为。没有要求有一个名为的标签name，而且很多人不会想要这样的标签。换句话说，不存在众所周知的标签，您对标签的称呼完全取决于个人喜好、组织惯例等。
8
如果没有默认的“标签”，就无法选择数据源。
在之前的实验中，我观察到 Humio 会根据存储库的名称自动添加标签，因此即使应用程序端没有配置标签，也应该可以选择数据源。
正确的。当查询中未给出标签过滤器时，Humio 将搜索所有标签。
虽然，话是这么说。事实证明，Humio 摄取 api 实际上支持空对象 ( {}) 或null标签。因此，在自动配置器中，我们可以轻松默认，null而不会造成任何损害。
7
因此，在自动配置器中，我们可以轻松地默认为 null，而不会造成任何损害。
这实际上就是我们使用 micrometer-metrics/micrometer@1d2326f 所做的事情
7
@jkschneider 太棒了。尽管空支票不是必需的。{"tags": {}, "events": …}、{"tags": null, "events": …}、 和都是{"events": …}允许的。
6
谢谢@mwl。我可以发送最简单的 JSON 形式的{"events": …}.
5
不知道你已经走了多远，但我已经走了这么远https://github.com/spring-projects/spring-boot/compare/master...mwl:master
2
谢谢你的提议，@mwl，但我已经有了这个。如果您对我所做的更改感兴趣，请查看https://github.com/spring-projects/spring-boot/commit/1e2d5a1382897277a0161b16984c4e705327e8d8。
8
谢谢@wilkinsona。完成后我了解到您也在进行自动配置。反正。看来我们对如何完成这件事非常同意？