3
当 AspectJ 位于类路径上时，这增加了对自动配置的支持ObservedAspect，从而可以使用@Observed.
3.1 是否有可能考虑这一点？我知道 RC1 上周已经上市了，但这是一个影响很小的变化，IMO 为用户提供了很好的便利。
/抄送@jonatan-ivanov
Q
[spring-projects/spring-boot]为 ObservedAspect 添加自动配置
A
回答
6
谢谢，@vpavic。
我认为我们不应该急于解决这个问题。TimedAspect这与我们不自动配置有一些相似之处。我记得这是有充分理由的，但对问题跟踪器的搜索并没有发现太多可以刷新我记忆的东西。这可能与相位和WebMvcMetricsFilter所寻找的相位之间可能存在的冲突有关@Timed。
9
谢谢你的公关！
我对此百感交集：一方面，如果这可以开箱即用（也@Timed可以），那就太好了。@Counted另一方面（这些可能不是那么大的问题），我想这有一个很小的开销，也许用户不想配置 Micrometer 的各个方面，但他们希望对注释做出不同的反应（在这种情况下，他们可以创建自己的注释）。
Andy 的观点是：@Timed由于过滤器，Boot 2.x 中存在冲突AutoTimer：如果您添加了@Timed一个控制器方法并且还配置了一个方面，那么您最终会得到两个计时器。 3.x 的情况并非如此，我不知道如果我们这样做会遇到什么问题（如果我们想这样做，也许我们还应该引入一个启用标志）。
2
这个 PR 背后的动机是，根据我的经验，为了获得基于 Micrometer 的应用程序范围的可观察性，@Observed除了最琐碎的应用程序之外，基本上所有应用程序都必须使用 Micrometer。随着框架为其功能添加可观察性支持，情况将会有所改善，这些功能可用于构建某种端点（或更一般地说，某些处理流程的入口点），但实际应用程序仍然会有一些@Observed.
我从未使用过@Timed，@Counted所以我无法谈论您所表达的担忧，但对我来说，感觉这些与可观察性有点不同，可观察性是 Spring 最近版本中的一个主要主题，老实说，这是很多样板工作需要从一个项目到另一个项目重复。
7
我同意现实世界的应用程序仍然会有一些用例，@Observed即使我们对所有事情都有仪器，仍然存在业务逻辑。
6
如果我们决定继续推进这一点，我们是否还可以涵盖TimedAspect,CountedAspect和SpanAspect这里？请参阅：https://github.com/spring-projects/spring-boot/issues/36001
9
@jonatan-ivanov 我不清楚你的问题是针对谁的 - 是 Spring Boot 团队（的某人），还是你要求我更新 PR 并添加你提到的 bean 注册？
8
@vpavic 这个问题是针对参与此 PR（或将参与）的每个人的。你肯定被包括在内，如果我们决定继续这些，你愿意添加其他方面吗？
9
如果团队决定这样做，并且这有助于推动事情向前发展，那么就不用担心更新 PR。
8
嘿@vpavic，我们今天讨论了这个问题，因为这不是一个有风险的改变，而且会是一个很好的补充，所以如果可能的话，我们希望将其包含在内3.2.0-M1。您愿意更新 PR 并添加对、TimedAspect的支持吗？CountedAspectSpanAspect
9
当然，我会在接下来的几天更新。
7
我今天考虑更新此 PR，但自动配置其他方面并不像ObservedAspect.我也不确定这些是否真的应该成为同一提交/PR 的一部分，因为它们来自不同的 Micrometer 模块：
ObservedAspect是一部分micrometer-observationSpanAspect是一部分micrometer-tracingCountedAspect并且TimedAspect是的一部分micrometer-core
因此，他们似乎针对不同的自动配置：
ObservedAspect适合ObservationAutoConfiguration（如本 PR 所提议）SpanAspect看起来它应该适合MicrometerTracingAutoConfiguration，但根据Micrometer 文档，该方面取决于其他几个组件，我不确定真正需要在那里自动配置什么 - 另外（有趣的是）文档将这一方面描述为孵化- 我不确定在哪里
CountedAspect应该TimedAspect自动配置，但看起来它们不适合ObservationAutoConfiguration或MicrometerTracingAutoConfiguration
0
我认为CountedAspect并且TimedAspect应该在我们自动配置的位置“旁边” MeterRegistry，我会把它放进去，MetricsAutoConfiguration但它似乎正在配置注册表之前我们需要的所有东西，所以我想为此创建一个新类是有意义的，例如：MetricsAspectsAutoConfiguration.你怎么认为？
关于SpanAspect，我只是更深入地研究了它，我刚刚意识到我们的ValueResolver实现总是返回 null，这可能不是自动配置的最佳选择。我认为“孵化”标签可以通过 Micrometer Tracing 1.2.0 解决，但让我问 Marcin：@marcingrzejszczak 你想SpanAspect在 Micrometer Tracing 1.2.0 中保持稳定吗（现在文档说正在孵化）？如果是这样，我们应该为其添加自动配置，我们是否应该添加一个默认值ValueResolver来String.valueOf代替自动配置NoOpValueResolver？
1
正如https://github.com/spring-projects/spring-boot/pull/35191#issuecomment-1527906036中提到的，我没有经验@Timed，@Counted所以我真的对如何构建自动没有意见相关方面的配置。
从你的评论来看，似乎还有更多的问号SpanAspect。
这个 PR 的开放纯粹是为了可观察性，我认为团队承认了这一点，将其作为可观察性主题的一部分（https://github.com/spring-projects/spring-boot/issues/35776），但是看过之后在我看来，在配置这些附加方面时，重点现在正在转移到涵盖 Micrometer 提供的所有方面（这是一个比可观察性更广泛的问题）。
按原样继续此 PR，并为CountedAspect/TimedAspect和单独提出问题SpanAspect（该问题甚至似乎被阻止）是否有任何问题，可能会给社区中的其他人提供贡献这些问题的机会？
0
@marcingrzejszczak 你想让 SpanAspect 在 Micrometer Tracing 1.2.0 中保持稳定吗（现在文档说正在孵化）？
我认为这是文档中的一个错误。这不是一个孵化阶段——它是稳定的。
如果是这样，我们应该为其添加自动配置，我们是否应该添加一个默认的 ValueResolver 来执行 String.valueOf 而不是自动配置 NoOpValueResolver ？
当然，为什么不呢，有道理。