Start here. This is the direct spoken answer to practice first.
Why this question matters
Counters are most valuable as a fast classification tool. They show which resource is moving with the incident, but they rarely identify the exact method or object owner by themselves.
I first identify the affected process and instance, then monitor a focused set of runtime and application metrics during the slow period. I compare CPU, working set, managed heap size, allocation rate, collection frequency, time in GC, exception rate, ThreadPool thread count and queue length, completed work, request rate, and request duration. The pattern guides the next step: high CPU with stable queues points toward a CPU profile; rising allocation and GC point toward allocation or heap analysis; a growing ThreadPool queue with low or moderate CPU suggests blocked workers; high request latency with quiet runtime metrics points toward a database or remote dependency. I compare the values with normal traffic and the recent deployment rather than treating one absolute number as universally bad.