Log output cleanup

[zone117x]

• [x] [socket.io] ... messages should include a property to easily filter by, and most of them should be changed from info to verbose level
• [x] [stacks-node event] ... messages should include a property to easily filter by
• [x] getPagingQueryLimit error messages like 'limit' must be equal to or less than 50 are logged without any error level, these should be http-400 messages

[rafaelcr]

We should also move from winston to pino logging

[zone117x]

@csgui is this something you can take on? The migration from winston to pino that Rafael mentioned above can be done in a follow-up PR.

[csgui]

@zone117x Sure. I'll have a look. Assigning it to me.

[csgui]

Hello @zone117x and @rafaelcr !

• [socket.io] ... messages should include a property to easily filter by

Does socket.io text can't be used as a filter? I.e.: if the property message contains socket.io filter by that.

• [stacks-node event] ... messages should include a property to easily filter by

Does stacks-node event text can't be used as a filter? I.e.: if the property message contains stacks-node event filter by that.

[zone117x]

Does socket.io text can't be used as a filter? I.e.: if the property message contains socket.io filter by that.

Yes, but not easily. It's much better to have structured log properties. For example, the log metadata object for socket.io messages can have a property like {socketio: true} which could then be easily used in log tooling. Similar could be done for the stacks-node event logs. Alternatively, the log metadata object could be something like:

{
  // new property that we can start adding to log lines
  "component": "socket-io" | "stacks-node-event"
}