Support for serverless functions

[eyalkoren]

See the discussion at https://discuss.elastic.co/t/apm-with-aws-lambda-java/185936.

Currently implementation should at least include addition of a blocking flush API. Maybe some work around metrics.
(It is likely that we would want to work on native support for serverless, rather than offering something that requires specific API for that, but we'll think about implementation when we get to it).

In addition, add some documentation on how to enable:

• using the programmatic attach API
• provide tools.jar
• a word of warning about overhead and maybe tuning
• caveats (metrics?)

[RajatArora08]

Hi @eyalkoren! Is this planned for any release yet?

[eyalkoren]

@RajatArora08 thanks for expressing your interest!
It is not planned for any specific release yet, but it is definitely something we are actively looking into, not specifically for the Java agent and not specifically for AWS lambda, but trying to figure out the best way to support server-less architectures across our entire Observability offering.
Keep tracking this issue for now, so you should get notified when we get to it in the Java agent.

[gamefundas]

@eyalkoren it has been a while since this was opened, has there been any progress in this area for serverless observability. I was considering elastic apm for our application and support of AWS lambda is quite important. Came across this and few other threads to learn that currently there is no official support available. Is this true?

[eyalkoren]

Not a lot to report at the moment, only this Python agent PR as a partial POC of one approach.

[remmeier]

a word of warning about overhead and maybe tuning

is maybe the main point to address in order to allow serverless functions to start quickly. For example, our non-servlerless services start in about 2-3 seconds. When applying the apm agent, startup times double to 4-5 seconds. A general direction for startup optimizations is to move more things from runtime to build-time. e.g. graal native creates binaries to replace JIT. micronauts/dagger do dependency injection at compile-time. With these tools applications can start in milliseconds. Would be great to allow the integration of elastic with such tech stacks.

One angle could be be the use cases covered by the apm agent library:

• publishing of data to apm server
• openapi interface
• integration into the various tech stacks (servlets, jdbc, jpa, etc.)
• apm to inject the various integrations into a running application

It could help for startup performance if there is a (documented) approach how to setup apm programmatically rather than using the agent approach. Developers would then embed the parts necessary for their application. This inclusion will be at build-time rather than attached as agent at runtime. Which in turn will allow all the optimizations for above (and more). Currently I suspect the agent makes up most of the startup effort while the actual trace collection/publishing is rather lightweight.

[Sutty100]

I added 1.21.0 to a simple Java Lambda but the collection of data was very sporadic with many transactions seemingly being dropped. It also significantly impacted startup times of the lambda for the first request. It's such a shame as it worked great as a POC on our spring services but the inability to include our AWS Lambdas into the same trace really removes a lot of value.