WIP #1316 Lifecycle logging #1372
Conversation
Moved logging of Accumulo metadata from tablet to its own logger. This allows logging of metadata to be turned on/off independantly from tablet lifecycle events.
|
From a quick review, I like the approach. Do you have any thoughts concerning a ZooKeeper logger - used in ZooReader, ZooStore,... that could log zookeeper operations - or would that be too low level and best just done with current debug logs? |
|
I like the tidyness and uniformity. Logging can get messy but there is a loss of whether something is logged to trace, or debug, or error. Maybe it could be reflected in the method call like logger.traceTabletMutated(...) . And, I have to admit since @Manno15 and I are trying to understand the migration process for a ticket he is working being able to follow the "exact" log message back into the code is very helpful. |
I might be in favor of that. The only concern I would have is I would not want to duplicate any functionality the zookeeper client offers in terms of logging. Also, would it be better to change zookeeper to have more useful logging rather than Accumulo?
It is interesting that this code could become an accidental guide book into the most important parts of the Accumulo code. One that is always kept up to date. |
|
This PR was created for feedback. Took a first step in implementing this in #1480 |
I did some experimentation of what the structure for #1316 might look like. Sharing this experimentation for discussion only. For this PR I put the logging code in a single package intentionally. The reason for this is it would make it easy for user to look at the source code for this single package and see the important log messages Accumulo generates. Having it all in one place may also make it easier to generate a grok file for logstash, making a task like apache/fluo-muchos#254 easier.
I gave a lot of thought to the logical logger hierarchy, but its very incomplete.