Closed emanuelpalm closed 4 years ago
After becoming more familiar with logging in Netty, it seems like its logging capabilities must be explicitly enabled, which means that it is very possible to replace its InternalLogger
entirely with something else.
Perhaps logging can be avoided by enabling errors to be listened for by registered callbacks? That would enable the creation of logging plugins, which would automatically listen for relevant kinds of errors and log them automatically.
@jronnberg It struck me today that logging is likely going to be a problem that will have to be solved at the Arrowhead Framework level, and not just at the library level. Being able to aggregate an analyze log information will be a vital tool for system operators to monitor and fix problems within their local clouds.
I belive @jenseliasson has been working on some kind of logging support for his DataManager? But giving the Historian service source code a brief look gave me the impression that it is made to store SenML, Excel and CSV data, rather than log entries for system operators. @jenseliasson Do you know about the state of logging in Arrowhead? I guess you, at least, should have been part of some discussions on the topic? :)
I have added and integrated SLF4J into the library, as well as making it a public part of the library API (0081ab81807494a1757db317b87c35e71d516ed5 and 7b64a690f705a09e99f97d634aeff4d638c397d3). I will close this issue after having written some documentation on arkalix.se about enabling logging.
I've moved this issue over to the website repo. I'm closing this.
While
kalix
should not force one to use any particular logging framework, there are things that will be impossible to log unless some kind of integration support is provided for arbitrary logging solutions.A possible solution is to follow the model of Netty, which uses an
InternalLogger
that is automatically plugged into whatever logging framework it detects or is explicitly attached to.Another solution would be to include SLF4J as part of the library. While it opens up for using either JUL or Log4J2, it does comes with its own learning curve and complexity, which I would like to avoid.
As of now, the following are things I discovered would be nice to log:
DEBUG
: Ignored fields in read JSON messages.I will update the list as I can come to think of more things. If you have other proposals, make a comment here and I'll include it in the list if it seems reasonable.