With updateSettings() method you can modify the current Worker logLevel and logTags, but how can you get that messages? At first I though they were written directly to stderr, but after reading the Worker source code, and if I’ve understood it correctly, it seems in last instance logs are send to the Javascript (Rust) side (following MS_DEBUG_TAG(), ChannelSocket::SendLog() and ChannelSocket::SendImpl()) and it’s this the one printing them, but reading the docs or the code I can’t be able to find where or how capture this logs.
Is there an undocumented event or something on the client side that I can listen for them? If not, can someone point me in the code where they are being received in the Javascript side so I can add some hooks / events for them? My idea is to have multiple Worker instances sending the logs with the lowest level (debug) and later group and process and filter them on Javascript side, no matter from what Worker they came from.
In a side note, is there a way to know what actual Router instance inside a Worker has generated a log message? Maybe parsing them?
We use the debug module for debugging purposes. It’s a debugging feature rather than a logging feature. Logs are printed in JS side by debug module as usual, which is “just” a wrapper that logs to stdout or stderr. We don’t expose an API for the app to collect those logs programatically. This is on purpose. It’s not designed to be “an application logging” system.
For example, express (super famouse and widely use Node web/http framework) also uses debug module, but nobody expects express to provide the app with those logs. They are just printed. That’s exactly the same that mediasoup does.
So, if I understood it correctly, updateSettings() allow to define the debug settings of the worker, so debug messages are send to the Javascript side, and mediasoup module capture them and send them to the debug package, isn’t it? So, in this case, to capture that Worker debug messages, I need to attach myself to the debug package, isn’t it?
debug package supports defining output streams, so I can piggy-back my own function and capture the log messages. Is this the way you are suggesting me to do it?
We already use those, see Logger.ts in mediasoup. But we don’t expose it. Why? Because if we expose it next question will be: “how to parse Router/Transport/Producer id from each log?” and then we’ll be asked to do, indeed, a complete logging system and that’s not the purpose of mediasoup debugging logs.
I now I’m already doing some nasty things with Mediasoup and using undocumented fields I’m asking for that to have a mapping of all Mediasoup functionality in Mafalda SFU, and updateSettings() is the last missing one. I will not ask how to parse the IDs, I can do it myself, just wanted to know where to get the data from
BUT, if you insist so much they are only debugging logs… Are you saying, in normal conditions, I should ignore about updateSettings() method at all, since it’s only for debugging purposses (not actual logging of Workers activity), and don’t provide access to it? That would simplify me things a lot, in fact…
No. Worker logs are sent from C++ to JS via a UnixSocket pipe.
We don’t include ids in logs. It would be super convoluted. I insist those are debugging logs. They are of little value when there are tons of routers, transports, producers and consumers.
I insist
Said that, I think mediasoup provides very low level API so your app can log the result of any API method. We have also trace events that tells you about RTP, RTCP, BWE, etc. And we have stats.
As a tip, I recommend you building an “Observer” system into the app by just using worker.observerrouter.observeretc.observer and produce app logs based on them.
That code looks similar to mediasoup :: API. I’ve not builded an Observer system by itself, but yes, I’m listening to almost all that events and using it as a reference, thanks Maybe I should export that events too so Mafalda users can bind to them…
and that’s not the purpose of mediasoup debugging logs.
Maybe I should export that events too so Mafalda users can bind to them…