The thing is, while a hub does normally allow for only half-duplex communications (I've heard of full-duplex hubs but I've never seen one), that doesn't mean that you're only going to see half of the traffic, what it means is that the devices communicating with each other through the hub will communicate at half-duplex. You'll still see all of the traffic passing through the hub. When clientA communicates to clientB you'll see that and when clientB responds to clientA you'll see that as well. A hub forwards traffic to all ports, so you'll see all the traffic regardless of duplex.
In the process of your monitoring you're probably introducing a temporary performance problem because of the fact that any devices connected to the hub are probably going to try communicating at full-duplex (especially if they're hard coded to full-duplex) and therefore collisions will occur, necessitating the re-transmitting of quite a bit of traffic in addition to the "slow down" as a result of the half-duplex nature of the hub.
The thing that's good about using a hub is that it acts as a passive network tap. You can insert it inline between the customer switch and firewall/router and monitor their internet usage, see who's going where, see what kind of usage is occurring (HTTP, FTP, etc.), see how much of their internet connection is being utilized, and see how much broadcast traffic exists in the network.
What you probably aren't seeing are problems that exixt with specific hosts on the network as you can't insert the hub between every host on the network (you can only connect the hub to one switch port, not all of them). For that you need a switch with port mirroring capability so that you can mirror traffic from specific switch ports or groups of ports to your monitor port.
I use both a hub and a port mirroring capable switch, depending on the problem I'm troubleshooting. I usually start with a hub connected between the customer switch and firewall/router. This gives me a handle on how much internet traffic there is, what kind of traffic it is, and gives me a feel for how much broadcasting is occurring on the network. I'd say that in the majority of cases the problem turns out to be insufficient internet bandwidth or a large volume of broadcasting causing congestion, re-transmits, slow ACK's, duplicate ACK's, etc.