使用 Dropwizard 跟踪指标的适当设计模式

Question

我正在研究 Dropwizard Metrics，我的目标是实时测量计数器和直方图，并将它们发送到 ElasticSearch 实例。

即使我发现在开发阶段很容易让它工作，我想知道是否有一种方法可以在项目增长时添加 Metrics 代码，同时保持干净。

在跟踪指标时是否有常用的设计模式？我的意思是，一个可以让我们保持我们的代码解耦，业务与指标的实现。

我一直在考虑的可能方法是：

A) AOP：干净，但在我的业务类中仍有一些代码。

B) HTTP 代理并将请求转发到特定的微服务/API，使用 Camel 或类似工具。也许太复杂了，我担心这会增加延迟。

谢谢！

Answer 1

这是一个相当令人困惑的问题。但我会试试看：

从它的声音。你正在以一种奇怪的方式做事。 Metrics 已经有它自己的最佳实践，并且由于您正在衡量业务逻辑，如果您想详细了解它，我不明白您如何不能将代码放入您的业务类中。例如，无论如何，您总是需要将其提交给您的指标，如下所示：

try (Context time = metrics.timer(SEND_TIME).time()) {
     // do some business operations and send something 
}

因此，您“可能”绕过它的唯一方法是使用拦截器。他们只会将您的业务方法调用包装到一个指标中，仅此而已。我相信，使用 guice，你可以拦截你所做的每一个方法调用，所以基本上记录了一切。

这当然会让你失去细节。您只能衡量方法，而不能衡量方法中的内容。当然，现在您可以将所有方法拆分为更小的方法并记录更多细节——但这真的能让您的代码更干净吗？

在我看来，指标的典型用途是拥有 1 个保存所有指标的注册表，然后将该注册表注入到要使用指标测量的类中。我认为这种方法很好。

问题与报告有关。您想实时执行此操作吗？这意味着，您希望每个指标都向您的 ES 实例提交请求，以索引您刚刚测量的任何内容。

这种方法有两个问题：

1. 如果您对您衡量的每一个指标都提出请求，您就会终止您的应用程序。您可以使这些请求异步，但由于您不想丢失任何东西，您仍然需要担心中断、DOS、重试等等等。您将忙于跨线程跟踪您的指标，您不会的首先，您没有任何剩余时间来执行您要测量的逻辑。这听起来是个非常糟糕的主意。

2. 您可以使用记者。它们异步工作，它们做的不多，它们不占用资源等。但是现在你不再是实时的了。记者通常每分钟左右运行一次，因此您会有延迟。是的，你可以每 10 秒、每 1 秒等运行你的记者——你总是不是实时的。一旦你变得足够小，取决于你的实现，你将再次遇到问题 1，你的所有应用程序都在尝试与弹性搜索对话。

如果您需要记者：https://github.com/elastic/elasticsearch-metrics-reporter-java

所以本质上，我对你的方法有点困惑，但话说回来，我从来没有真正需要做实时报告。

我们使用近乎实时的报告，这意味着我们最多延迟 1 分钟，这对我们和我们的客户来说都很好。这是我们可以在不影响应用程序性能的情况下将数据从应用程序转移到报告主机的频率。

我读到您可以使用 ES 客户端 impl，它直接与集群对话，而不是使用 http 请求来索引您的数据。这可能会给你更多的表现，但我相信 1 和 2 仍然成立。

希望对你有帮助

阿图尔