Hi, we’re currently trying to get a bot in production. In order to fully analyze everything we also need to map the action-server logs to certain conversations.
So the simplest way, would be to just add the sender id to every log message or create and pass a logger instance through all functions. However, this gets really ugly. Did anyone make a more general solution work?
Any other ideas to map these log messages to specific conversations are also welcome.
Hi @IgNoRaNt23, what parts of the action server do you need logs for? if they all occur in the same file you could configure the logger module to write to a log file whose name depends on the conversation ID. would that work?
I have lots of custom actions which rely on other modules over multiple files (and folders). And I basically want every log message (ofc not the ones during initialization) to be tracked down to a specific conversation.
Why did you choose (or not choose) to not carry that information into your code? For example here
is a debug statement, which does not carry information over the conversation by default. But especially in a situation with lots of different users it will hard to read the log file.
Another option would be to log the conversation ID once at the beginning of your form action, and all subsequent logs will belong that that conversation ID. would this be an option?
Alternatively you could modify the logger.debug() messages - I agree that it would in general be useful for the forms debug statements to contain the conversation IDs. If you do go ahead and make changes to those statements, feel free to create a PR on the rasa-sdk repository, and we can discuss the implementation there.
The reason why I made this thread is that having the conversation (or sender) id in all the log messages is not trivial for me. We have a working solution but I think it might not be the prettiest. If you know how to implement this easily, go ahead and tell me.
This should also not be solved at the FormAction-level but at least at the Action-level (or even deeper? There are conversation-dependant logs at the ActionExecutor-level, didnt look even deeper into the code)
I could also make a feature request at Github, but your support is a bit poor there (at least for the issues I created). So I went over to just implementing all this in my company’s code. But with a good solution, Id be willing to spent a bit of my free time to implement this.
An implementation of this would likely just be adding the conversation ID to log messages where one is available. I’ve gone ahead and created an issue on the rasa-sdk repo, and we’ll consider implementing it in the future. As before, if you’d like to propose your quick implementation as a solution to this, you’re more than welcome to. We can discuss potential changes / improvements in the PR.
Ah ok, yes ofc this is the trivial implementation. That’s not a problem at all, but having the correct ID without explicitly adding it to the debug statement or handing a specific logger over to every function is.
there are only very few calls to logger.debug() in rasa-sdk so a general solution like taking the global value of the currently-active conversation ID is not necessary
There’s tons of custom code out there, so there’s definitely also tons of logger.xyz-statements out there, which will benefit from this.
Sure, but custom code that uses the tracker should use log statements that output the conversation ID
Yep, they should. Maybe I wasn’t clear enough, but this whole topic is about getting the conversation ID into the log statements WITHOUT explicitly stating it in every single call.
And probably even into third-party log statements even though I doubt that this possible, but maybe I’m just missing something.
I see your point, although the overhead of maintaining something like that for the benefit of not having to type tracker.sender_id in custom debug messages is not justified. In general log statements may be issued outside of code that has knowledge of the conversation ID, so anything like this would probably be quite complicated
Well, tracker might not be available in all functions, so that’s one point. And while there are log messages outside of conversations, these could just show ‘None’ for the id. And in general these cases should be rare (and at least for my case should be limited to the initial loading of the action server).