没人监听 Port 8125,那 StatsD 数据去哪了?

Nobody Is Listening on Port 8125

没人监听 Port 8125,那 StatsD 数据去哪了?

我的 Fedora 机器上有个应用持续向 127.0.0.1:8125 发送 StatsD 数据包,但端口上没有任何监听程序。这引出了一个思考:传统的 statsd_exporter 本质上只是一个套着 UDP 套接字的包嗅探器。既然内核已经处理了这些数据,为什么还要在用户态再跑一个监听器?我们尝试用仅 165 行 C 代码的 eBPF 程序直接在内核层捕获流量,配合 JavaScript 解码器,彻底取代了 statsd_exporter。应用端无需任何改动,依然通过 UDP 发送数据,但指标采集不再依赖任何监听服务。这不仅简化了架构,还让 Redis、memcached 等协议的监控也能复用同一套机制。

监听器是每个数据包的第二个读取者,所以我们直接找到了第一个。
  1. bawolff

    我明白你可以这么做,但我不太理解背后的理由。我无法想象这是一条足够热的路径,以至于从性能角度来看这样做是合理的,那为什么要这么做呢?有什么好处?

    直觉上,被替换掉的方案听起来比替换后的方案好得多。

  2. chanux

    听起来这个方案简化了什么东西,但我没搞懂是怎么简化的,或者简化了什么。

  3. therein

    这事儿挺奇怪的。

    抛开这点不谈,这肯定是 AI 写的。那种行文节奏就是铁证。

同日更多故事

2026-10-03