If you do a search for "sys.dm_os_performance_counters", you'll find a ton of some pretty good articles on what to look for. The trouble is, the counters are just reporting symptoms. Not a one of them will lead you to the code that is causing you problems. They're just labels on the neck of the bottle and no list of ingredients. IMHO, looking at "wait stats" doesn't do much more than report symptoms, either.
You can also setup alerts to email you and you can configure those emails to pop up on your screen. They'll definitely let you know when you have excessive CPU usage, compiles, excessive file usage, reads/sec, writes/sec and a whole bunch of other things... and all of them are just symptoms. They don't tell you anything about the cause.
What you need to do is visit Brent Ozar's site and look at all the different flavors of sp_Blitz* code he has or Adam Mechanic's sp_WhoIsActive and have your alerts call those to save stuff you can go and look at in a table, which can normally include the code that may be causing the problem and, sometimes, even the estimated execution plan that goes with it.
You can also use one of Grant's favorite methods of setting up some similar Extended Events to record the "high spots" in a table.
You could also buy some monitoring software.
But I wouldn't waste my time digging into "sys.dm_os_performance_counters". To me, it's not even as useful as having a PerfMon chart running with a 2 second sample rate (total of a half hour of history). It's like hearing an animal on your roof... you know there's an animal there but you don't know what kind it is.