<!-- Kamailio Pull Request Template -->
<!-- IMPORTANT: - for detailed contributing guidelines, read: https://github.com/kamailio/kamailio/blob/master/.github/CONTRIBUTING.md - pull requests must be done to master branch, unless they are backports of fixes from master branch to a stable branch - backports to stable branches must be done with 'git cherry-pick -x ...' - code is contributed under BSD for core and main components (tm, sl, auth, tls) - code is contributed GPLv2 or a compatible license for the other components - GPL code is contributed with OpenSSL licensing exception -->
#### Pre-Submission Checklist <!-- Go over all points below, and after creating the PR, tick all the checkboxes that apply --> <!-- All points should be verified, otherwise, read the CONTRIBUTING guidelines from above--> <!-- If you're unsure about any of these, don't hesitate to ask on sr-dev mailing list --> - [X] Commit message has the format required by CONTRIBUTING guide - [X] Commits are split per component (core, individual modules, libs, utils, ...) - [X] Each component has a single commit (if not, squash them into one commit) - [X] No commits to README files for modules (changes must be done to docbook files in `doc/` subfolder, the README file is autogenerated)
#### Type Of Change - [X] Small bug fix (non-breaking change which fixes an issue) - [ ] New feature (non-breaking change which adds new functionality) - [ ] Breaking change (fix or feature that would change existing functionality)
#### Checklist: <!-- Go over all points below, and after creating the PR, tick the checkboxes that apply --> - [X] PR should be backported to stable branches - [X] Tested changes locally - [ ] Related to issue #XXXX (replace XXXX with an open issue number)
#### Description <!-- Describe your changes in detail --> usrloc generated statistics (contacts, expires, users) contain "-" in their names (usrloc-contacs and so on), which is not valid according to prometheus naming convention. You can view, comment on, or merge this pull request online at:
https://github.com/kamailio/kamailio/pull/2304
-- Commit Summary --
* usrloc: change "-" for "_" in stats name to be prometheus compliant
-- File Changes --
M src/modules/usrloc/udomain.c (2)
-- Patch Links --
https://github.com/kamailio/kamailio/pull/2304.patch https://github.com/kamailio/kamailio/pull/2304.diff
Have anyone noticed use of `-` instead of `_` in other places/modules? If we do it, better doing it for all.
Then wondering if we should do this via some config option (maybe a global param) to set the separator char for these stats, so we have a way to let people use older name in case this change is going to break their exisiting monitoring apps.
I've spot the same usage in p_usrloc and ims_usrloc_pcscf modules (they both derived from usrloc). I didn't notice any other module building "derivate" stats (as those), so I'm not sure that implementing a global param is worth in this case.
@grumvalski pushed 1 commit.
2fe0378c3d0596e30d8ec9ea4cb7d828321d2030 p_usrloc, ims_usrloc_pcscf: change "-" for "_" in stats name to be prometheus compliant
With the global parameter I was thinking of the cases when someone has already a monitoring/admin tool using existing stats names, practically this change will break them, requiring to update them as well, which is not always easy.
What you can do is to add a define in `core/config.h`, like:
``` #define KSR_STATS_NAMESEP '_' ```
Use it across those modules/patches and later I can add a global config param to replace it, if considered useful.
@grumvalski pushed 2 commits.
4357b5e6be2a71a401e9d53c43e787b9bfcc8ed0 core: define KSR_STATS_NAMESEP for stats name separator 0595795c659f6af586e63837efe56b45808cd735 ims_usrloc_pcscf, p_usrloc, usrloc: use KSR_STATS_NAMESEP for stats names
It can be merged. Then I will add the global parm to set this char. The question is what to make the default, the old dash/minus `-` (for backwards compatibility); or underscore `_`, the new proposal in this PR.
my vote is use `Prometheus` format "_".
I can find some time in the next days to implement the global param. I'd also go for prometheus format by default.
If you want to merge it now, I can add quickly what is needed to have the global parameter in the interpreter, as I am familiar with lex/yacc and then you can do further adjustments, if you need. Waiting that you do everything is more than fine for me, as well.
@grumvalski pushed 1 commit.
3203a6572b874d191c3be61519853005bd5ab056 core: new core parameter stats_name_separator
@grumvalski - I think it makes no sense to added to the `cfg_group_core / default_core_cfg` structure, because that is for parameters that can be changed at runtime. But, imo, this is not set once and actually use only during startup, when the stats names are exported.
It can simply be a global variable like `int ksr_tcp_accept_hep3=0;`. It can be added to src/core/counters.c and exposed with extern in src/core/globals.h.
The cfg_group_* structures work as a block and making them larger without a reason should be avoided.
In the future probably we should create some structures for global attributes grouped per purpose, so instead of many individual global variables, there will be a few global structure.
As a side node, I would recommend using the `ksr_` prefix for global variables in the core, recently I encounter some issues with global variables being cross visible between object files, so db_mode of permissions module was inherited by usrloc module. Apparently some compilers (or operating systems) build libraries with visibility for all symbols, without adding any prefix.
@grumvalski pushed 1 commit.
9948696fd84605919e6ce6a7106099f1cdd0de98 core: remove stats_name_separator from cfg_group_core
Right, I realized after doing it. I've pushed the new suggest implementation.
OK to merge it. Do not forget to add docs in the core cookbook wiki.
Thanks Daniel, documentation added to the wiki.
Merged #2304 into master.