Add support for lambda advanced logging controls

[bnusunny]

https://aws.amazon.com/blogs/compute/introducing-advanced-logging-controls-for-aws-lambda-functions/

Additional details here:

Application log-level filtering with custom runtimes
When you configure application log-level filtering for your function, behind the scenes Lambda sets the application log level in the runtime using the AWS_LAMBDA_LOG_LEVEL environment variable. Lambda also sets your function's log format using the AWS_LAMBDA_LOG_FORMAT environment variable. You can use these variables to integrate Lambda advanced logging controls into a custom runtime.

For the ability to configure logging settings for a function using a custom runtime with the Lambda console, AWS CLI, and Lambda APIs, configure your custom runtime to check the value of these environment variables. You can then configure your runtime's loggers in accordance with the log format and log levels you select.

[calavera]

If we want to do this, it might be necessary for us provide some higher level functions to configure tracing_subscriber. By default, tracing_subscriber doesn't compile with support for JSON logs, and we would not be able to use the format variable without that support. We could expose an initializer for tracing like this:

fn main() {
  lambda_runtime::tracing::init();
  ...
}

However, it makes me wonder if we should create a different crate for utilities which could evolve into a similar concept than Lambda's PowerTools.

[bnusunny]

Yeah, I vote for a separate lambda-powertools-rs crate.

Copy @heitorlessa. This could be a good time to cooperate.

[heitorlessa]

Hey Harold, ping me mid this week for a call - I've got another idea we can do progressively to limit supply chain risks here.

---

Why this is hard and not sustainable.

We haven't received investments (read: headcount) for a Rust implementation of Powertools for AWS Lambda. We would need a minimum of 2 to do this to meet the high bar docs quality, security, ops excellence, tenets, and the trademark we hold.

Non-intrusive usage tracking is the second impediment - main reason we didn't do Golang (much higher demand than Rust at the moment)

There is an alternative route that won't publish a crate but use Rust for a better purpose -- interop with Python and NodeJS. Maybe Java and .NET if proven stable too.

I've got some candidates for an experiment in this area. If successful, it's a low risk to do one at a time, build bindings for both progressively, eventually replace their respective AWS SDKs, and when investment is secured we can do a crate from the work mostly completed.

[calavera]

I've been thinking about this, and I don't think we need a new crate or project. When people start with Rust Lambda functions, they usually start with cargo lambda new, which already brings tracing and tracing-subscriber as dependencies. Instead of having to manage that in Cargo Lambda, it makes more sense for the runtime to provide the default logging configuration. This way we avoid dependency drift.

The changes to support this feature are actually tiny, and the documentation is straight forward. I'm going to open a PR soon with the implementation.

[github-actions]

This issue is now closed. Comments on closed issues are hard for our team to see.
If you need more assistance, please either tag a team member or open a new issue that references this one.