此 PR 包含新增的属性，允许 Micrometer 导出到两个不同的 Dynatrace API。两个 Micrometer PR（见下文）中的代码依赖于此，并有望包含在 Micrometer 的 1.8.0 版本中。
决议 #24978
@pirgeo 感谢您的 PR，但我现在要关闭它，因为它不可行。我们无法查看代码，因为 Micrometer 中的更改尚未可用。当 micrometer 有包含此 PR 所需更改的版本时，我们显然可以重新考虑。
@snicoll 更改已合并到微米：https://github.com/micrometer-metrics/micrometer/pull/2619
鉴于有些配置属性是 v1 所特有的，有些是 v2 所特有的，我想知道我们是否应该为这些属性引入单独的组。两个版本的 API 共有的属性将保留在，management.metrics.export.dynatrace而 v1 特有的属性将移至management.metrics.export.dynatrace.v1，同样，v2 特有的属性将移至management.metrics.export.dynatrace.v2。WDYT，@snicoll？
我认为这是一个有趣的想法。也就是说，我们的流入支持存在同样的问题，我们目前的映射方式与 Micrometer 相同。我不知道是否有先例，我们的配置与相关的 Micrometer 的类有很大不同Config。
这会是一个重大改变吗？或者有没有办法在不破坏现有v1配置的情况下做到这一点？@jonatan-ivanov 您是否遇到过类似的情况并在此提供意见？
@pirgeo 在 Boot 方面，这取决于 Boot 团队想要如何处理这个问题。如果我们能为 Micrometer 提出一个值得一提的重大改变，那么这可以成为 2.x 的主题。正如 Stéphane 提到的，Influx 配置类似，其中 v1-v2 的处理方式与此 PR 类似，但我非常喜欢 Andy 的提议。
谢谢@jonatan-ivanov。我也认为这个提议很有意义。我们也希望将其作为一项非破坏性的附加更改引入。这将使我们能够提供与 Micrometer 1.x 兼容的版本，而不必等待 2.x 版本。@snicoll，@wilkinsona 您是否同意此 PR 中的当前提议？
我还将文档移到了新位置。由于此代码依赖于1.8.0-SNAPSHOTMicrometer 的构建，因此 CI 目前已中断。我们如何继续？
@snicoll @wilkinsona 您是否有必要在早期依赖 Micrometer 1.8.0，main以便能够合并 Boot 对 Micrometer 新功能的支持？
是的，我想是的。一旦我们确定了 Micrometer 1.8 里程碑的日期并且知道时间表一致，我们就可以这样做。
@wilkinsona 我们计划在 Boot 发布这些里程碑之前 8 天发布 M1/M2/M3/RC1/GA，例如：1.8.0-M1计划于 7 月 14 日发布，2.6.0-M1于 7 月 22 日发布。我们可以将其包括在内2.6.0-M1吗？
仅供参考：Micrometer 1.8.0-M1已于今日发布，向大家问好。:)
我已推送了一个分支，希望它能说明我的想法。方法是将 v1 和 v2 特定属性分别移至management.metrics.export.dynatrace.v1和之下management.metrics.export.dynatrace.v2。为了向后兼容，旧的 v1 特定属性仍保留management.metrics.export.dynatrace在弃用形式。
现在，不再为 API 版本设置属性，而是根据设备 ID 是否已设置进行推断。这种方法的缺点是，如果用户尝试使用 V1 API，如果他们忘记设置设备 ID，则不会收到错误消息。相反，系统将尝试使用 V2 API。这种方法的优点是 IDE 体验更好，因为自动完成功能会引导您找到正确的属性，并且不会出现将 API 版本设置为 v1 然后尝试配置特定于 v2 的属性的情况。
有什么想法吗？
嗨 @wilkinsona，感谢您的建议，这很棒。我们有一个小小的想法：是否可以分别将v1和重命名v2为和api-v1 ？api-v2/v1听起来v2像注册表版本，类似于@since可以混合功能的地方。当使用api-v1或api-v2时，更清楚的是我们的意思是 Dynatrace API 版本，这应该澄清只使用两者中的一个（默认情况下是最新版本），并且功能不能在版本之间混合。你怎么看？我已在此 PR 上启用“允许维护者修改”，因此如果您愿意，您应该能够将您的提交推送到开放分支，否则我可以接管它。在我们确定其中一个替代方案后，我会对文档进行一些收尾工作谢谢！
感谢您的关注，@pirgeo。我们不在配置属性前缀中使用连字符，因此我们尝试将.前缀的每个分隔部分保留为一个单词。我们可以使用apiv1andapiv2或v1apiandv2api但不能使用api-v1and 。就我个人而言，我更喜欢andapi-v2的简洁性，并且不会感到困惑，但您比我更了解您的用户群。对于vs ，我更喜欢前者，因为后者可以读作 apiv 1。v1v2v1apiapiv1
@wilkinsona 哦，我明白了。apiv1和apiv2确实看起来有点奇怪。让我们继续，v1然后v2我会更新文档，让每个阅读它的人都很清楚。你会把你的提交推送到这个分支，还是你想让我这么做？再次感谢你的支持！
add-dynatrace-v2-properties当我尝试推送到的分支时，GitHub 给出 403 错误。dynatrace-oss-contrib/spring-boot请随意将我的提交推送到该分支。
@wilkinsona 我已经推送了您的提交并完善了文档，现在从我们的角度来看它看起来不错。感谢您的帮助！我认为由于此分支指向 Micrometer 1.7.0（其中没有我们的更改），因此构建仍会中断。我们应该如何继续？
我可以处理。我会在合并之前重新设置基准，这样就可以升级到 1.8.0-M1。
@pirgeo 非常感谢您为 Spring Boot 做出的首次贡献。现已合并到main。
@wilkinsona 非常感谢！