[Feature request]: fine grained controller over log_level on log_namespace

[sjorge]

Is your feature request related to a problem? Please describe

Currently we can configure the log_level which will be applied to all namespace.

Describe the solution you'd like

Being able to configure a log_level on a namespace level, maybe we can do what samba does: https://wiki.samba.org/index.php/Configuring_Logging_on_a_Samba_Server#Setting_Individual_Log_Levels_for_Debug_Classes

Describe alternatives you've considered

Having a way to exclude certain namespace from being logged would also work but would ultimately be less flexible. The samba approach seems far more useful and flexible.

Additional context

This is not very flexible at times, when adding/debugging devices I might want to see what z2m is doing, so I want debug logging. Now this includes also a lot of zh:* namespace, especially zh:zstack:* is very verbose. Which is great when trying to debug stuff at that level but that ius not always needed. And it makes finding the useful messages from z2m namespace difficult.

[Nerivec]

I don't believe winston supports this. It would have to be implemented entirely. There are performance considerations with anything that would loop, every time a line is logged, to match strings, regexes, etc.

The filtering of the logs can be done with a couple of shortcuts in vscode though. Select the desired namespace to remove (to the desired depth), ctrl+shift+l ("select all occurrences") then left arrow or right arrow (to get a simple cursor on each line), then ctrl+x to remove all these lines. Can even ctrl+z to bring them back. 😉

[sjorge]

Doesn’t help much when not using vscode and you need to leave logging on for a long time to catch the events.There do seem to be modules that would allow this though https://www.npmjs.com/package/winston-namespaceI guess the current namespacing doesn’t use something like this.~ sjorgeOn 29 Apr 2024, at 19:54, Nerivec @.***> wrote: I don't believe winston supports this. It would have to be implemented entirely. There are performance considerations with anything that would loop, every time a line is logged, to match strings, regexes, etc. The filtering of the logs can be done with a couple of shortcuts in vscode though. Select the desired namespace to remove (to the desired depth), ctrl+shift+l ("select all occurrences") then left arrow or right arrow (to get a simple cursor on each line), then ctrl+x to remove all these lines. Can even ctrl+z to bring them back. 😉

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: @.***>

[Nerivec]

Namespacing is doable with a simple string passed as metadata to winston, so a package for this would be overkill.

I guess we could do something regex-based, limited to debug level, that shouldn't be too bad for performance:

        // TODO: settings.get().advanced.log_debug_skip_namespaces;
        const debugSkipNamespaces = [
            '^zhc:legacy:fz:(tuya|moes)', // ignore tuya.* or moes.* below fz
            '^zh:ember:uart:', // ignore below `uart`
            '^zh:controller', // ignore `controller` and below
        ];
        this.debugSkipNamespaceRegex = debugSkipNamespaces.length ? new RegExp(debugSkipNamespaces.join('|')) : null;

    public debug(message: string, namespace: string = 'z2m'): void {
        if (this.level !== 'debug') {
            return;
        }
        if (this.debugSkipNamespaceRegex?.test(namespace)) {
            return;
        }

        this.logger.debug(message, {namespace});
    }

Would require an extra yaml setting. Not sure about frontend support though (to be able to edit said array without restarting z2m).

---

Doesn’t help much when not using vscode and you need to leave logging on for a long time to catch the events.

I just used vscode as reference. All major editors should have some way to do this; multi-cursor support is pretty much mandatory nowadays. Though you can hit the multi-cursor limit sometimes, if it's a large log file (10k by default in vscode, can be changed), and have to repeat said operation.

[sjorge]

The small overhead of the regex is probably worth it IMHO, especially if we can avoid it in the default case of not filtering.

I guess this could also just be an ENV var like we had before the rework to get debugging info out zh, which was not included by default. So basically the reverse but slightly more finegrained like with the regex change.