go-profiler-notes VS parca

Thanks!

As @brancz mentioned, Delve uses DWARF unwind information to produce backtraces (they are stored in the .debug_frame section for Go).

You are right, Go enabled frame pointers for all architectures as of 1.17 [0]. This is enabled to allow profilers to work well, without having to use to techniques such as the one we describe in our post.

When it gets funny is that there's `gopclntab`, a 3rd option in Go to unwind stacks, used by `panic` and I believe other parts of the runtime. If you are interested in more details, Felix Geisendörfer's repo contains way more details [1]

[0]: https://go.dev/doc/go1.17

[1]: https://github.com/DataDog/go-profiler-notes/blob/main/stack...

this is a good read about pprof https://github.com/DataDog/go-profiler-notes/blob/main/guide/README.md

Continuous profiling tools such as parca may be worth looking into for your use case.

They were bought by Elastic, maybe they'll open source it. There's also https://github.com/parca-dev/parca

an alternative option to pyroscope to do continuos profiling in production could be parca.dev check and here

+1 to Parca.dev https://github.com/parca-dev/parca as continuos profiling tool in production

Parca collects, stores and makes profiles available to be queried over time. It is open source and can be deployed on production environments as Parca focuses on sampling profiling two main types of profiles: tracing and sampling.

Polar signals develops Parca [0] which is another eBPF observability tool, and Isovalent develops Cilium [1] which is built on eBPF as well. Genuinely curious if there are differences, or if eBPF only allows for specific observability functionality and each tool has it all.

[0]: https://github.com/parca-dev/parca

[1]: https://github.com/cilium/cilium