-
-
Notifications
You must be signed in to change notification settings - Fork 4.2k
Reapply reduce requests necessary for log publishing from lambda to cloudwatch logs #12470
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
Conversation
Set the semver label to minor, as the changed log format (keeping newline endings) can be quite visible to the user, even though it is technically a parity improvement. |
LocalStack Community integration with Pro 2 files ± 0 2 suites ±0 1h 29m 7s ⏱️ - 20m 26s Results for commit d1a87aa. ± Comparison against base commit e1f3422. This pull request removes 1166 and adds 1 tests. Note that renamed tests count towards both.
|
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.
LGTM 🚀
Thanks for re-introducing this optimization and pointing out the next steps. I created a backlog item to capture these improvement suggestions.
Ext run is 🟢
@@ -50,10 +50,34 @@ def run_log_loop(self, *args, **kwargs) -> None: | |||
log_item = self.log_queue.get() | |||
if log_item is QUEUE_SHUTDOWN: | |||
return | |||
# we need to split by newline - but keep the newlines in the strings | |||
# strips empty lines, as they are not accepted by cloudwatch | |||
logs = [line + "\n" for line in log_item.logs.split("\n") if line] |
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.
Do we have a test for the empty lines case?
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.
No, but cloud watch does not accept empty lines. The logic matches the one in store_cloudwatch_logs
though, so we at least do not get worse in terms of parity. We should write tests for this though, when we rework the logging in general.
@@ -50,10 +50,34 @@ def run_log_loop(self, *args, **kwargs) -> None: | |||
log_item = self.log_queue.get() | |||
if log_item is QUEUE_SHUTDOWN: | |||
return | |||
# we need to split by newline - but keep the newlines in the strings | |||
# strips empty lines, as they are not accepted by cloudwatch | |||
logs = [line + "\n" for line in log_item.logs.split("\n") if line] |
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.
Following this discussion, do we have an intuition where these replacements came from?
log_output = log_output.replace("\\x1b", "\n\\x1b")
log_output = log_output.replace("\x1b", "\n\x1b")
I just wanted to add the reference in case we need to add them reactively because we removed them without knowing where they came from 😄
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.
No, still no idea. Since those are ANSI escape sequences, I still think they stem from the time were we captured the lambda logs directly from docker running inside a full terminal instance.
Motivation
With #10294 we had to revert increased performance for lambda cloudwatch logs, reduced requests necessary for every log storage from 3 to (on average) 1.
The root cause for this revert was the
.splitlines()
method used to split the logs, as it also splits on several other characters, like a carriage return, unlike the old log method.Since the runtime interface clients patch the loggers (e.g. here: https://github.com/aws/aws-lambda-nodejs-runtime-interface-client/blob/2ea9a34b5c1b15621df132eb2d377ac54b330c8f/src/LogPatch.js#L82-L88), we need to leave carriage returns as is for now.
In the long term, to further increase logging parity, we need to:
INIT_START
message (this should allow for proper snapshotting of logs as well then, as the count should align)The test added mostly assures normal carriage returns are not split into multiple messages - the main cause for the failing ext test.
In the future, with the improvements above, we need to add more tests for parity for different logging mechanisms.
Changes