When you closely watch doctors and surgeons, they analyze reports in a step by step manner. No one needs an x-ray or CT-scan report, right on the first meet. Initial readings will be pulse rate, blood pressure, fever etc. A few correlations of these data will lead to next level. Then it may be ECG, X-rays or ultrasound tests etc. Further analysis may lead to full-blown details using CT-Scan etc.

The reason why they go step by step, is definitely cost and time to get these details done. The same thing applies to application performance. Somewhere you must start. A good start can be made with monitoring of all applications, server boxes and databases. The moment you start monitoring these, you will get clues on what is happening. Without monitoring, your teams are in dark when risk occurs. Monitoring will get the initial readings about the apps and databases, such as number of connections, requests per second, IO Operations per second etc.

Monitoring of applications and logfiles will also help to be compliant with SIEM. https://en.wikipedia.org/wiki/Security_information_and_event_management. Logfiles contain important details about what has happened. Logs are always used for post-mortem only, to go back in time and analyze what has happened.

But monitoring cannot solve your problem. You can use deep-dive profilers that can tell you the exact place of the slowness, aka bottlenecks. Still a tool cannot give an out of the box solution to your problem. The moment you know the location of the problem, you can attack that easily.

To proactively ensure performance, you must do drill frequently. Walking 40-minutes, twice a week, can reduce heart attack possibilities by as much as 80%. So the more stress tests you do to your apps, before going live, it is better and it preempts post production surprises. So doing a load test, coupled with monitoring will help you get predictable performance. This must be your ultimate goal to keep your customers happy, by providing faster apps.