Missing Bucket Metrics

Couchbase Server
1

How to fetch the following 2 bucket metrics :-

  1. TPS(Transactions per second)
  2. N1QL queries/sec

I tried the /pools/default/buckets/<bucket_name>/stats, couldn’t find the above 2 stats in the list.
I also tried, /pools/default/buckets/<bucket_name>/statsDirectory , didn’t find it in this api as well.

2

@Sumit1991Saha Can you please take a look here

3

@raju @vsr1
What i am looking for is no. of N1QL per Sec for a bucket.

The link that you shared https://docs.couchbase.com/server/current/n1ql/n1ql-rest-api/admin.html#_statistics consits of different N!QL stats at node level, but i need it at bucket level.
Only way i could figure out is using “/default/buckets/{bucket}/nodes/{hostname}/stats” and fetch the N!QL per sec stats and then call it on other nodes and sum it up, which doesn’t look right to me.

Is there any other api? or am i looking at this problem incorrectly?

4

@Sumit1991Saha You are looking at this correctly. Let me find out from my development team too and get back to you

5

@raju any update on this?

6

I am afraid there’s no per bucket request counter.
This is for two reasons, 1- metric definition, 2- performance.
In terms of 1- it may mean different things for different people, for instance

  • for joins and unions, to name but two, do you count the same request once per bucket (meaning that the same request is counted more than once, and if you sum all the n1ql requests for all the buckets, you get way more requests than the value reported by the global requests counter)
  • if you do, for self joins and unions on the same bucket, do you count them once per arm (so you will see two requests for the same bucket) to make it consistent with the above, or do you only count it once, as per below?
  • or do you count them only for one bucket, and if yes, which one?
  • do we mean requests, or KV gets (equally meaningful measures)?

WIth the advent of collections N1QL requests per bucket doesn’t even mean any of that anymore, as buckets become tenant containers and the actual data is held inside collections, so the relevant metric would have t become N1QL request per collection.

In this context, the only reliable measure every one could agree on would be N1QL KV gets per bucket, which if you do a simple SELECT USE KEYS would equate to a N1QL requests per bucket counter

Re 2, metrics are already fairly expensive for N1QL, and counting requests per bucket would require navigating the execution tree at the end of each request.
We could optimize this and make it part of the request teardown process, but the point still remains that, in particular with the advent of collections, that could potentially add to an extra thousand of metrics that ns_server has to poll every second: that’s an order of magnitude bigger than what ns_sever already polls.

I think the best thing that we can do here is take a step back - what you you need to achieve? We may be able to achieve what you need by having a look at different metrics.

As a side node - the /admin endpoints are defined per node. Per cluster measures are accessed through the system keyspaces, which, internally use the /admin endpoints to collated all the per node metrics.

HTH,
Marco

7

@Marco_Greco thanks a lot for the detailed explanation.
Since on the bucket dashboard , i saw a metric called N1QL/sec hence was wondering why am i not receiving the metric using /stats.
The presence of N!QL per sec at node level makes more sense. But the presence of it on Bucket stats dashboard created a confusion for me.

8

I don’t disagree that it could be better placed in the UI.
Re the metric in stats, it’s the “active_request.count” field in the json document.
The UI then calculates the N1QL requests per second from that.