Open jackjansen opened 3 months ago
Actually: if you do something like a "connection number" you could report it back to the client. The client could then print it in its log file.
Then, after a session, we could download the orchestrator log and filter it on the relevant connection numbers, and we'd have all the orchestrator log that pertains to the session.
There also seems to be information missing on things that orchestrator decides to do. For example, around 09:44:50.805
I think the orchestrator decided to close the session, because the admin has left. But this isn't reflected by a log line.
And the [SENDDATA] Missing parameters
also isn't very helpful...
I get the impression that [REMOVEDATASTREAM]
only prints a message if something goes wrong (online [DECLAREDATASTREAM]
).
If we look at the log file in #32 for example there is not enough information about what was happening. At the very least there needs to be something that shows which connection this line belongs to. One possibility is to add something like
::ffff:192.168.0.1
. But if that is difficult (I don't know if you have access to that information when you print the log line) you could also give each new connection a unique "connection number".(But note that I'm using #32 here only as an example: I think that the specific error reported there doesn't have a lot to do with the orchestrator).