使用 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 实例提交请求，以索引您刚刚测量的任何内容。

这种方法有两个问题：

如果您对测量的每一个指标都提出请求，那么您的应用程序就会被终止。 您可以使这些请求异步，但由于您不想丢失任何内容，您仍然需要担心中断、DOS、重试等等等。您将忙于跨越线程跟踪您的指标，您不会没有任何余地去做你想要衡量的逻辑。 这听起来是个很糟糕的主意。
你可以用一个记者。 它们异步工作，它们没有做太多事情，它们不会消耗资源等等。但是现在你不再是实时的了。 记者通常每分钟运行一次，所以你会有延迟。 是的，你可以每 10 秒、每 1 秒等等运行你的记者——你永远不是实时的。 一旦你变得足够小，取决于你的实现，你将再次遇到问题 1，你的应用程序所做的就是尝试与弹性搜索对话。

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

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

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

我希望有帮助，

阿图尔