-
Notifications
You must be signed in to change notification settings - Fork 474
Add Message Prefix for File deletion actions in GCRun #3745
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Changes the logger name and removes the space and "class" info from the name. Moves the datalevel to the end of the logger name to ensure it shows up in log messages.
Adds a separate logger for file deletion operations in the Garbage Collector.
Co-authored-by: EdColeman <dev1@etcoleman.com>
Adds a message prefix instead which can be picked up by a regexFilter.
|
I did some more work and decided to change my direction and switch to adding the prefix in the message body. The additional logger work is still under commit d083506 |
| public class GCRun implements GarbageCollectionEnvironment { | ||
| // loggers are not static to support unique naming by level | ||
| private final Logger log; | ||
| private static String fileActionPrefix = "FILE-ACTION:"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure why we need this variable. You could just add "FILE-ACTION" at the beginning of each log message. The only reason to make it a variable is in the case that you think it would change in a future version.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My opinion: having it makes it explicit and also easier to track down with a show usages if ever need. And if it was me, making sure its spelt the same everywhere ;-)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@EdColeman you and I had the exact same thought on this.
I had created it as a variable to ensure that misspelling did not occur between log messages since this would be utilized by a regex.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since it's used in so many places, it probably makes sense to keep it as a variable. But, it should be final:
| private static String fileActionPrefix = "FILE-ACTION:"; | |
| private static final String fileActionPrefix = "FILE-ACTION:"; |
Also, I'm not sure if "FILE-ACTION:" is a great prefix, or if we need it at all... isn't the Logger name distinct enough to filter on?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There is a desire to filter GC logs further and only select log messages related to the deletion of a file.
This prefix standardizes the log messages related to file deletions and allows them to be easily selected.
I used FILE-ACTION as an attempt to make it generic as opposed to sometime tightly linked to DELETE.
If you have a different suggestion I'm open to it.
|
Using thread context / mdc might be something that we would want to explore in general, For a 2.1 release, it may not be the best time to introduce it. If I recall, there are subtleties with clearing the mdc stack (like lock / unlock semantics?) and sometimes using local variables? Again, not sure, and I think I was considering what it would look like for scans / bulk imports where transaction id or other "per user / thread" could provide additional insight, so might not apply here? It been awhile since I last looked. |
|
slf4j supports passing the MDC implementation to the underlying logging system, but has no direct support for MDC. If the log layout format has to be modified, is there a possibility that user established 2.1 log parsing may break between 2.1.x versions? References: |
With the use of a message prefix, the datalevel does not need to be appended directly to the GCRun class name. This was only done to ensure the current precision specifier did not hide relevant information from the logs.
| public class GCRun implements GarbageCollectionEnvironment { | ||
| // loggers are not static to support unique naming by level | ||
| private final Logger log; | ||
| private static String fileActionPrefix = "FILE-ACTION:"; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since it's used in so many places, it probably makes sense to keep it as a variable. But, it should be final:
| private static String fileActionPrefix = "FILE-ACTION:"; | |
| private static final String fileActionPrefix = "FILE-ACTION:"; |
Also, I'm not sure if "FILE-ACTION:" is a great prefix, or if we need it at all... isn't the Logger name distinct enough to filter on?
Remove redundant `e.getMessage()` in log message Co-authored-by: Christopher Tubbs <ctubbsii@apache.org>
Co-authored-by: Christopher Tubbs <ctubbsii@apache.org>
Original Ticket Contents
This change allows easy logging targeting by putting all file deletion actions into a separate logger.
This approach was chosen because log4j2 regexFilters only work against the message body.
That solution would work as long as log messages were written in a specific format with no validation.
By using a completely separate logger, the contents of the log message don't matter.
Instead, as long as the correct logger is used, the contents can be targeted fairly easily.
This logger is created under the existing GCRun prefix, so any logging targeting the GCRun class should still work.
This change allows easy logging targeting by grouping all file deletion actions under a common prefix.
Adding a message prefix is a much smaller scoped change that is better suited to a 2.1.x release.
How to Test
I added the following changes to the
test/src/main/resources/log4j2-test.propertiesfile.Original Test Contents
These changes setup a separate appender, then create 3 specific loggers to pull those file deletion messages together.
These changes create a new appender with a regex filter set to deny message that don't match "FILE-ACTIONS:"
Then the appender is added to the rootLogger
When running the
org.apache.accumulo.test.functional.GarbageCollectorIT, from the root of the repo directory, the filetest/target/test-gc-actions.logis created and contains the file deletion messages from the GC.The file deletions are also still present in the main
SimpleGarbageCollector_<id>.outlogs