Here are some thoughts:

1. I think of this as a log that has the following columns: timestamp, method name, user name, client-ip, transaction id, primary object id, data. I'm also OK with the object id being folded into the data field.
2. A single method call can emit multiple rows. Each set of rows emitted from the same call with share a transaction id.
3. The data field of each row will communicate useful data, e.g. start of a method, some parameters, access denied, object not found, end of method, etc.
4. Fields that are common for all rows emitted from a row should be set at the entry of the method, and should automatically show up in logs emitted by the method or core APIs calls within the method. The latter can be added over time.
5. The logging used should fit with the existing logging technology and should work with plugins like the EventLog plugins that allow logging to the database and viewing such logs via the web interface.

Sounds good to me. One note - 'Fields that are common for all rows emitted from a row' should be 'Fields that are common for all rows emitted from a method ' , right?

If storing data in the log, we should be careful that this does not contain any sensitive information.

(In reply to comment 0013798:0031403)

If storing data in the log, we should be careful that this does not contain any
sensitive information.

The safest way to do that is to have a whitelist approach, e.g. log project id, username and issue_id , rather than exclude specific fields.