play framework logging
TRANSCRIPT
Play Framework LoggingLogback: Logs can tell everything
Why we need logging?Monitoring
Debugging
Error Tracking
Business Intelligence
Play provides an API for logging which is accessed through the Logger object and uses Logback as the default logging engine.
Logback Logging ArchitectureDifferent components:
LoggerDefault logger named “application”
Can create our own logger
Log Level :OFF : use to turn off logging
ERROR: Runtime error, or unexpected exception
WARN: Deprecated Api, unexpected situation
INFO: Interested runtime events
DEBUG: Detailed information on the flow of system
TRACE: More detailed information
Logback Logging ArchitectureAppender
Handle responsibility to write event to component
Kinds of appender:
OutputStreamAppender: Append events to OutputStream
ConsoleAppender: Append events to console, or System.out or System.err
FileAppender: Append events to file
RollingFileAppender: Append events to file with the capability to rollover log files
Time based rolling policy
Size and time based rolling policy
Fixed window rolling policy
SocketAppender and SSLSocketAppender
SMTPAppender
AsyncAppender
Write your own Appender
Appender
Event doAppender(Event e)
DB
File
Console
Logback Logging ArchitectureEncoder
Accept events and transform these events into byte array
Write into output stream
Total control of what and when bytes gets written to the output stream
LayoutTransform an incoming event into a String
Has no control over when events get written out
Layouts can not aggregate events into batches
Encoders is to have total control of what and when bytes gets written to the output stream
FilterCapable of filtering incoming events based on specific rule
Can accept or deny events based on rule
Using LoggerImport play.Logger
Logger.debug("Result={}", result)
Never do Logger.debug(“Result=”+result), as it will do string concatenation every time without we actually adding it in log file based on Log level.
Play puts both the console and the file logger behind the logback AsyncAppender
Config file path : conf/logback.xml
Sample appender logback.xml <appender name="FILE" class="ch.qos.logback.core.FileAppender"> <file>${application.home:-.}/logs/application.log</file> <encoder> <pattern>%date [%level] from %logger in %thread - %message%n%xException</pattern> </encoder> </appender>
<appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender"> <encoder> <pattern>%coloredLevel %logger{15} - %message%n%xException{10}</pattern> </encoder> </appender>
<appender name="ASYNCFILE" class="ch.qos.logback.classic.AsyncAppender"> <appender-ref ref="FILE" /> </appender>
<appender name="ASYNCSTDOUT" class="ch.qos.logback.classic.AsyncAppender"> <appender-ref ref="STDOUT" /> </appender>
MDC: Map Diagnostic ContextHelp uniquely stamp request
Manages contextual information on a per thread basis
MDC.put(“userkey”, value)
MDC.remove(“userkey”)<appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender"> <encoder> <pattern>%coloredLevel %logger{15} %X{userkey} - %message%n%xException{10}</pattern> </encoder> </appender>
Best PracticesAlways keep date on log file name
Always add some name to your log file name, which help in distinguish it from other log files.
Always log time and date of events
Store date in YYYYMMDDHHMMSS format (ideally) as it helps in sorting.
Use 24 hour time format.
In multi threaded system, use thread id.
Use different name of logger, depending on kind of logs as that help in separation.
Add rolling of logs so they don’t grow without bound
Best PracticesLog single event in single line, stack trace kind of thing can be
multiline.
Log with a delimiter between fields so logs can be easily parsed. Don’t skip empty fields add something like - or delimiter to identify it.
Log identification information as that helps in debugging.
Don’t log sensitive information like passwords etc.
Thanks
