In 5.2, the system health page shows a trigger load breakdown by thread. Due to ordering constraints—for example, that an HTTP request trigger must execute before the corresponding HTTP response trigger—it may not be possible to evenly distribute trigger load, so 100% load is not actually achievable.
Regarding trigger drops, that is the surest indicator that the system is overloaded. Ideally, this metric should always read zero, since dropping triggers means missing out on potentially useful analysis. Generally, drops happen in bursts, so I would look not only for triggers with a high number of average cycles, but also those with a high maximum number of cycles. There are sometimes very simple changes you can make to your triggers to drastically improve performance, without giving up anything in the way of analysis or metrics.