How to Do Database Logging/Monitoring "Right"?

So, people sometimes ask me about how to do database logging/auditing/monitoring and log analysis right. The key choice many seem to struggle with for database auditing and monitoring is reviewing database logs vs sniffing SQL traffic off the wire. Before proceeding, please look for more background on database log management, auditing and monitoring in my database log management papers (longer, more detailed - shorter) The table below summarizes the situation with database monitoring and auditing - now you can make your choice more intelligently (items in bold are the ones I consider key):

	Pro	Con
Sniff SQL traffic from the wire	No database performance impact Awareness of returned content (for SELECTs) Guaranteed role separation Better for DBA monitoring No agents No database configuration changes	Extra device needs to be purchased, deployed and managed Doesn't work with encryption No local access monitoring
Collect and analyze database logs	No extra $$$ - use your existing logging tool Can user review activity across log sources, from databases to servers Satisfies compliance demand for "database log review" Can monitor ALL access to data in the database, even over APIs and local	Performance impact possible (*) Database config changes needed Usually not truly "real-time" (polling)

Choose logs if you care for the relevant Pros (esp key ones) associated with them; choose sniffing if you care for the Pros and are NOT undermined by their Cons (e.g. lack of support for encrypted traffic)

Comments? Additions? Concerns?

(*) Nobody really knows what it will be in each particular situation: 0-40% were observed under various conditions by various people ...

Technorati tags: log management, logging, database, security

UPDATE: Rich adds his option #3, but I am skeptical since it is not very sexy. Dedicated agents on each databases just aren't that exciting...