‹ BackHN Continuity

Thread

Nobody Is Listening on Port 8125

19 points · 15 comments · zasc

Loading the complete thread in the background. This saved snapshot is available now. Refresh

  1. theamk · · focus · HN ↗
    > 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.

    1. tucnak · · focus · HN ↗
      Maybe they wanted to play a bit with eBPF... The only reasonable conclusion. Wait till they go beyond localhost and discover XDP!
      1. r3tr0 · · focus · HN ↗
        haha we got xdp, tcx, BPF_MAP_TYPE_ARENA you name it ;)

        check the docs.

        <a href="https:&#x2F;&#x2F;yeet.cx&#x2F;docs" rel="nofollow">https:&#x2F;&#x2F;yeet.cx&#x2F;docs

    2. cookiengineer · · focus · HN ↗
      Web developers make web developer choices while vibe coding.

      Your past experience limits your thinking, especially in agentic environments.

      1. r3tr0 · · focus · HN ↗
        founder here. we are not a bun&#x2F;node&#x2F;deno library.

        we embed V8 directly and just point it at bpf

        1. r3tr0 · · focus · HN ↗
          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.

          1. lloydatkinson · · focus · HN ↗
            Which popular systems if any use this? So I can avoid it.
        2. cookiengineer · · focus · HN ↗
          Aren&#x27;t v8 Isolates inside seccomp sandboxes?
  2. bawolff · · focus · HN ↗
    I understand that you can do this, but I&#x27;m not sure i understand the rationale. I can&#x27;t imagine that this is a hot enough path that this makes sense from a performance perspective, so why? What&#x27;s the benefit?

    Naively the thing this is replacing sounds like a much better solution than the replacement is.

  3. therein · · focus · HN ↗
    Pretty strange thing to do. That aside, definitely AI written. The cadence is a dead giveaway.
    1. stevekemp · · focus · HN ↗
      Very much so.

      Though weirdly there&#x27;s a part in the middle &quot; 8125 is contentionally what statsd used&quot; which should obviously have used &quot;conventionally&quot;, so who knows which parts were written and which prompted for.

      I&#x27;m reaching a point now where I&#x27;d really just rather see the prompts than these kinds of posts.

      1. max__dev · · focus · HN ↗
        &gt; I&#x27;m reaching a point now where I&#x27;d really just rather see the prompts than these kinds of posts.

        On the mark.

    2. lloydatkinson · · focus · HN ↗
      &gt; the way apps have done since Etsy taught everyone to in 2011.

      What in the slop is this?

      1. YesThatTom2 · · focus · HN ↗
        Etsy’s SRE team invented statsd in 2011
  4. chanux · · focus · HN ↗
    It sounds like the solution simplifies something but I could not figure out how or what.
  5. dmitrygr · · focus · HN ↗
    So: replace 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…
Open on Hacker News to reply ↗

Unofficial Hacker News client; not affiliated with Y Combinator.