[SR-Users] Re: RFC: uptime metric for xhttp_prom module

Is this a variable named "xhttp_prom_stats", or the modparam key "xhttp_prom_stats"? There's already two separate parameters, right: - xhttp_prom_stats - corresponds to the rpc stats.get_statistics, thus it's argument corresponds to that RPC call - xhttp_prom_pkg_stats - Corresponds to the rpc pkg.stats, takes a Boolean argument A few thoughts: - The leading 'xhttp_prom_' prefix on the modparam key is unnecessary, since the first argument to modparam is the module itself. I point this out because if the issue is backwards compatibility, then my recommendation would be to keep 'xhttp_prom_stats' as is, and introduce a param 'stats' that can introduce new syntax in the third parameter. As an idea, the third parameter could be literally what would be passed to RPC. Not every possible RPC command would need to be implemented (many wouldn't make sense), but this would keep the syntax predictable: modparam("xhttp_prom", "stats", "corex.uptime"); ## Would provide uptime modparam("xhttp_prom", "stats", "stats.get_statistics all:") ## Same result as modparam("xhttp_prom", "xhttp_prom_stats", "all") modparam("xhttp_prom", "stats", "pkg.stats"); ## Same result as modparam("xhttp_prom", "xhttp_prom_pkg_stats", "1") - My current test env is 5.7.3, but it looks like the existing ' xhttp_prom_stats' parameter can only be declared once, thus there's no syntax for selecting multiple specific items. In other words this configuration doesn't give counters for the sl module and the core module. It only provides the counters from which ever is declared last (core in this case). modparam("xhttp_prom", "xhttp_prom_stats", "sl:") modparam("xhttp_prom", "xhttp_prom_stats", "core:") Rather than changing the existing module parameters, the new "stats" parameter could be called multiple times, so: modparam("xhttp_prom", "stats", "stats.get_statistics sl:") modparam("xhttp_prom", "stats", "stats.get_statistics core:") modparam("xhttp_prom", "stats", "pkg.stats") modparam("xhttp_prom", "stats", "corex.uptime") Would get all sl module counters, all core module counters, the uptime and the package memory stats for each child process. An advantage here is that other counters can be implemented without any real thought to syntax. For example, shared memory stats would predicably be added as: modparam("xhttp_prom", "stats", "shm.stats") -----Original Message----- From: Ovidiu Sas via sr-users <sr-users(a)lists.kamailio.org> Sent: Thursday, April 4, 2024 1:40 PM To: Henning Westerholt <hw(a)gilawa.com> Cc: Kamailio (SER) - Users Mailing List <sr-users(a)lists.kamailio.org>rg>; Ovidiu Sas <osas(a)voipembedded.com> Subject: [SR-Users] Re: RFC: uptime metric for xhttp_prom module CAUTION: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Hello Henning, I have nothing against using a single variable, except that it is confusing. It is not backward compatible. If you enable all vars, then all new stats will be enabled by default. In the current stable version, the names of the stats vars and stats groups are inherited from the "stats.get_statistics" RPC command. That's why we don't have explicit documentation for them in the README file. For the new stats we don't have a group and the stats vars have sort of arbitrary names. Having dedicated modparams for all these new stats not covered by the generic ones require a simple and clean implementation along with an easy way to switch them on and off while keeping backward compatibility. If more kamailio admin feel that we should merge them, we could :) -ovidiu On Thu, Apr 4, 2024 at 1:45 PM Henning Westerholt <hw(a)gilawa.com> wrote: -- VoIP Embedded, Inc. http://www.voipembedded.com/ __________________________________________________________ Kamailio - Users Mailing List - Non Commercial Discussions To unsubscribe send an email to sr-users-leave(a)lists.kamailio.org Important: keep the mailing list in the recipients, do not reply only to the sender! Edit mailing list options or unsubscribe: