pyroscope-rs VS trippy

A general purpose profiler: https://github.com/pyroscope-io/pyroscope-rs

If someone is interested in this space, feel free to reach me!

I feel some of the OP points. I was working on a profiling agent lately, and one of the issues was running it on multiple platforms (just the four big ones linux/mac-x86/arm) on FFI (because it'll be run directly from python/ruby/etc...) and preferably having the thing just work without having to install or configure any dependencies.

Like OP I hit two walls: libunwind, and linking. For libunwind, I ended up downloading/compiling manually; and for linking there is auditwheel[1]. Although it is a Python tool, I did actually end up using for Ruby (by creating a "fake python package", and then copying the linked dependencies).

It was at that time that I learned about linking for dynamic libraries, patchelf and there is really no single/established tool to do this. I thought there should be something but most people seem to install the dependencies with any certain software. I also found, the hard way, that you still have to deal with gcc/c when working with Rust. It does isolate you from many stuff, but for many things there is no work around.

There is a performance hit to this strategy, however, since shared dynamic libraries will be used by all the running programs that need them; whereas my solution will run its own instance. It made me wonder if wasm will come up with something similar without affecting portability.

Finally, the project is open source and you can browse the code here: https://github.com/pyroscope-io/pyroscope-rs

[1]: https://github.com/pypa/auditwheel

Version 0.5 is now live!: https://github.com/pyroscope-io/pyroscope-rs

Working on https://github.com/pyroscope-io/pyroscope-rs A profiling solution for Rust and other languages.

Thanks to the maintainers at pprof-rs for helping us figure out how we can modify their profiler to create our rust agent (https://github.com/pyroscope-io/pyroscope-rs).

Another interesting tool in this space is trippy, which ‘combines the functionality of traceroute and ping’

https://github.com/fujiapple852/trippy

You can, with several caveats, detect which hop(s) on the path perform NAT by using some trickery [1]:

> NAT devices are detected by observing a difference in the expected and actual checksum of the UDP packet that is returned as the part of the Original Datagram in the ICMP Time Exceeded message. If they differ then it indicates that a NAT device has modified the packet. This happens because the NAT device must recalculate the UDP checksum after modifying the packet (i.e. translating the source port) and so the checksum in the UDP packet that is nested in the ICMP error may not, depending on the device, match the original checksum.

[1] https://github.com/fujiapple852/trippy/releases/tag/0.11.0

OP, you may find this [1] “trick” useful. It allows you to dynamically determine the correct byte order for the various IPv4 headers for the platform and thus avoid the need to statically decide on the byte ordering for each platform you intend to target.

You may also find this [2] table useful, it shows which platforms allow the combination of IPPROTO_ICMP + IP_HDRINCL so it may be used without elevated privileges.

In general, my experience of raw sockets is that they are not very “raw” at all, the OS can and does still perform a variety modifications and additions to what you send and receive, in highly platform specific and often poorly documented ways. In particular, TCP and raw sockets should generally be avoided.

[1] https://github.com/fujiapple852/trippy/blob/master/crates/tr...

[2] https://github.com/fujiapple852/trippy/issues/101#issuecomme...

[3] https://github.com/fujiapple852/trippy/issues/1104

You are right that showing packet loss for intermediate hops is a frequent source of confusion.

Rather than leave it out, I added a status column which shows different statuses for intermediate hops (blue if the hop responds to less than 100% of probes and brown if it responds to 0%) vs the target hop (amber and red).

Where this breaks down is when dealing with ECMP for UDP & TCP tracing, as a given hop (ttl) may represent the target for a given round of tracing but not for the next. The mistake, imho, is to associate _any_ data with a hop (ttl) rather than the hop in the context of a tracing flow.

That is why Trippy had a number of features aimed at helping with ECMP, such as Paris and Dublin tracing, and the ability to filter tracing by unique flow id. I've covered these quite a bit in the 0.8.0 [0] and 0.9.0 [1] release notes if you want to know more.

[0] https://github.com/fujiapple852/trippy/releases/tag/0.8.0