As with any monitoring processes we can often gather so much data we find it hard to identify issues or trends. This was intended to be very pointed information.

Also I would almost never recommend any constant running trace other than the built in system traces of SQL Server 2005 and up. There is overhead involved. Are there situations where you can afford a trace to monitor things all the time? Sure but the canned response would be to do periodic pointed monitoring to proactively catch issues.

As a side note, remember that all high IO OLTP databases will encounter a certain amount of blocking. This is not a bad thing. This is there to protect your data consistency. It is a matter of finding a balance in how the code is written to make the blocking minimally impacting. SQL Server does a great job of finding that balance for you however the code still needs to be written with skill.