我应该将哪个StatsD客户端用于java/grails项目？

Question

我正在考虑将StatsD数据集添加到我的grails应用程序中,并查看现有的库和代码让我对什么是一个好的可扩展解决方案感到困惑.为了将问题放到上下文中,我正在开发一个在线游戏类型项目,我自然会监控用户与游戏引擎的交互,这些将自然地聚集在X用户将在窗口内执行交互的特定时刻一两秒,然后在10-20秒暂停后重复.

以下是我对今天可用选项的分析.

Etsy StatsD客户端示例

https://github.com/etsy/statsd/blob/master/examples/StatsdClient.java

"可能最简单的工作"解决方案,我可以将这个类拉入我的项目并将一个单例实例作为一个spring bean实例化并直接使用它.但是在注意到grails-statsd插件创建了一个客户端实例池后,我开始想知道这种方法的可扩展性.

如果许多线程试图同时发送事件,似乎该doSend方法可能成为瓶颈,但据我所知,由于发送UDP数据包的火灾和遗忘性质,这应该很快发生,避免了巨大的开销我们通常与网络连接相关联.

grails-statsd插件

https://github.com/charliek/grails-statsd/

有人已经为grails创建了一个StatsD插件,其中包含一些很好的功能,例如注释和withTimer方法.但是我看到那里的实现缺少示例实现中的一些错误修复,例如在调用时指定语言环境String.format.当标准的Executor可以达到类似的效果时,我也不是为了吸引apache commons-pool的狂热粉丝.

Java的statsd客户端

https://github.com/tim-group/java-statsd-client/

这是一个替代的纯Java库,它通过维护自己的ExecutorService来异步操作.它支持整个StatsD API,包括集合和抽样,但不提供任何用于配置线程池和队列大小的挂钩.在出现问题的情况下,对于非关键的事情,例如监控,我认为我更喜欢有限的队列并且丢失事件而不是拥有填满我的堆的无限队列.

播放statsd插件

https://github.com/vznet/play-statsd/

现在我不能直接在我的grails项目中使用这个代码,但我认为值得一看,看看事情是如何实现的.一般来说,我喜欢编写代码的方式StatsdClient.scala,非常干净和可读.似乎也有区域设置错误,但其他功能完整与etsy示例.有趣的是,除非有一些我不理解的scala魔法,否则这似乎会为发送到StatsD的每个数据点创建一个新的套接字.虽然这种方法很好地避免了对象池或执行程序线程的必要性,但我无法想象它的效率非常高,可能会在请求线程中执行DNS查找,这应该尽快返回给用户.

问题

1. 从所有其他实现似乎已经实现了另一种处理并发策略的事实来看,我可以假设Etsy示例对于生产使用有点太天真了吗？
2. 我的分析在这里看起来是否正确？
3. 在java/groovy中使用statsd的其他人有哪些？

到目前为止,看起来最好的现有解决方案是grails插件,只要我能接受公共池依赖,但是现在我正在认真考虑在周日编写我自己的版本,它结合了每个实现的最佳部分.

Answer 1

作为java-statsd-client的主要提交者,以及在生产中使用此库的人,我想尝试消除你对"拥有一个填满我的堆的无限队列"的恐惧.

当你说"由于火灾并忘记发送UDP数据包的性质时,我认为你几乎已经对你的Etsy StatsD客户端示例进行了分析,这应该很快发生,避免了我们通常与网络连接相关的巨大开销."

我的理解是,当前实现java-statsd-client的方式,构建大型出站消息队列的约束是发送消息而忘记UDP数据包的速度.我不是这方面的专家,但我不知道这可能阻止无限队列可能会积累的任何方式.

当您最初进行评估时,java-statsd-client存在许多未解决的问题(例如,区域设置/字符编码模糊以及缺乏采样支持),但最近已经解决了这些问题.剩下的问题是是否存在填补堆的真正风险.我希望能听到社群关于这个问题的想法,如果共识是存在问题,我很乐意探讨在库中引入限制队列.

Answer 2

经过一周的思考后，我想我将继续使用现有的 grails StatsD 插件。这样做的理由是，虽然我可以使用执行器处理并发来实现类似的效果，但如果不使用对象池，这仍然会绑定到单个客户端/套接字实例，理论上这是应用程序中相当明显的瓶颈。因此，如果我无论如何都需要一个游泳池，我也可以使用一个其他人已经完成了所有艰苦工作的游泳池:)