应用设计模式以使用 Dropwizard 跟踪指标

Question

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

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

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

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

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

B) HTTP 代理并将请求转发到特定 microservice/API，使用 Camel 或类似工具。也许太复杂了，恐怕会增加延迟。

谢谢！

Answer 1

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

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

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

因此，您 "maybe" 绕过它的唯一方法是使用拦截器。他们只会将您的业务方法调用包装到一个指标中，仅此而已。我相信，使用 guice，您可以拦截您进行的每个方法调用，因此基本上可以记录所有内容。

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

在我看来，指标的典型用途是拥有 1 个包含所有指标的注册表，然后将该注册表注入要使用指标衡量的 classes。我认为这种方法很好。

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

该方法有 2 个问题：

如果您对测量的每一个指标都发出请求，您的应用程序就会终止。你可以使这些请求异步，但由于你不想丢失任何东西，你仍然需要担心中断、DOS、重试等等。你会忙于跨越线程跟踪你的指标，你不会一开始就没有什么可以做你想衡量的逻辑了。这听起来像是一个非常糟糕的主意。
你可以使用记者。他们异步工作，他们做的不多，他们不耗尽资源等。但现在你不再是实时的了。记者通常每分钟运行左右，所以你会有这样的延迟。是的，你可以每 10 秒、每 1 秒等运行你的记者——你将永远不是实时的。一旦你变得足够小，根据你的实现，你将再次遇到问题 1，你的所有应用程序都试图与弹性搜索对话。

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

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

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

希望对您有所帮助，

阿图尔

Appropiate Design Pattern to track metrics with Dropwizard