Feature request: Priming for `powertools-tracing`

[phipag]

Use case

PLEASE READ: Priming documentation: https://github.com/aws-powertools/powertools-lambda-java/blob/main/Priming.md

Parent issue: https://github.com/aws-powertools/powertools-lambda-java/issues/1588 Sample PR: https://github.com/aws-powertools/powertools-lambda-java/pull/1861

Java CRaC can be used to prime an application by implementing beforeCheckpoint() and afterRestore() hooks in selected classes. When used with AWS Snapstart, the beforeCheckpoint() hook runs before the memory snapshot is taken. This behavior can be leveraged to further reduce restore durations by pre-loading classes and calling commonly used code to incorporate this into the memory snapshot.

1. Class-preloading / automatic priming: Based on a statically generated classesloaded.txt file, loads classes used at runtime into memory
2. Invoke priming: Execute commonly used code e.g. to initialize all reflectively access objects, warm up caches, TCP connection pools etc. Common examples include performing "dry" AWS SDK calls (not impacting production resources) or performing JSON serialization/deserialization.

The goal of this issue is to implementing priming techniques for the powertools-tracing module.

Solution/User Experience

Implement priming based on Priming Documentation (feel free to update documentation and suggest improvements):

• [ ] Automatic priming
• [ ] Invoke priming

Alternative solutions

Acknowledgment

• [x] This feature request meets Powertools for AWS Lambda (Java) Tenets
• [ ] Should this be considered in other Powertools for AWS Lambda languages? i.e. Python, TypeScript, and .NET

Future readers

Please react with 👍 and your use case to help us understand customer demand.

[dcabib]

Hi @phipag! 👋

I'd be happy to help implement priming support for the powertools-tracing module. I've reviewed the priming documentation and the reference implementation in powertools-metrics, and I have a good understanding of what needs to be done.

My proposed implementation approach:

1. Add Maven profile to powertools-tracing/pom.xml for generating the classes loaded file (similar to the generate-classesloaded-file profile in powertools-metrics)

2. Generate and clean up the classesloaded.txt file by:

   • Running tests with the VM argument -Xlog:class+load=info:classesloaded.txt
   • Processing the file to extract only the fully qualified class names
   • Moving it to src/main/resources/

3. Implement CRaC Resource interface in TracingUtils class (as the main entry point for the tracing module) by:

   • Adding CRaC dependency and imports
   • Registering with Core.getGlobalContext() in a static block
   • Implementing beforeCheckpoint() to call ClassPreLoader.preloadClasses()
   • Adding any tracing-specific initialization (like initializing X-Ray components)

4. Test the implementation to ensure it works correctly with SnapStart

I notice that TracingUtils is the main utility class that users interact with, making it a suitable candidate for CRaC integration, similar to how MetricsFactory is used in the metrics module.

Would you like me to proceed with this implementation? I can start with creating a PR that follows the same pattern as the metrics module implementation.

Also, are there any specific tracing-related initializations you'd recommend including in the beforeCheckpoint() hook beyond the standard class preloading?

Thanks for creating this issue and making it accessible to new contributors! 🚀

[phipag]

Hey @dcabib,

thanks for your detailed implementation plan. I think it makes sense to include the Priming logic in TracingUtils. Just a note: It is possible to use only @Tracing annotation and since this is an AspectJ aspect it does not trigger the CRaC hooks if it calls TracingUtils transitively. We need to update the documentation with guidance that the user needs to reference TracingUtils directly in their code to trigger SnapStart priming.

We did the same thing for ValidationConfig in this PR: https://github.com/aws-powertools/powertools-lambda-java/pull/2081.

Regarding what to prime:

• Class pre-loading
• Invoke priming of AWS SDK. You can prime the X-RAY SDK by performing some dummy calls but need to make sure that no traces are persisted in X-RAY which will incur a cost to the user. Ideally you can make some requests that do not have any persistent side-effects.

Let me know if you have any questions. Should I assign the issue to you to work on it?

[dcabib]

Hi @phipag!

Thanks for the feedback and clarifications! I understand the important point about users needing to reference TracingUtils directly to trigger SnapStart priming, and I'll make sure to update the documentation accordingly.

I'm ready to work on this implementation following the patterns established in the metrics module and the ValidationConfig approach from PR #2081. I'll focus on:

• Class pre-loading via TracingUtils
• Invoke priming of X-Ray SDK with dummy calls that don't persist traces
• Proper documentation updates about direct TracingUtils usage

Please assign this issue to me and I'll get started on the implementation.

Thanks!

[phipag]

That's awesome @dcabib. I assigned the issue to you 🚀

[phipag]

This issue is in the backlog again and open for contribution.

[Attyuttam]

Hi, I would like to pick this up

[Attyuttam]

@phipag can you please have a look at my PR. I have made the changes to the best of my understanding, so it would be great if you could suggest any more changes if needed.

[phipag]

Thanks @Attyuttam, let's continue the conversation in the PR.