java - Codahale 指标 : using @Timed metrics annotation in plain Java

Question

我正在尝试使用 codahale 指标将指标添加到普通 Java 应用程序。我想使用 @Timed 注释，但我不清楚它使用哪个 MetricRegistry，或者如何告诉它使用哪个 MetricRegistry。该应用程序是一个普通的 Java 8 应用程序，使用 Maven 3 构建，没有 Spring，没有 Hibernate。

我在 dropwizard 文档中找不到任何关于如何实现 @Timed 的文档:https://dropwizard.github.io/metrics/3.1.0/manual/

我已经添加了这些依赖项:

<dependency>
  <groupId>io.dropwizard.metrics</groupId>
  <artifactId>metrics-core</artifactId>
  <version>3.1.0</version>
</dependency>
<dependency>
  <groupId>com.codahale.metrics</groupId>
  <artifactId>metrics-annotation</artifactId>
  <version>3.0.2</version>
</dependency>

当我使用对 Timer 的编程调用时，我可以获得报告，因为我知道使用了哪个 MetricsRegistry:

static final MetricRegistry metrics = new MetricRegistry();
private void update() throws SQLException {
  Timer.Context time = metrics.timer("domainobject.update").time();
  try {
    [...]
  } finally {
    time.stop();
  }
}

但是当我使用更优雅的 @Timed 注释时，我不知道使用了哪个注册表，因此我无法创建报告器，这意味着我无法获得报告的指标(我什至不确定是否这实际上做任何事情):

@Timed(name = "domainobject.update")
private void update() throws SQLException {
    [...]
}

请告知如何使 @Timed 和其他 Metrics 注释在常规 Java 应用程序中工作。

附加信息: 我觉得这很奇怪的原因是我添加了 Lombok 框架并且 @Slf4j 注释确实有效。我在 maven pom.xml 中添加了 Lombok 作为依赖项:

<dependency>
  <groupId>org.projectlombok</groupId>
  <artifactId>lombok</artifactId>
  <version>1.14.8</version>
</dependency>

而且我可以使用@Sl4fj 类注解在类中添加一个记录器，而不会弄乱成员变量:

@Slf4j
public class App {
  public void logsome(){
    log.info("Hello there");
  }
}

因此，如果仅通过添加依赖项就可以做到这一点，我认为我只是缺少一个依赖项或配置来使 codahale @Timed 注释正常工作，如上所述。

(顺便看看 Lombok ，它会让你的生活更轻松:http://projectlombok.org/)

Answer 1

长话短说，你不能在没有某种 AOP(无论是 Spring AOP 还是 AspectJ)的情况下使用 @Timed。

一两周前，我还决定为我们的项目添加指标，并为此任务选择了 AspectJ(主要是因为我过去将它用于类似目的，并且因为它允许编译时编织，而 Spring 只允许运行时通过代理)。

您应该能够在此处找到所有必要的信息和说明:https://github.com/astefanutti/metrics-aspectj .

至于 Lombok，我猜他们使用内置 javac 注释处理器:

Another point of contention is the implementation of both the code supporting IDE integration as well as the javac annotation processor. Both of these pieces of Project Lombok make use of non-public APIs to accomplish their sorcery. This means that there is a risk that Project Lombok will be broken with subsequent IDE or JDK releases.