Bug 1317 - utility to make adding counters easy
utility to make adding counters easy
Status: NEW
Product: unbound
Classification: Unclassified
Component: server
1.6.2
Other All
: P5 enhancement
Assigned To: unbound team
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2017-06-21 19:09 CEST by Manu Bretelle
Modified: 2017-06-22 20:36 CEST (History)
2 users (show)

See Also:


Attachments
adding a counter (4.97 KB, application/octet-stream)
2017-06-21 19:09 CEST, Manu Bretelle
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Manu Bretelle 2017-06-21 19:09:42 CEST
Created attachment 412 [details]
adding a counter

It would be nice if bumping stats counter could be more versatile. Currently, you need to create a dedicated variable in the stats structure, add code to specifically display the stats and there seem to be a relation between the server and the library, while the server should be able to reach out to the library to bump counters, there could be cases where the library needs to bump a counter and this currently need to go through the server, which is not desirable.

If there were a utils library to bump counters using a simple str/uint key-value pair, it would be easier to add counters and expose internal statistics making it easier to understand what goes on in a production system.

Something like a C++ unordered map http://www.cplusplus.com/reference/unordered_map/unordered_map/ would be handy.

Some API like:
counter_increment('num.queries_ratelimited', 1)
would be used in the code, the api may take care of setting the value on first invocation, or responsibility could be left to the implementer in the initialization of their module/component.

Displaying stats can walk the unordered map and retrieve key/values and print them out.

What do you think of this, pros/cons any other ideas?
Comment 1 Wouter Wijngaards 2017-06-22 08:57:24 CEST
Hi Manu,

No.  Too slow, and it adds a library dependency.

Best regards, Wouter
Comment 2 Manu Bretelle 2017-06-22 20:36:02 CEST
Hi Wouter,

I agree it would be slower, but I think there is value on the operational side in getting more metrics easily and could be a worthwhile trade-off.

Knot seems to implement something similar [0], they may have data about how expensive it is and wether or not they find value to it.
There is also ways to have a faster implementation for the hot path (maybe that would mean keeping on using stats struct there), while still providing something more versatile for less used code path. This would also mean people could potentially add stats within their python module for instance (unless this is already available).


[0] http://knot-resolver.readthedocs.io/en/stable/modules.html#statistics-collector