@anmartan pushed 1 commit. 52277d9b74e6ba2973ecaa0163a49be54bdd5454 core: add support for custom log function -- View it on GitHub: https://github.com/kamailio/kamailio/pull/3902/files/411b3c9fa3157437a0973c… You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/pull/3902/before/411b3c9fa3157437a0973cf66ee47fc6096b4e21/after/52277d9b74e6ba2973ecaa0163a49be54bdd5454(a)github.com>

@anmartan pushed 1 commit. 2ecd44410be96c441f137a0c02ffe47a51f20fd9 --amend -- View it on GitHub: https://github.com/kamailio/kamailio/pull/3902/files/52277d9b74e6ba2973ecaa… You are receiving this because you are subscribed to this thread. Message ID: <kamailio/kamailio/pull/3902/before/52277d9b74e6ba2973ecaa0163a49be54bdd5454/after/2ecd44410be96c441f137a0c02ffe47a51f20fd9(a)github.com>

Hi @miconda , thanks for your feedback! Regarding `ksr_logdata_t`, most likely it got flagged by some static checker, but we've re-tested the original version and couldn't pin-point which exact check/rule triggered this. Regarding the `asprintf` - thanks for spotting the memory leak! We've never detected it using our memory checkers since we never actually use the default stub continuously - it always gets replaces when our custom module is initialised. The benefits of being able to control the output format of the logs are mainly evident when Kamailio is used in a deployment alongside other products/tools, all of which are generating their logs using a common scheme. Thus, being able to control Kamailio log output scheme helps to: 1. keep the log collection/processing pipeline manageable (since all logs flowing through it share a common scheme) 2. reduce the developer cognitive load from having to switch to different log formats during development stage (not dealing with production logs from log pipeline but with direct Kamailio output) Here's a sample output made possible with the help of this patch: (scheme used: `<pname> <ver> <timestamp> <lvl> <mname> <pid>:<file>:<line> <msg>`) ``` pname 1.35.15 2024-06-20T10:43:24.134886Z WARNING pname 13:libpname/core.cpp:85 Core successfully created! pname 1.35.15 2024-06-20T10:43:24.135058Z INFO tls 13:tls_mod.c:445 use OpenSSL version: 30000070 pname 1.35.15 2024-06-20T10:43:24.135079Z INFO tls 13:tls_mod.c:447 With ECDH-Support! pname 1.35.15 2024-06-20T10:43:24.135096Z INFO tls 13:tls_mod.c:450 With Diffie Hellman pname 1.35.15 2024-06-20T10:43:24.135166Z WARNING tls 13:tls_init.c:980 openssl bug #1491 (crash/mem leaks on low memory) workaround enabled (on low memory tls operations will fail preemptively) with free memory thresholds 11534336 and 5767168 bytes pname 1.35.15 2024-06-20T10:43:24.135203Z INFO core 13:core/cfg/cfg_ctx.c:589 tls.low_mem_threshold1 has been changed to 11534336 pname 1.35.15 2024-06-20T10:43:24.135223Z INFO core 13:core/cfg/cfg_ctx.c:589 tls.low_mem_threshold2 has been changed to 5767168 ... pname 1.35.15 2024-06-20T10:43:24.136142Z INFO tls 13:tls_mod.c:491 Loading SSL_CTX in process_no=0 rank=-127 ksr_tls_threads_mode=0 pname 1.35.15 2024-06-20T10:43:24.136176Z INFO tls 13:tls_domain.c:353 TLSs<default>: tls_method=23 pname 1.35.15 2024-06-20T10:43:24.136200Z INFO tls 13:tls_domain.c:365 TLSs<default>: certificate='/usr/local/lib/pname/certs/serv.crt' ... pname 1.35.15 2024-06-20T10:43:33.612026Z TRACE pname 16:libpname/log/trace_object.hpp:19 Create > binding::SipMsg() pname 1.35.15 2024-06-20T10:43:33.612093Z TRACE pname 16:libpname/binding/sip_msg.cpp:645 Call > binding::SipMsg::getCallId() pname 1.35.15 2024-06-20T10:43:33.612136Z TRACE pname 16:libpname/log/logger.cpp:100 Call > zroute::Logger::setTraceId("3811ef5eb36d7024f1f3e7bfaf70e572") pname 1.35.15 2024-06-20T10:43:33.612194Z INFO pname 16:/usr/local/etc/pname/./route.cfg:11 TraceID[3811ef5eb36d7024f1f3e7bfaf70e572] Processing "INVITE" request received from "sip:10.22.10.9:5060" [Call-Id: &quot;8t1b49///1-94(a)10.22.10.9&quot;] pname 1.35.15 2024-06-20T10:43:33.612218Z INFO debugger 16:debugger_api.c:351 TraceID[3811ef5eb36d7024f1f3e7bfaf70e572] request_route=[DEFAULT_ROUTE] c=[/usr/local/etc/pname/./route.cfg] l=12 a=25 n=MYLOG_DBG pname 1.35.15 2024-06-20T10:43:33.612244Z TRACE pname 16:libpname/log/logger.cpp:110 TraceID[3811ef5eb36d7024f1f3e7bfaf70e572] Call > zroute::Logger::isTraceIdSet() pname 1.35.15 2024-06-20T10:43:33.613788Z DEBUG pname 16:/usr/local/etc/pname/././invite.cfg:2 TraceID[3811ef5eb36d7024f1f3e7bfaf70e572] Received INVITE request, routing pname 1.35.15 2024-06-20T10:43:33.612266Z DEBUG pname 16:/usr/local/etc/pname/./route.cfg:12 TraceID[3811ef5eb36d7024f1f3e7bfaf70e572] INVITE sip:test@example.com SIP/2.0 ``` -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/3902#issuecomment-2208661203 You are receiving this because you are subscribed to this thread. Message ID: &lt;kamailio/kamailio/pull/3902/c2208661203(a)github.com&gt;

