I understand that you can do this, but I'm not sure i understand the rationale. I can't imagine that this is a hot enough path that this makes sense from a performance perspective, so why? What's the benefit?
Naively the thing this is replacing sounds like a much better solution than the replacement is.
Though weirdly there's a part in the middle " 8125 is contentionally what statsd used" which should obviously have used "conventionally", so who knows which parts were written and which prompted for.
I'm reaching a point now where I'd really just rather see the prompts than these kinds of posts.
So: replace what should be a clear simple concise program using documented API that can be understood and debugged and improved … with an interface designed for completely different purposes, gaining absolutely nothing, losing debuggability, clarity, and extensibility.
Yeah…
I suppose this article could be salvaged if it ended with something like “We get that this is an incredibly dumb idea, we’re just doing it for the lols. Please, nobody attempt something like this seriously, or in any production system. For educational purposes only.” But there isn’t any of that there.
> We replaced the listener with an eBPF program that watches port 8125 at the traffic control layer of every interface, and a JavaScript decoder that turns the lines into Prometheus families.
this is insane! Why on earth would one to replace a short, simple, highly debugable program with this crazy combination. Why would you trade a simple socket(2) call which shows up in ss, netstat, strace etc.. with something that opaque? Especially given the bandwidth is minuscule and the destination is already localhost.
I understand that you can do this, but I'm not sure i understand the rationale. I can't imagine that this is a hot enough path that this makes sense from a performance perspective, so why? What's the benefit?
Naively the thing this is replacing sounds like a much better solution than the replacement is.
It sounds like the solution simplifies something but I could not figure out how or what.
Pretty strange thing to do. That aside, definitely AI written. The cadence is a dead giveaway.
Very much so.
Though weirdly there's a part in the middle " 8125 is contentionally what statsd used" which should obviously have used "conventionally", so who knows which parts were written and which prompted for.
I'm reaching a point now where I'd really just rather see the prompts than these kinds of posts.
> I'm reaching a point now where I'd really just rather see the prompts than these kinds of posts.
On the mark.
> the way apps have done since Etsy taught everyone to in 2011.
What in the slop is this?
Etsy’s SRE team invented statsd in 2011
So: replace what should be a clear simple concise program using documented API that can be understood and debugged and improved … with an interface designed for completely different purposes, gaining absolutely nothing, losing debuggability, clarity, and extensibility. Yeah…
I suppose this article could be salvaged if it ended with something like “We get that this is an incredibly dumb idea, we’re just doing it for the lols. Please, nobody attempt something like this seriously, or in any production system. For educational purposes only.” But there isn’t any of that there.
Just wow.
> We replaced the listener with an eBPF program that watches port 8125 at the traffic control layer of every interface, and a JavaScript decoder that turns the lines into Prometheus families.
this is insane! Why on earth would one to replace a short, simple, highly debugable program with this crazy combination. Why would you trade a simple socket(2) call which shows up in ss, netstat, strace etc.. with something that opaque? Especially given the bandwidth is minuscule and the destination is already localhost.
Web developers make web developer choices while vibe coding.
Your past experience limits your thinking, especially in agentic environments.
But I suppose their whole business model is built upon that, given that yeet is a bun/node/deno library with bpf support.
founder here. we are not a bun/node/deno library.
we embed V8 directly and just point it at bpf
the choice of javascript was very intentional.
it has some really nice properties for dynamically instrumenting the OS.
and provides lightweight isolation for agents to control probes and do deep packet analysis.
Which popular systems if any use this? So I can avoid it.
Maybe they wanted to play a bit with eBPF... The only reasonable conclusion. Wait till they go beyond localhost and discover XDP!
haha we got xdp, tcx, BPF_MAP_TYPE_ARENA you name it ;)
check the docs.
https://yeet.cx/docs