Improve query logging
mbard opened this issue · 3 comments
Today all the cqls are logged as Manager.logger.info with the logger com.outworkers.phantom
Which is fine for the normal case.
But I would like to have different log levels for different request.
1.
Logger.info for modifying requests
Logger.debug for get requests
2.
In my application to be able to tune the log level in different parts of my application
No 1 Could be solved by having different logger for different request
com.outworkers.phantomcom.outworkers.phantom.createcom.outworkers.phantom.selectcom.outworkers.phantom.update
...
No 2 Could be solved by setting the log level on the statement
@mbard The separate log level approach could be very problematic. The second one could perhaps be looked at, but it's a backwards incompatible change for a lot of people relying on the existing setup, so we are going to need to think hard about some way to inject the logging configuration from the user side.
At what log level would you expect to see full Cassandra queries?
I would expect to see the full cql in debug.
The idea would be to change the log level per statement.
And if there is per statement configuration of log level, there shouldnt be any problem with backward compatibility
@mbard Sorry we haven't followed up here in due course, the idea of having separate log levels for each type of query is not feasible, log levels mean something different.
At framework level, the creation of queries is also completely separate from their execution, in a free monad style approach, and there's a good reason for that. Phantom supports Scala Futures, Twitter Futures, and Monix Tasks all at the same time, so there isn't a single code path where queries get "executed", and where they could be logged.
That's why the mechanism is generic, and we log the way we do. We could potentially be able to support a logger for each query type, but this would mean incompatible breaking changes to the many thousands of codebases using phantom, and more importantly the very large enterprise customers with 100 phantom repos.
They would have to completely change their monitoring approach, which means this is not something we can effectively implement. Out of curiosity, what benefit would you get having them separate?