I had no time for a proper review, it seems rather important change considering that logging is critical component. Does it affect in any way the modules `log_custom` or `log_systemd`? Maybe other can review as well and make remarks on this change. -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/3902#issuecomment-2235915993 You are receiving this because you are subscribed to this thread. Message ID: &lt;kamailio/kamailio/pull/3902/c2235915993(a)github.com&gt;

This PR is stale because it has been open 6 weeks with no activity. Remove stale label or comment or this will be closed in 2 weeks. -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/3902#issuecomment-2319752277 You are receiving this because you are subscribed to this thread. Message ID: &lt;kamailio/kamailio/pull/3902/c2319752277(a)github.com&gt;

I will look into it in more details soon, summer holidays kept me out of the office quite a lot. It would be good to find a way to have a single framework that works for all logging related modules, like `log_custom` or `log_systemd` (maybe these modules can be adapted to the way proposed by this patch, if it offers more flexibility that the existing one). -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/3902#issuecomment-2320640758 You are receiving this because you are subscribed to this thread. Message ID: &lt;kamailio/kamailio/pull/3902/c2320640758(a)github.com&gt;

@miconda thanks for looking into this! Indeed it seems that structured logging takes care of most of our needs. But I'm not sure whether it would allow us to do uniform logging from config files. Let me explain: right now we're using custom log function from the PR and we're "manually" resolving `$cfg(file)`/`$cfg(line)` PVEs and feeding them into the log handler. I haven't seen such functionality in `dprint.c/.h` nor there seems to exist a version of `LOG_XX` macro that would allow to inject that data. I suppose we could completely bypass `LOG_XX` macros and call the `_ksr_slog_func` function manually by passing it manually constructed `ksr_logdata_t` structure, although that could lead to some hard to catch bugs if the logger type is ever changed. How feasible is it to create another version of `LOG_XX` (for example `LOG_SD`, short for "source data") that takes source file and line number as arguments? -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/3902#issuecomment-2337964838 You are receiving this because you are subscribed to this thread. Message ID: &lt;kamailio/kamailio/pull/3902/c2337964838(a)github.com&gt;

I understand, my question was about the possibility of adding a flavour of the `LOG_XX` macro that takes file/line as arguments and populates the slog structure rather than always using `__FILE__`/`__LINE__`. One example for such use-case would be custom config logging commands that extract executed config file's name/line from PVEs and pass the to the new `LOG_XX` macro for the nearly identical logging behaviour regardless of whether logs are generated from CFG or C code. -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/3902#issuecomment-2338448175 You are receiving this because you are subscribed to this thread. Message ID: &lt;kamailio/kamailio/pull/3902/c2338448175(a)github.com&gt;

That is right. Thanks! I'll try to submit another PR with improvements to the `LOG_XX` macro as mentioned above for a uniform logging entry point. -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/3902#issuecomment-2357801480 You are receiving this because you are subscribed to this thread. Message ID: &lt;kamailio/kamailio/pull/3902/c2357801480(a)github.com&gt;

Closed #3902. -- Reply to this email directly or view it on GitHub: https://github.com/kamailio/kamailio/pull/3902#event-14410454366 You are receiving this because you are subscribed to this thread. Message ID: &lt;kamailio/kamailio/pull/3902/issue_event/14410454366(a)github.com&gt;