Thanks to visit codestin.com
Credit goes to github.com

Skip to content

v2.4.0

Latest
Latest
Compare
Choose a tag to compare
@github-actions github-actions released this 09 Sep 15:25
· 1 commit to refs/heads/main since this release
v2.4.0
3f51c39

Summary

We are excited to announce a new feature in Logger: Logger buffering. This new feature allows you to buffer logs for a specific invocation, and flush them automatically on error or manually as needed.

We also added GraalVM support for CloudFormation and Idempotency utilities, expanding native compilation capabilities for better performance and reduced cold start times.

⭐️ Thanks to @ConnorKirk, @aryannikhil, and @kjswaruph for their first-time contributions to this release!

New Log Buffering feature

Docs

You can now enable log buffering by configuring the BufferingAppender in your logging configuration. This feature allows you to:

  • Buffer logs at the WARNING, INFO, and DEBUG levels
  • Automatically flush logs on error or manually as needed
  • Reduce CloudWatch costs by decreasing the number of emitted log messages
public class PaymentFunction implements RequestHandler<APIGatewayProxyRequestEvent, APIGatewayProxyResponseEvent> {

    private static final Logger LOGGER = LoggerFactory.getLogger(PaymentFunction.class);

    @Logging
    public APIGatewayProxyResponseEvent handleRequest(final APIGatewayProxyRequestEvent input, final Context context) {
        LOGGER.debug("Processing payment");  // this is buffered
        LOGGER.info("Payment validation complete");  // this is not buffered
        
        LOGGER.error("Payment failed");  // this will flush the buffer automatically
        
        return new APIGatewayProxyResponseEvent().withStatusCode(500);
    }
}

Configuration options

Log buffering is configured through your logging framework configuration (Log4j2 or Logback) using the BufferingAppender:

Option Description Default
maxBytes Maximum size of the buffer in bytes 20480
bufferAtVerbosity Minimum log level to buffer (more verbose levels are also buffered) DEBUG
flushOnErrorLog Whether to flush buffer when an error is logged true

When log buffering is enabled, you can use the @Logging annotation with flushBufferOnUncaughtError = true to automatically flush the buffer when an uncaught exception occurs. This enables you to have detailed logs from your application when you need them the most.

Here is an example log4j2.xml configuration:

<?xml version="1.0" encoding="UTF-8"?>
<Configuration>
    <Appenders>
        <Console name="JsonAppender" target="SYSTEM_OUT">
            <JsonTemplateLayout eventTemplateUri="classpath:LambdaJsonLayout.json" />
        </Console>
        <BufferingAppender name="BufferedJsonAppender" 
                           maxBytes="20480" 
                           bufferAtVerbosity="DEBUG" 
                           flushOnErrorLog="true">
            <AppenderRef ref="JsonAppender"/>
        </BufferingAppender>
    </Appenders>
    <Loggers>
        <Root level="DEBUG">
            <AppenderRef ref="BufferedJsonAppender"/>
        </Root>
    </Loggers>
</Configuration>

Buffering FAQs

Q: Does the buffer persist across Lambda invocations?
A: No. Each Lambda invocation has its own buffer. The buffer initializes when the Lambda function is invoked and clears after function completion or manual flushing.

Q: Are my logs buffered during cold starts?
A: No. We never buffer logs during cold starts to ensure all logs from this phase are immediately available for debugging.

Q: How can I prevent log buffering from consuming excessive memory?
A: You can limit the size of the buffer by setting the maxBytes option in the BufferingAppender configuration. This will ensure that the buffer does not grow indefinitely and consume excessive memory.

Q: What happens if the log buffer reaches its maximum size?
A: Older logs are removed from the buffer to make room for new logs. This means that if the buffer is full, you may lose some logs if they are not flushed before the buffer reaches its maximum size. When this happens, we emit a warning when flushing the buffer to indicate that some logs have been dropped.

Q: What timestamp is used when I flush the logs?
A: The timestamp preserves the original time when the log record was created. If you create a log record at 11:00:10 and flush it at 11:00:25, the log line will retain its original timestamp of 11:00:10.

Q: What happens if I try to add a log line that is bigger than max buffer size?
A: The log will be emitted directly to standard output and not buffered. When this happens, we emit a warning to indicate that the log line was too big to be buffered.

Q: What happens if Lambda times out without flushing the buffer?
A: Logs that are still in the buffer will be lost. If you are using the log buffer to log asynchronously, you should ensure that the buffer is flushed before the Lambda function times out. You can do this by calling the PowertoolsLogging.flushBuffer() method at the end of your Lambda function.

Changes

📜 Documentation updates

  • docs: Rename wrong POWERTOOLS_DISABLE_METRICS to correct POWERTOOLS_M… (#2043) by @phipag

This release was made possible by the following contributors:

@ConnorKirk, @aryannikhil, @dreamorosi, @kjswaruph, @phipag, @sthulb

Contributors

sthulb, phipag, and 4 other contributors
Assets 2
Loading