Auditing question

The docs say that we can audit when “A N1QL DELETE statement was executed” on the Query service and also when a “Document was deleted” on the data service.

My question is what other data comes along with those events. Will the Data Service provide the key of the deleted document and the Query service provide the query.

We are using Enterprise 6.5.
Thank you for your help.

Yes the delete event contains the document key.

N1QL mostly (except random document, stats) includes document key any operations with Data service.

What goes in the audit of n1ql statements can be seen query/audit_descriptor.json at master · couchbase/query · GitHub

1 Like

This is a sample delete audit event for a n1ql statement when auditing for deletion is enabled for Query service.

    "$1": {
      "description": "A N1QL DELETE statement was executed",
      "id": 28678,
      "isAdHoc": true,
      "metrics": {
        "elapsedTime": "8.884558ms",
        "executionTime": "8.853976ms",
        "resultCount": 0,
        "resultSize": 0
      "name": "DELETE statement",
      "node": "local_node",
      "real_userid": {
        "source": "local",
        "user": "Administrator"
      "requestId": "ded68ae3-d964-4d87-b1c2-70cf72041c6b",
      "statement": "DELETE FROM orders WHERE priority = 6",
      "status": "success",
      "timestamp": "2018-02-09T14:52:55.786-08:00",
      "userAgent": "curl/7.43.0"

Under the metrics section, you should be able to see the resultcount and mutation count. But as for seeing which document ID was changed / deleted, I don’t think you can see the key itself. Unless you added it to the query specifically. But this is true only for N1QL - DELETE statement audits.

If you look at audit logs from Data Service - document delete, you should be able to see the id and key that was deleted. something like -
{....."description":"Document was deleted","id":12345,"key":"Product_375" .... }

1 Like

This post was super helpful

What are the ordering properties of these audit logs.

I assume the timestamp is the time of logging, which is after completion of execution. I suppose timestamp - elapsed time (what is the difference between execution time and elapsed time?) is the start time for this query. I guess that means the time query begins to get processed by the engine. parsing → planning …

Can I rely on this time order wise per server? per service across multiple servers.

Is there a way via logs to determine order of arrival of queries over the wire?


elapsedTime – Time query listener accepted request to completion (if all servicers are in use it will be queued)
executionTime - Time query start execution (From parse) to completion.
The difference between elapsedTime, executionTime tells how long it queued. Most of cases those will be small unless lot of incoming requests and query services already processing its capacity.

At present there is no info logged arrival of query per node or per cluster. cc @Marco_Greco

1 Like