Support structured JSON logging for errors about aws-lambda-go

[bmoffatt]

Need to play with it a bit! :)

• Implementation: Not sure if a special log writer needs to be implemented to make Lambda recognize the levels, or if there's magic that makes it work out of the box parsing standard out. Ref Java: https://github.com/aws/aws-lambda-java-libs/blob/main/aws-lambda-java-runtime-interface-client/src/main/java/com/amazonaws/services/lambda/runtime/api/client/logging/FramedTelemetryLogSink.java
• Design: Not sure if the current built in log.Println and log.Fatal should match the AWS_LAMBDA_LOG_LEVEL (end thus always be present), or have their level defaulted to INFO, and be configurable via like StartWithOptions(..., lambda.WithLogLevel(...))
• Design: Ditto for AWS_LAMBDA_LOG_FORMAT. Leaning towards lambda.WithLogFormat(...) for backwards compat sake. And then there's ensuring that whatever the JSON format for errors looks like is consistent with the other runtimes

[bensie]

Thanks for taking a peek!

Not sure if a special log writer needs to be implemented to make Lambda recognize the levels

Nothing special is required - as long as level is a top-level JSON key in an entry from standard out, it will omit logs based on the function's AWS_LAMBDA_LOG_LEVEL setting. So you can (technically) spew all kinds of debug logging that just won't make it to CloudWatch Logs if you're set to error level. In app logs that can get expensive though if you're debug logging massive structs as JSON or whatever, so in my code above I'm passing the AWS_LAMBDA_LOG_LEVEL to slog, which is smart about bailing early before calling MarshalJSON on log args.

Not sure if the current built in log.Println and log.Fatal should match

I'm not sure about that either. It's really only an issue if those calls are / can be expensive, but I didn't see it doing anything substantial except for panic recovery and trace info, which is exactly what I'm hoping to get here.

And then there's ensuring that whatever the JSON format for errors looks like is consistent with the other runtimes

There's a doc - scroll to the "JSON format for application logs" section - they detail how the shape looks in the managed runtimes (don't even get me started on time vs timestamp being different between the platform and application logs, come on!). There's also a "Application log-level filtering with custom runtimes" section on that same page I can't link directly to with the ENV var stuff.