I hate sounding like a broken record, but this is exactly what the built in logging for database drivers does for you. The only thing missing is the intelligence of what to look for, which by the way is the most difficult part. Right now, you can turn on logging and periodically review the logs. What would you look for? If you can't do it by hand, you will never be able to program it into code. But even if you can do it by hand, that doesn't mean you can create a program to do it. Programs can't be smarter than their author, although they can be faster.
Logging has a completely different focus than normal operations. If everything worked perfectly, you wouldn't need logging. So one requirement of a logging facility is that it is somewhat out of the hands of the normal user. First they may not know to use it, and second, they may want to disable it so they can go undetected while they do bad things. Admins usually have to hunt through log files looking for clues to bad behavior and often is isn't known beforehand what to look for. If you create a selective logging facility, you limit your ability to apply any intelligence to the analysis.
But beyond this, I can't think of many package which allow users to choose what sql or procs/scripts to run. Actually the only one I can think of is my cronjob package. It specifically runs only with admin privileges, but the original goal was to allow regular users to submit code which could run after approval was obtained. The data model is in place where each cronjob can be disabled/enabled or approved/not approved, just no regular user pages to manage it. But this package places the review prior to execution and review/approval must be done by an admin. This is also a good place to put in regularly/sometimes run auditing/reporting code, since you can also select any cronjob and run it instantly.
On the database side it is more difficult to be generic. Each database is different and logging data must require a separate set of tables, which eventually slow down the system. Triggers work well, but there are also log files for the database. They can probably be more selective than the ns_db logging, but also they contain less context. The database doesn't know anything about users or packages.
