Java Statsd Client未发送全部事件指标问题排查

碰到过类似的问题，结合你的场景（4线程每2秒发送Gauge指标，发送70次后InfluxDB仅统计到40k），从几个核心环节给你梳理排查方向：

1. 先排除UDP协议本身的不可靠性 #

你使用的java-statsd-client默认采用UDP发送，UDP本身是无确认、无重传的协议，网络波动、接收端队列溢出都会直接丢包，而且客户端的错误处理器根本捕获不到这种情况——因为UDP发送在本地就直接返回成功，不会等待接收端的反馈。

快速验证这个点：把客户端改成TCP模式发送，代码调整如下：

// 最后一个参数设为true启用TCP传输
StatsDClient statsDClient = new NonBlockingStatsDClient("your.prefix", "telegraph-host", 8125, true);

如果改成TCP后数据完全不丢了，那问题根源就是UDP丢包，后续可以考虑长期使用TCP，或者针对性调优UDP相关参数。

2. 检查Telegraf的StatsD接收队列配置 #

Telegraf作为StatsD的接收端，默认消息队列大小有限，如果你的发送速率超过它的处理能力，就会直接丢弃消息。

打开Telegraf的配置文件，找到[[inputs.statsd]]段，重点检查：

• allowed_pending_messages：这个是StatsD插件的消息队列上限，默认可能只有几千，建议调大到10000甚至更高
• 查看Telegraf的日志（比如/var/log/telegraf/telegraf.log），如果看到类似statsd message queue overflow的日志，那就是明确的队列满丢包信号

3. 验证各环节的计数一致性 #

要准确定位丢包发生在哪个环节，得在每个节点加计数验证：

• 客户端本地计数：加个原子计数器统计实际发送的次数，代码示例：

private static final AtomicInteger totalSent = new AtomicInteger(0);

// 发送指标的代码里加上计数
statsDClient.gauge("my.metric", 1000);
totalSent.incrementAndGet();

// 定时打印计数，比如每10秒输出一次
new ScheduledThreadPoolExecutor(1).scheduleAtFixedRate(
    () -> System.out.println("Total metrics sent: " + totalSent.get()),
    0, 10, TimeUnit.SECONDS
);

如果本地统计的次数确实是70，但InfluxDB里只有40，那问题出在客户端→Telegraf或Telegraf→InfluxDB环节；如果本地计数都不到70，那得检查你的发送线程逻辑有没有阻塞、遗漏。

• Telegraf端计数：可以临时把Telegraf的输出改成file，把指标写到本地文件，对比文件里的指标数量和客户端发送的数量。如果文件里是完整的，那问题就出在Telegraf到InfluxDB的传输环节。

4. 排查Telegraf到InfluxDB的写入问题 #

如果Telegraf接收的指标是完整的，但InfluxDB没收到，检查这几点：

• 查看InfluxDB的日志，有没有write failed、rate limit exceeded或者disk full的错误——这些都会导致写入失败
• 检查Telegraf的[[outputs.influxdb]]配置，flush_interval不要设置太大，避免Telegraf缓存太多数据还没发送就异常退出；另外确认timeout和retries参数是否合理，保证写入失败时会重试

5. 客户端发送线程的潜在问题 #

NonBlockingStatsDClient用线程池来发送指标，默认是CachedThreadPool，虽然会自动扩容，但如果你的发送逻辑有阻塞，或者线程池被其他任务占满，也可能导致发送任务被丢弃。可以尝试自定义线程池：

ExecutorService sendExecutor = Executors.newFixedThreadPool(8); // 线程数比你的发送线程多一些
StatsDClient statsDClient = new NonBlockingStatsDClient("your.prefix", "telegraph-host", 8125, sendExecutor);

内容的提问来源于stack exchange，提问作者Nipun