statsd的副作用可能导致额外的延迟

Question

我正在使用Datadog的statsd client记录特定服务器响应的持续时间。 time输入这些响应时，我通常会传递大量自定义标签。因此，我正在减少自定义标签的数量。

但是，问题是，当我减少传入的标签数量时，服务器响应会出现额外的延迟，这是不直观的，因为我传递的标签数量更少并且实现没有更改。

根据Datadog和Etsy（最初发布statsd），记录这些指标的这些方法没有被阻止。但是，他们必须使用一些额外的线程来执行此操作。

可能是什么问题？使用此客户端可能有任何副作用吗？

Answer 1

我不能专门讲Java实现，但是在CSharp客户端中，可以通过UDP端口8125将数据发送到Datadog的功能是127.0.0.1。它与执行代码在同一线程上，而不是异步。发送UDP消息后，您过程的全部工作就完成了-它被触发并立即被忘记。

您提到的线程开销发生在单独的Datadog代理进程中，该进程正在UDP 8125的另一端侦听，并且具有自己的线程池，并能够在发送到Datadog的服务器之前缓冲一些数据。

您是否有其他信息可以显示此行为？根据我的了解，这听起来不像是Datadog / StatsD的副作用。

Answer 2

我在Datadog的帮助论坛上找到了答案："How to graph percentiles in Datadog"。

  

  
• 进行更改以增加标签的复杂性（添加更多标签以更具体）将导致汇总指标可视化的行为发生变化      
    
  • EX：而在更改之前，METRIC_NAME.avg（不带任何标签）将在所有原始点上聚合（statsd获取所有原始数据点，对其进行聚合，然后通过单个度量标准流进行运送），并添加类似区域的标签（ US，EU）标记使statsd将原始数据点分为两个区域bin，进行汇总，然后通过两个流进行运送。这意味着当用*表示METRIC_NAME.avg AVG时，表示两个流的聚合，而不是单个流的
    
  

要点是延迟本身并没有增加，但是聚合多个流（每个流对应于每个自定义标签）会导致图形显示不同的形状。