queue:take() does not increments call counter

[vasiliy-t]

Empty queue tube_1 method calls take, kick, touch do not increment call counters in metrics:

sharded_queue_calls{status="take",name="tube_1",alias="queue_master"} 0
sharded_queue_calls{status="kick",name="tube_1",alias="queue_master"} 0
sharded_queue_calls{status="touch",name="tube_1",alias="queue_master"} 0

Expected: every call to every method increments call coounter.

[oleg-jukovec]

Statistics are now not about the number of calls, but about the number of tasks to which an action was applied.

On the one hand, this is less informative about the number of calls, and on the other hand, it is better suited for analysis what is actually happening.

[oleg-jukovec]

I'll want to clear for me a few questions:

1. Do you want the stat from a router or from storages, or both?
2. What about another label for backward-compatibility "sharded_queue_api_calls"?

[is217175]

I have not actually understood how this work for analysis. If a function call occurs, then in any case tarantool does some internal operations, regardless of whether it returns anything. It is not dry-run, is it?. There is no big difference for ops between counting good and all calls if we watch only one metric. May be you can add more metrics to sharded_queue like request/response size, time etc. Then It should make tarantool more analyzable. IMO, for sure.

1. We gather all from storages and routers, but both sharded_queue_* metrics appears only on routers and they are the same.
2. In absence of another metrics, adding an additional one which count all calls will be good idea.

[oleg-jukovec]

2. In absence of another metrics, adding an additional one which count all calls will be good idea.

Let me give some context:

1 take() on router could became number_of_storages take() on storages in sum. Are you interested in calls counting only on a router, storages, or router + storages separated?

[is217175]

2. In absence of another metrics, adding an additional one which count all calls will be good idea.

Let me give some context:

1 take() on router could became number_of_storages take() on storages in sum. Are you interested in calls counting only on a router, storages, or router + storages separated?

No. I mean metric like sharded_queue_calls, but which include calls on empty queue.

But if separating metrics by roles/instance make sense in troubleshooting, why not?