3 ms·

Thanks for your comment. Yes, it's a bummer to see people waste time reinventing something, and, to then have multiple solutions to the same problem. It's clutt

Thanks for your comment. Yes, it's a bummer to see people waste time reinventing something, and, to then have multiple solutions to the same problem. It's clutter, and wastes end user's time to sort through. One solution is to spend several years developing expertise and finding the edge of the known world, beyond which is yet to be explored. In this space it means knowing all the tools that are out there. It's no coincidence that I find it easy to draw these diagrams: https://www.brendangregg.com/Perf/linux_observability_tools.png https://www.brendangregg.com/Perf/linux_observability_tools.... ... and to find new areas where there are missing tools. These skills are connected! But I'm lucky to have had roles where I have spent over a decade specializing in performance analysis and tooling. For a lot of people with limited time, your best bet is to not learn the entire world, but to learn some narrow specific use case and see what tools exist just for that, and how it can be improved. Just like you say: a very specific use case. Plus check the open issues on bcc/bpftrace github, since there's stuff there (not just bugs, but tool/feature ideas) that haven't been done yet.

Matthias247 5y ago
> Yes, it's a bummer to see people waste time reinventing something, and, to then have multiple solutions to the same problem. It's clutter, and wastes end user's time to sort through. It's only that way if you see the main purpose of this blog post to explain someone how to trace a TLS connection. That could indeed be shortened to 10 lines of "use this existing tool". However to me it doesn't seem like this is the main goal of the post. It mostly uses TLS tracing as an example to describe how eBPF based tracing works, and what components are necessary for it. It can be seen as a tutorial on how to add tracing support for any other userspace function, instead of just being an explanation on how to use a predefined tool to use a single problem. I don't think its a bad thing if more of those tutorials show up.
- brendangregg 5y ago
  People learning to code observability tools in eBPF should be starting with bpftrace, and the tutorials should too. I've made this point in blog posts and keynotes etc. Doing it using bcc is how we did it 6 years ago -- it's out of date.

Matthias247 5y ago

> Yes, it's a bummer to see people waste time reinventing something, and, to then have multiple solutions to the same problem. It's clutter, and wastes end user's time to sort through. It's only that way if you see the main purpose of this blog post to explain someone how to trace a TLS connection. That could indeed be shortened to 10 lines of "use this existing tool". However to me it doesn't seem like this is the main goal of the post. It mostly uses TLS tracing as an example to describe how eBPF based tracing works, and what components are necessary for it. It can be seen as a tutorial on how to add tracing support for any other userspace function, instead of just being an explanation on how to use a predefined tool to use a single problem. I don't think its a bad thing if more of those tutorials show up.

brendangregg 5y ago
People learning to code observability tools in eBPF should be starting with bpftrace, and the tutorials should too. I've made this point in blog posts and keynotes etc. Doing it using bcc is how we did it 6 years ago -- it's out of date.