我正在使用 Datadog 的statsd client 来记录某个服务器响应的持续时间。当time-ing 这些响应时，我曾经传递了不少自定义标签。所以我正在减少自定义标签的数量。
但是，问题在于，当我减少传入的标签数量时，服务器响应会有额外的延迟，这并不直观，因为我传入的标签更少并且实现没有改变。
根据 Datadog 和 Etsy（最初发布 statsd），记录这些指标的这些方法不会阻塞。但是，他们必须使用一些额外的线程来执行此操作。
可能是什么问题？使用此客户端是否有任何副作用？
【问题讨论】：
标签： latency side-effects statsd datadog
我不能专门针对 Java 实现，但在 CSharp 客户端中，可以通过 UDP 端口 8125 将此数据发送到 Datadog 到 127.0.0.1。它与您的执行代码在同一个线程上，而不是异步。一旦发送 UDP 消息，您的进程的整个工作就完成了 - 它被触发并立即被遗忘。
您提到的线程开销发生在单独的 Datadog 代理进程中，该进程正在侦听 UDP 8125 的另一端，并且具有自己的线程池并且能够在发送到 Datadog 的服务器之前缓冲一些数据。
您是否有其他信息表明这种行为？据我所知，这听起来不像是 Datadog/StatsD 的副作用。
【讨论】：
我在 Datadog 的帮助论坛上找到了答案："How to graph percentiles in Datadog"。
- 进行更改以增加标签复杂性（添加更多标签以更具体）将导致汇总指标可视化的行为发生变化
- EX：而在更改之前 METRIC_NAME.avg（没有任何标签）将聚合所有原始数据点（statsd 获取所有原始数据点，聚合它然后通过单个度量流发送），添加一个标签，如区域 (美国、欧盟）标签导致 statsd 将原始数据点分箱到两个区域箱中，聚合它们，然后通过两个流传送。这意味着在绘制 METRIC_NAME.avg AVG 时，* 表示跨两个流而不是单个流的聚合
所以要点是延迟本身并没有增加，但是聚合多个流（其中每个流对应于每个自定义标签）导致图表显示不同的形状。
【讨论】：