### Description
I am in need to get some statistic counters related to each lcr gw currently loaded in Kamailio. Kamailio already provides the counters I need inside the KEX module with the following command: ``` kamcmd> stats.get_statistics core: core:bad_URIs_rcvd = 69 core:bad_msg_hdr = 2 core:drop_replies = 0 core:drop_requests = 8499 core:err_replies = 0 core:err_requests = 0 core:fwd_replies = 4 core:fwd_requests = 65 core:rcv_replies = 502088 ... ``` Here kamailio doing exactly what i want, it's exposing the counter data via xmlrpc which is great for attaching an external tool to build statistics. Unfortunately Kamailio KEX module is counting every single request/reply hitting the proxy server, the idea is to have the above stats related to the gateways currently loaded by the lcr module. In this way, for example I can tell how many request/replies I got from gw id X or gw id Y and produce gw based stats. Unfortunately the KEX module has no "concept" of "GW" and "LCR", so the idea is to implement the same counting logic inside LCR module. The counting should not be persistent (counters must go to zero every time kamailio restarts). When adding or deleting a new gateway, the counting in memory must reflect the status of the internal state or lcr gatewas, so, for example, after adding a new gateway and reloading lcr tables, the new counters must be immediately available through xmlrpc without a new kamailio restart. The same concept applies when the gateway is removed from the list.
### Expected behavior A possible implementation should give the user to query counters in a way similar to this: ``` # kamcmd lcr.stats { gw: { { gw_id: <id of lcr mysql table here> gw_name: <description of lcr mysql table here> requests: 0 requests_invite: 0 requests_cancel: 0 ... } { gw_id: <id of lcr mysql table here> gw_name: <description of lcr mysql table here> requests: 0 requests_invite: 0 requests_cancel: 0 ... } } } ```
Additionally, it would be helpful to set a gw id as argument in order to filter, for example:
``` # kamcmd lcr.stats 95 { gw: { { gw_id: 95 gw_name: <description of gw id 95> requests: 222 requests_invite: 1 requests_cancel: 1 requests_ack: 1 ... } } } ```
#### Actual observed behavior
To my knowledge, nothing related to this issue has been implemented in Kamailio so far
This is a feature request, something that's best discussed on the mailing list.
Have you tested what you can do with the stats and/or counters modules?
It could be probably added also in the cfg script with the mentioned modules. But I agree that it could be a good idea to provide this from the lcr module as well. Just note that if nobody steps up to implement it e.g. by creating a pull request, feature requests are closed after some time due to inactivity.
Thank you for your replies. The main point on this feature is that I need the counters to be updated whenever there is a lcr reload tables to detect a new peer. I tried implementing something inside the KEX module since it already has something similar but I soon realized it's quite complicated to do what I want inside it because the counters are declared when the module starts Changing KEX module leads to 2 problems: 1. You have to make sure the user launches LCR module BEFORE KEX (otherwise the gw list is empty) in kamailio conf file. 2. It is hard to change later, at runtime, the counters since they must be declared at start. If I call function ```register_module_stats()``` at runtime I get the following error: ``` LM_BUG("late attempt to register counter: %s.%s\n", group, name); ``` maybe there is a way to get around this? Additionally, the kex module requires to process some data coming from LCR, this is possible with some API implementation inside LCR module but... it's another complication.
I can try to submit a PL if you think this could be useful.
If you want to implement native statistics, it actually should be implemented in the module that provides the functionality and not in the kex module. So if you like to submit a PR, please add it to the lcr module. You can look to other modules (e.g. sl, usrloc etc..) to get some ideas how its implemented.
feature did dont fint its way into master, closing issue
Closed #3372 as completed.
-
Alessio Garzi -
Henning Westerholt
-
Olle E. Johansson