Upgrade from 0.58.0 to 0.59.0 removed access logs from cloudwatch

[elip-OE]

Context

Hi there!
I'm using zappa on a project for more than 3 years, so first of all thanks for your hard work!
On my last deployment, I've upgraded zappa version from 0.58.0 to 0.59.0 (python 3.8/django 4.1.9/aws lambda), and form that time I stopped from see the access logs of the HTTP server in the aws cloudwatch logs

Expected Behavior

zappa tail STAGE should show access logs

Actual Behavior

zappa tail STAGE doesn't show access log, the access logs are not available in the AWS cloudwatch

Possible Fix

Steps to Reproduce

Your Environment

• Zappa version used: 0.59.0
• Operating System and Python version: amazon/aws-lambda-python:3.8 docker
• The output of pip freeze:
• Link to your project (optional):
• Your zappa_settings.json:

[thogerb]

Hi. If helpful, I believe I experience this issue too. Upgraded requirements some days ago and discovered this morning my logs in Cloudwatch from the Zappa deployment were gone. What worked for me in the end: downgrading zappa 0.59 to 0.58 again.

Expected Behavior

When I set "log_level": "INFO" in zappa_settings, INFO log records are shown in CloudWatch for both 0.58.0 and 0.59.0

Actual Behavior

When I set "log_level": "INFO" no INFO log records are shown in CloudWatch when on 0.59.0 – but they do show on 0.58.0.

Your Environment

Zappa version used: 0.59.0 -> No INFO logs here, I did spot a WARNING log though
Zappa version used: 0.58.0 -> INFO logs show as expected

Web service type: Django 4.2

Operating System and Python version: amazon/aws-lambda-python:3.8 docker

Your zappa_settings.json: These settings might be relevant, but note that I kept them consistent for the two version

        "log_level": "INFO",
        "cloudwatch_log_level": "INFO",

Downgrading fixed my problem for now, so just reporting if the extra context is helpful 👍

[paulclarkaranz]

#1277 seems like the only logging related change in the diff in between versions. If no-one wants to dig into why this is happening perhaps that can be reverted to prevent more people pinning their zappa version?

[ceturc]

@elip-OE To work around this breaking change, you can copy the configured log_level from Zappa's handler.py into your root logger (app.py):

app = Flask(__name__)

# work around breaking change in https://github.com/zappa/Zappa/pull/1277
# by copying the log level from zappa's logger (now called "handler") up to the root logger 
zappa_log_level = logging.getLogger("handler").level
logging.getLogger().setLevel(zappa_log_level)

logging.info("This log message should appear in the Lambda cloudwatch logs if Zappa's log_level=INFO")

This change in #1277 is no longer setting the root log level from the zappa_settings log_level. This change also broke my application: my logs were all missing after upgrading to 0.59.0.

The system now sets the log_level on a child logger called handler, because handler.py is invoked by lambda from the root the packaged ZIP file.

Previously, the system would set the log_level for the root logger, which is behavior all my apps rely on. This means the root logger is probably still defaulting to logging.WARNING, not a more verbose level that you may have specified in zappa_settings log_level.

Thanks to @paulclarkaranz for pointing out the P/R that introduced the breaking change.

I doubt that PR #1277 was intended to be a breaking change, but for all of us that use logging.info() in our app code (root logger), with Zappa's log_level="INFO", the change caused all of our logs to disappear, because Zappa is no longer setting the root log level.

[elip-OE]

Thanks @ceturc that worked great!

[ceturc]

Idea to resolve this for a broader audience: restore the previous behavior of setting the root logger level. I like the work done in #1277 and simply want to restore the old feature of setting the root logger level. If there's interest in this approach, I'll prepare a P/R for it.