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

时间:2016-04-06 12:13:52

标签: java design-patterns dropwizard metrics code-cleanup

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

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

跟踪指标时是否有常用的设计模式?我的意思是,一个实现可以让我们保持我们的代码与业务量指标脱钩。

我一直在考虑的方法是:

A)AOP:干净,但我的商务课程中仍然有一些代码。

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

谢谢!

1 个答案:

答案 0 :(得分:0)

这是一个相当令人困惑的问题。但我会尝试一下:

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

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

所以,你可能“绕过它”的唯一方法就是使用拦截器。他们只是将您的业务方法调用包装成一个指标,就是这样。我相信,使用guice,你可以拦截你所做的每一个方法调用,所以基本上记录一切。

这当然会让你失去细节。您只能测量方法,而不能测量方法中的方法。当然,现在您可以用更小的方法拆分所有方法并记录更多细节 - 但这是否真的能让您的代码更清晰?

我看到,度量标准的典型用法是拥有一个包含所有指标的注册表,并将该注册表注入要使用指标进行衡量的类中。我认为这种方法很好。

问题出在报道上。你想实时做到这一点?这意味着,您希望每个指标都向ES实例提交一个请求,以索引您刚刚测量的内容。

这种方法有两个问题:

  1. 如果您对所测量的每个指标发出请求,则会终止您的应用程序。您可以使这些请求异步,但由于您不想丢失任何内容,您仍然需要担心停机,DOS,重试等等。您将忙于跨越线程跟踪您的指标,您赢了'你还有什么可以做你想要测量的逻辑。这听起来像个坏主意。

  2. 你可以使用记者。它们异步工作,它们没有做太多,它们没有耗尽资源等。但现在你不再是实时的了。记者通常每分钟都会跑一次,所以你会有这种延迟。是的,你可以每10秒钟,每1秒钟运行一次你的记者等等 - 你永远不会是实时的。一旦你变得足够小,根据你的实现,你将再次遇到问题1,你的所有应用程序都在尝试与弹性搜索交谈。

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

    基本上,我对你的方法感到有些困惑,但我再也没有真正做过实时报道。

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

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

    我希望有所帮助,

    阿图尔