Find the N1ql Query Error info shown in Dashboard

Hi Team,

I have attached a image below from dashboard of my couchbase setup for one hour and for a specific bucket.

Its showing errors at consistent times.
I checked the application log and not able to find these many errors. I need to understand this metric.
I want to understand how this graph is built to actually find out why it showing these many errors?
Also Where can I find the error logs from which this dashboard is built?

Is there any bucket similar to system:completed_requests where the errors are stored?
can you give me some pointers.?

Thanks in advance


look system:completed_requests on each node for status != “success”

Thanks for the reply.

Executed the query . DId not find any results.

That means it is not returned errors or it is rotated. Query service logs error statement in system:completed_requests and return as part of response (will not write into logs) cc @Marco_Greco

I have the same situation.
I have some peaks in n1ql_errors metric from one hour ago. I’ve checked the system:completed_requests and despite of have info from more than 1 hour ago, I am not able to see any query in error. How could I be able to identify this kind of information?

And about such metric in particular, what kind of errors does it count? Is it only for N1QL sintax errors or does it also catch timeouts or anything else?


Without having configured completed requests to capture the requests, you won’t be able to see what the failing statements were.

Bear in mind that if you configure to capture all statements and if your system is handling a large enough number of requests the completed limit will be hit in a short amount of time and the statements of interest will then be evicted.

We do not by default record “any errors” as these may for example be typo’s resulting in syntax error returns. It is up to the administrator to decide which statements are worth noting and which aren’t (via the completed requests configuration). If they are say syntax errors from ad-hoc queries, this may mean the spikes you observed aren’t anything to be concerned with. Similarly if say an insert statement is accidentally run multiple times attempting to insert the same keys, this could easily result in a spike in the error count which is benign, should be expected by the user issuing the statement and be of no real interest to the administrator.

Typically we’d expect that an application receiving unexpected errors would report such errors and any investigation would be initiated in response to that, rather than from observation of the error count metric.


1 Like

Thanks for your reply.
I did some configuration changes based on threshold or timeout settings mainly in order to capture info about slow queries, but how do I setup the queries that gives any error? In my completed_requests settings do not have anything as error (even the label is not in the settings json), how should I get it configured to get any query in error? I’ve read that you can configure any particular error code, but how to set it up to capture all of them?

As example, here my settings for completed requests:


You cannot say “capture any error”. You can set the threshold low enough to capture all requests, and mine the results where the errorCount != 0, but you cannot limit the capture to only those with errors.

Again though, if your application reports specific unexpected errors - as would be the typically expected starting point - it is seeing then you would configure for them…

1 Like

Normally errorCount != 0 it will be logged irrespective of time it taken. Once it started execution.
if CE check the following on every query node.

select s.* from system:completed_requests AS s WHERE s.errorCount != 0;

(non execution) syntax/semantics/planner errors may not logged into system:completed_requests, can be counted N1QL errors in dash board.
Verify run query with syntax error 10 times quickly and see it reflected dashboard errors after few min

1 Like

To clarify, and build on my responses and what @vsr1 has noted, if it is something like a syntax error then the n1ql_errors count will increase but requests will not be logged as execution will not have commenced. If you set the threshold to 0 (i.e. to capture all requests) you should also see requests that have not commenced execution but failed with an error. (But you will have to carefully consider your error limit and request rate before capturing all requests.)

1 Like