DEV Community

Cover image for Day 41: Ditching print() for AWS Lambda Powertools (Structured Logging)
Eric Rodríguez
Eric Rodríguez

Posted on

Day 41: Ditching print() for AWS Lambda Powertools (Structured Logging)

Building my AI Financial Agent has taught me a lot about cloud infrastructure, but today I learned a crucial lesson about Observability.

Up until now, I was logging custom metrics and errors using a helper function that basically did print(json.dumps(log_entry)). It worked, but it felt hacky and didn't integrate natively with AWS X-Ray or standard CloudWatch query syntax.

The Upgrade
Today, I stripped out the manual JSON dumping and brought in aws_lambda_powertools.

Here is what changed:

Context Injection: I configured the EventBridge scheduler to pass a specific JSON payload containing the user's name and ID.

Global Logging State: Using the Powertools Logger, I can inject user_id at the start of the handler. Every subsequent log message, even deep inside helper functions like my Bedrock invocation, automatically includes this data. No more passing user_id around as a function argument.

Dynamic Prompts: I hooked this new dynamic identity directly into the Amazon Nova prompt. The AI no longer just reads a hardcoded name; it reacts to whoever triggered the event.

Why you should care:
If you ever need to troubleshoot a distributed serverless application, grep is not your friend. You need queryable, structured data. With this setup, I can jump into CloudWatch Logs Insights and type:
filter level = "ERROR" | stats count() by user_id

Instantly actionable. No more guessing.

Top comments (0)