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.
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.
@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.
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.