-
Notifications
You must be signed in to change notification settings - Fork 114
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Specify when flush returns unsuccessfully #623
base: main
Are you sure you want to change the base?
Conversation
Co-authored-by: Emily S <[email protected]>
In the edge case where the extension takes too much time to respond (e.g. if there's a lenghy GC pause), | ||
the `flush` method should return after a timeout. | ||
|
||
The default timeout is 1s. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As a data point for what is currently happening in the agents, we use api_request_time
as our flush timeout, which defaults to 10s
.
That's likely too long, especially for Lambda. But I'm thinking we should create a new config option so this is configurable (and divorced from api_request_time
).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The default timeout is 1s. | |
| | | | |
|----------------|---| | |
| Type | [duration](configuration.md#configuration-value-types) | | |
| Default | `1s` | | |
| Dynamic | `true` | |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds good to me as an improvement over #613
Co-authored-by: Trent Mick <[email protected]>
@@ -291,3 +291,17 @@ Therefore, the Lambda instrumentation has to ensure that data is flushed in a bl | |||
|
|||
Some Lambda functions will use the custom-built Lambda extension that allows the agent to send its data locally. The extension asynchronously forwards the data it receives from the agent to the APM server so the Lambda function can return its result with minimal delay. In order for the extension to know when it can flush its data, it must receive a signal indicating that the lambda function has completed. There are two possible signals: one is via a subscription to the AWS Lambda Logs API and the other is an agent intake request with the query param `flushed=true`. A signal from the agent is preferrable because there is an inherent delay with the sending of the Logs API signal. | |||
Therefore, the agent must send its final intake request at the end of the function invocation with the query param `flushed=true`. In case there is no more data to send at the end of the function invocation, the agent must send an empty intake request with this query param. | |||
|
|||
### Flush timeout |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This option is used by the Java agent already. See https://www.elastic.co/guide/en/apm/agent/java/current/config-serverless.html#config-data-flush-timeout
### Flush timeout | |
### Configuration option `data_flush_timeout` |
In the edge case where the extension takes too much time to respond (e.g. if there's a lenghy GC pause), | ||
the `flush` method should return after a timeout. | ||
|
||
The default timeout is 1s. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The default timeout is 1s. | |
| | | | |
|----------------|---| | |
| Type | [duration](configuration.md#configuration-value-types) | | |
| Default | `1s` | | |
| Dynamic | `true` | |
CODEOWNERS
)To auto-merge the PR, add
/
schedule YYYY-MM-DD
to the PR description.