access logging: introduce critical ALS endpoint #17486
Conversation
Signed-off-by: Shikugawa <rei@tetrate.io>
|
cc @snowp can you also take a look at this? This is similar to some of the things we are doing at Lyft and we should see if there are any useful overlaps. |
|
This is super cool, I think this kind of pattern (bidi stream that sends payloads, buffers until ack) would be useful in other places as well. Do you think it would make sense to create a generic I think for example this could be employed by the gRPC stats sink, which currently would suffer the same kind of loss that the ALS sink does. |
|
@snowp @mattklein123 @lizan Finished to implement codes (except docs). Could you take a look please? |
Signed-off-by: Shikugawa <rei@tetrate.io>
|
/retest |
|
Retrying Azure Pipelines: |
|
Needs a main merge. cc @snowp to help finish the review on this. /wait |
|
This pull request has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in 7 days if no further activity occurs. Please feel free to give a status update now, ping for review, or re-open when it's ready. Thank you for your contributions! |
github-actions
bot
added
the
stale
Shikugawa
removed
the
stale
…8129) Commit Message: grpc: implement BufferedAsyncClient for bidirectional gRPC stream Additional Description: This function is a component for buffering and tracking the state of messages sent in the gRPC bidirectional stream. This component makes it possible to monitor and control the transmission status of highly granular messages from the Envoy side, and is identical to the one implemented in #17486. Risk Level: Low Testing: Unit Docs Changes: Release Notes: Platform Specific Features: Signed-off-by: Shikugawa <rei@tetrate.io>
Signed-off-by: Shikugawa <rei@tetrate.io>
|
CC @envoyproxy/api-shepherds: Your approval is needed for changes made to |
|
|
||
| // Size limit (in bytes) of the buffer used to store messages during processing in a | ||
| // critical logger. A critical logger buffers messages until it receives an ACK from upstream. | ||
| // The default is 16384. |
There was a problem hiding this comment.
What happens when the buffer size is exceeded? Can you clarify in the comment, please?
|
This pull request has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in 7 days if no further activity occurs. Please feel free to give a status update now, ping for review, or re-open when it's ready. Thank you for your contributions! |
github-actions
bot
added
the
stale
Shikugawa
removed
the
stale
|
This pull request has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in 7 days if no further activity occurs. Please feel free to give a status update now, ping for review, or re-open when it's ready. Thank you for your contributions! |
github-actions
bot
added
the
stale
|
This pull request has been automatically closed because it has not had activity in the last 37 days. Please feel free to give a status update now, ping for review, or re-open when it's ready. Thank you for your contributions! |
Signed-off-by: Shikugawa rei@tetrate.io
Commit Message: Add an ALS endpoint to ensure that the message reaches the destination. This endpoint is designed to return an ACK/NACK as a response, and if a NACK is received, Envoy will buffer the message and take steps to resend it. The log to be buffered is determined by the AccessLogFilter.
Additional Description:
Risk Level: Low
Testing:
Docs Changes:
Release Notes:
Platform Specific Features:
[Optional Runtime guard:]
[Optional Fixes #Issue]
[Optional Deprecated:]
[Optional API Considerations:]
cc @lizan