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.