Does percona have shell scripts for monitoring:
long running transactions
locks
deadlocks
logs generated
etc?
Just looking for something simple so I don’t need to install pmm. Most of our percona servers are not critical.
1 Like
PMM is indeed the best option for you. Deadlocks are error conditions returned to applications so there’s no need to monitor mysql for this if your app is properly coded to check errors. For long running transactions, you would need to run something like ‘SELECT * FROM performance_schema.processlist WHERE time > XX’ But then what do you do with that information once you have it? You can use pt-kill to kill long running transactions.
Which logs do you want? There are error logs and slow-query logs. Use any general tool for monitoring the error logs, but you will need to process/parse the slow log. Again PMM is the best for this.
3 Likes
I agree pmm is best for this but unfortunately installing packages and opening ports between servers will take some time where I work and I just need something quick to tell me what is happening in the db and email me.
Also unfortunately we usually have to tell app teams that their apps are causing deadlocks and have to proactively tell them that something is wrong with whatever sql we see causing it.
Long running queries sometimes tell us if something else is wrong like disk, etc. If all of a sudden there are a lot of long running queries it will indicate a problem. A few long running queries we probably don’t care or it would be a candidate for tuning.
If percona doesnt have a set of scripts to monitor (i’m guessing not) I’ll just make my own. Thanks.
1 Like
Installing PMM takes about 5 minutes using our easy script which sets up docker, downloads the image, and launches the container. You do need to install the pmm-client package on each machine to monitor and then register that agent with the PMM server.
we usually have to tell app teams that their apps are causing deadlocks
I’m sorry but that is complete nonsense. Deadlocks are a very specific error code and when they occur, the error code is returned back to the app and the app should be checking the result of any query. If the result is “error” then the app should take action. That is developer 101. It is not the responsibility of a DBA. “The database” did not cause the deadlock, the app code did thus this is is 100% the responsibility of the dev/app team to manage/handle.
If percona doesnt have a set of scripts to monitor
We do not. We focus our monitoring development by use of PMM.
1 Like