Skip to content
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

Feat!: remove log4j #995

Closed
wants to merge 7 commits into from
Closed

Feat!: remove log4j #995

wants to merge 7 commits into from

Conversation

jeromevdl
Copy link
Contributor

@jeromevdl jeromevdl commented Nov 22, 2022

Issue #, if available: #965

Description of changes:

  • Remove log4j as the de facto logging library
  • Replace with SLF4J to give the ability to choose a logging framework
  • Creation of 2 new modules (logging-log4j and logging-logback). These modules provide logging implementation. Others can be created (reload4j, JUL, ...), depending on the demand.
  • logged fields now match python and typescript versions (ex: function_name, cold_start, ... instead of functionName, coldStart) to simplify searching and troubleshooting across different runtimes (see Consistent log keys across all runtimes #752).

Developer experience

The developer experience doesn't change that much. Instead of using the logging module, developers need to add the implementation module (logging-logback, logging-log4j, ...) which has a dependency on the logging module.

Ex:

        <dependency>
            <groupId>software.amazon.lambda</groupId>
            <artifactId>powertools-logging-logback</artifactId>
            <version>1.12.3</version>
        </dependency>

Then they need to have the proper config file (log4j2.xml or logback.xml).

  • log4j2 is relying on the same mechanism as v1, using a JsonTemplateLayout. Two layout.json files are provided (standard and ECS). This can be extended. Developers can also choose to remove some fields generated by powertools or to rename them. The Resolver is more granular (each field is accessible). See the LambdaJsonLayout.json or LambdaEcsLaout.json.
<?xml version="1.0" encoding="UTF-8"?>
<Configuration>
    <Appenders>
        <Console name="JsonAppender" target="SYSTEM_OUT">
            <JsonTemplateLayout eventTemplateUri="classpath:LambdaJsonLayout.json" />
        </Console>
    </Appenders>
    <Loggers>
        <Root level="info">
            <AppenderRef ref="JsonAppender"/>
        </Root>
    </Loggers>
</Configuration>
  • logback is relying on encoders. Two encoders are provided (LambdaJsonEncoder and LambdaEcsEncoder). They don't rely on any external dependency (json, elastic) to reduce the size of the final package. We can probably go further in the customization here (for example having an 'excludeFields' attribute to remove some of the fields or an 'includeFields' to only select a few ones:
<configuration>
    <appender name="JsonAppender" class="ch.qos.logback.core.ConsoleAppender">
        <encoder class="software.amazon.lambda.powertools.logging.LambdaJsonEncoder" />
    </appender>

    <root level="INFO">
        <appender-ref ref="JsonAppender" />
    </root>
</configuration>

Checklist

  • [] Meet tenets criteria
    ==> this version will not be backward compatible. Several changes are required from the developer, and it comes with several changes (field names)
    ==> but it comes with a more standard way of logging (slf4j) and does not force a specific framework. It is also a bit more open for extension.
  • Update tests
    ==> not fully, wanted to share the DX first.
  • Update docs
    ==> not yet, wanted to share the DX first.
  • PR title follows conventional commit semantics

Breaking changes

  • Need to import one of the logging implementations (in mvn/gradle), rather than the logging module.
  • Logged fields are now using snake_case, to match Python and Typescript versions.
  • This new version logs less information than before (to match Python and Typescript versions and also to reduce the cloudwatch logs size). Note that with the log4j implementation, it is possible to extend and add fields (using resolvers). Would be great to provide an equivalent for logback.
  • Developer needs to use Logger and LoggerFactory from SLF4J instead of log4j implementations.

RFC issue #: #965, #752

  • Migration process documented
  • Implement warnings (if it can live side by side)

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

@jeromevdl
Copy link
Contributor Author

@pankajagrawal16 I'd like to get your thought on this one if you have some time.

@pankajagrawal16
Copy link
Contributor

@pankajagrawal16 I'd like to get your thought on this one if you have some time.

👍 I can give it a look sometime this week.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
needs-more-information RFC size/XXL status/staged-major-release This change will go with the next major release v2 Version 2
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants