Closed bnusunny closed 6 months ago
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.
Yeah, I vote for a separate lambda-powertools-rs
crate.
Copy @heitorlessa. This could be a good time to cooperate.
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.
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.
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.
https://aws.amazon.com/blogs/compute/introducing-advanced-logging-controls-for-aws-lambda-functions/
Additional details here: