I'm still not seeing the part where they actually fit together; it basically just looks like an accumulation of ad-hoc tools with no overarching concept. They look like they could be very useful tools, but there doesn't seem to be any architecture there.
There definitely isn't any overarching design. You see the same thing all throughout Linux's interfaces (containers are another great example). If you contrast this with the Solaris or BSD interfaces you notice that Linux has always been odd in this respect (DTrace, Jails/Zones, ZFS, pf, kqueue/eventports and so on).
Depending on your view you can view this as a positive or a negative. One view is to say that Linux is more collaborative, and only the "common core" interfaces are actually put into the kernel (with the higher levels being provided in userspace by vendors). A good example of this is the live patching code that came from a distilling of Red Hat's ksplice and SUSE's kgraft systems. You can track done most of Linux's features to this sort of development model.
illumos and BSD however, usually work far more like traditional software products. Some engineer goes off and implements a really interesting system that then gets put into a release. That's how ZFS, Jails, DTrace and so on were developed (in Sun) and I'm sure you can come up with other examples from BSD. The key point here is that this is a far more authoritarian model -- one set of engineers have decided on a system and developed it mostly in isolation. Linux doesn't permit that style of development because large patchsets need to be broken down over releases.
Personally I must say that I don't care for the Linux style of things, mainly because I feel it hampers OS innovation in some ways. But the upside is that the facilities are more like libraries than frameworks and so you're forced to design your abstractions in userspace. Is that good? I don't know.
Note that following along with the above theme, there is an overarching architecture for Linux's tracing tools (in userspace) in the form of bcc[1].
The answer is they don't fit well together. `perf-tools` is probably the most complete tool when it comes to number of performance counters, which be aggregated. However it is not well composable or extensible - so you have to use it as it is. I also find the code hard to read. `bcc` and `lttng` try to make things by creating a more usable API. They partially reuse the kernel part of `perf` (aka `perf_events`) and also add their own kernel modules to provide new functionality.
