Fleet differs from Rancher in one major design philosophy: nearly all "business logic" happens in the local cluster rather than in downstream clusters via agents.
The good news here is that the fleet-controller will tell us nearly all that we need to know via pod logs, network traffic and resource usage.
That being said, downstream fleet-agent deployments can perform Kubernetes API requests back to the local cluster, which means that we have to monitor traffic inbound to the local cluster from our agents as well as the outbound traffic we'd come to expect from the local fleet-controller.
While network traffic is major point of consideration, we also have to consider whether our performance issues are compute-based, memory-based, or network-based. For example: you may encounter a pod with high compute usage, but that could be caused by heightened network traffic received from the truly malfunctioning pod.
http pprof handlers are enabled by default with all default profiles under the /debug/pprof prefix.
To collect profiling information continuously one can use https://github.com/rancherlabs/support-tools/tree/master/collection/rancher/v2.x/profile-collector