[HN Gopher] Kyanos: eBPF-based network issue analysis tool
___________________________________________________________________
Kyanos: eBPF-based network issue analysis tool
Author : lijunhao
Score : 168 points
Date : 2024-11-16 05:34 UTC (17 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| jnck wrote:
| Great. Now we could gain detailed insights into how our system is
| behaving in real time, which is invaluable for troubleshooting
| and optimizing performance. For those who just heard eBPF, there
| is the fun-damental source about it [0].
|
| Links: [0]: https://ebpf.io/books/buzzing-across-space-
| illustrated-child...
| akutlay wrote:
| Great book!
| burnt-resistor wrote:
| Nice nice!
|
| Btw, I'm wondering if OFED and/or DPDK are also still used, and
| if they're still used for fast packet pushing.
| _zoltan_ wrote:
| Can't use RDMA without MOFED properly on Nvidia cards.
| gotbeans wrote:
| I think there must be still some corp frameworks that do use
| it extensively, but it's just not heard all that much about.
|
| Some examples, (Broadcom) Vmware NSX-T gateways, Alivaba used
| to use it, and a lot of extreme HFT use it too, mostly to
| reduce latency and manipulate tcp.
| jpgvm wrote:
| By OFED I assume you are meaning RDMA and yes, it's used
| extensively. Not just in HPC but anywhere you are doing high
| performance collective communication. Frameworks like MPI,
| UPC/UPC++, NCCL, UCX etc are all underpinned by RDMA. Most of
| the AI distributed training frameworks are MPI based for
| example.
|
| OFED is less of a thing now because most of the work has gone
| upstream, both into the kernel and into the rdma-core
| userland.
|
| Also worth mentioning that MLNX_OFED (sometimes called MOFED)
| is now being transitioned into DOCA-Host. This is mostly
| because of that aforementioned upstreaming and the move
| towards more SmartNIC stuff (ala Bluefield) being the focus
| as core RDMA support is mostly provided by upstream.
| baruch wrote:
| My day job is working on a product that uses DPDK for a super
| high performance file system.
| Vampiero wrote:
| Why would anyone want to read about eBPF in such a format?
| butterNaN wrote:
| Really cool, I remember a specific incident six odd years ago
| where I had to wade through tcpdump files to investigate an
| issue, and wished I could create something like this. I suppose
| you get more control over data if you're doing it the "hard" way
| (e.g I don't see an option to use `median`s in here) but I am
| guessing you likely dont need it in 90% of the cases
| burnt-resistor wrote:
| Speaking of network debugging tools, I really miss the network
| connectivity troubleshooting tool (and supporting network
| configuration database service) at Meta that has panopticon-like
| awareness of all networks, network rules, host firewall rules,
| and user/service user privileges. It ran with syntax paraphrased
| like the following: {{whatever_it_was_called}}
| {{src_ip_or_host[:src_port]}}
| {{dest_ip_or_host_or_network}}:{{dest_port}}
| [service_or_user_privileged_membership_group]
|
| It walks every hop and identifies any misconfiguration.
|
| Sadly, sysadmin and netadmin tools, responsibilities, and skills
| are withering trades that have been subsumed or ignored in the
| modern SWE/SRE enterprise almost as afterthoughts.
| sva_ wrote:
| Seems like it currently only supports protocols http, mysql,
| redis?
|
| Also, when you let it run through some wireguard vpn, the
| information is a lot more limited.
| hengyoush wrote:
| "Seems like it currently only supports protocols http, mysql,
| redis?" yes, more protocols will be supported in future
| releases
|
| "when you let it run through some wireguard vpn, the
| information is a lot more limited." The support for such
| complex networks is not very good at this stage, but
| improvements are expected in future versions.
| bigcat12345678 wrote:
| The author of this repo here, AMA
| faded242 wrote:
| So.. like trafshow.
___________________________________________________________________
(page generated 2024-11-16 23:00 UTC)