Too many connections
The app starts throwing connection errors under normal load, and restarting it helps for a few minutes before it comes back.
What it does. It compares open connections against the configured limit and checks whether the queries are actually slow. When they are not, the cause is on the application side, and it says so instead of blaming the database.
The app cannot connect to the database
Connection failures in the log, nothing obviously wrong with either machine.
What it does. It checks whether the database is accepting connections at all, whether the port is reachable from the app server, and what the log says it is rejecting. It reads the log line, never a credential value.
Queries suddenly got slow
Nothing was deployed, but a page that used to load instantly now takes seconds.
What it does. It looks at slow-query pressure, table growth and index use, so you find out whether a table quietly outgrew its index or something else on the box is competing for resources.
The database server is out of disk
Writes start failing and the largest consumer is not obvious from a directory listing.
What it does. It measures table and index sizes, and checks for the usual quiet offenders like binary logs and old backups sitting next to the data directory.
Is the database even the problem?
Something is slow and the database is the easiest thing to blame, so it gets blamed first and investigated last.
What it does. A handful of read-only checks rules it in or out in seconds, which either narrows the search or stops you tuning a database that was never at fault.
Nobody knows what is on this server
An inherited machine with databases on it, and no documentation about which application uses which.
What it does. It lists the databases, their sizes and their last activity, so you can see what is live, what is a forgotten copy, and what is safe to ask questions about.