Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.
And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.
[META 352] AWS Lambda support
See original GitHub issueI’m currently building a serverless architecture and was hoping to use elastic cloud as a one-stop repository for logs and metrics. Per elastic/apm-agent-python#320 it seems that Lambda is not a supported environment for Elastic-APM.
I’d be happy to put in some work to make this happen, but I’m not entirely clear on where the problems lie. Is there a reason why this is more complex than calling collect on the metric repository and flush on the transport?
If I had a MetricRegistry with a collect_interval of 0ms, and an unthreaded transport that flushed only on demand, I could flush explicitly at the end of the lambda invocation. It would be simple to extend that to a decorator that flushed on exit from the wrapped function. Is this an enormous simplification of the requirements?
Issue Analytics
- State:
- Created 5 years ago
- Comments:7 (5 by maintainers)
Top Results From Across the Web
Top Related Medium Post
Top Related StackOverflow Question
Troubleshoot Live Code
Top Related Reddit Thread
Top Related Hackernoon Post
Top Related Tweet
Top Related Dev.to Post
Top Related Hashnode Post
We’re going to try to get an MVP of this going soon – it will not be using lambda extensions initially, but will just be sending directly to the configured APM server from the lambda function itself. We know this will not be useful in all cases as the overhead will be dramatic, especially for short-running lambda functions. But it will be a first step toward a better implementation using extensions.
Ref https://github.com/elastic/apm/issues/352