4 ms·

Brenden, I’m co-opting this comment to thank you for your work in BPF world. Due to you I discovered BCC and bpftrace two years ago. Now as part of my full time

Brenden, I’m co-opting this comment to thank you for your work in BPF world. Due to you I discovered BCC and bpftrace two years ago. Now as part of my full time work I write BPF programs and applications using libbpf. It’s been a defining part of my career. Also, sometimes I think it’s a bummer when stuff like this comes up when tons of work has already been done. It’s pretty reliable that unless you have a very specific use-case, there’s probably a BPF tool written to do something.

brendangregg 5y ago
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.

brendangregg 5y ago

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.