-
Notifications
You must be signed in to change notification settings - Fork 388
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
To support Lambda customized log group #709
Conversation
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, but I have some concerns about how many times we're calling fullmatch
. If you don't think it's a performance concern, it's probably okay
# Need to parse logStream name to determine whether it is a Lambda function | ||
if is_lambda_customized_log_group(logs["logStream"]): | ||
metadata[DD_SOURCE] = "lambda" | ||
|
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.
It might not be a concern, but I worry about running a regular expression match on every Lambda log event.
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.
On second thought, it might be the best way...
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 format for logstream names varies on the source of the logs. I originally expect it to be something more consistent, but it is not.
def get_lower_cased_lambda_function_name(logs): | ||
logstream_name = logs["logStream"] | ||
# function name parsed from logstream is preferred for handling some edge cases | ||
function_name = get_lambda_function_name_from_logstream_name(logstream_name) |
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.
Rather than run this regex match a second time for every lambda log event, does it make sense to set the function_name
in awslogs_handler
based on whether we've discovered it to be a custom log group or not?
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.
I was thinking of avoiding pattern matching twice, and it turns out that in order to be compatible with the existing logics for default log group, the codes can be more verbose and hard to maintain. I tried to refactor the lambda log processing logic out into a separate function at the cost of it.
Co-authored-by: Christopher Agocs <[email protected]>
To support Lambda Customized Log group.
Customized log group can potentially be used by all AWS applications.
This PR is to make it support Lambda.
It also compatible with default log group, and all other things supported by the DD forwarder.
JIRA Link
Below screen shots can verify that it support both default and customized log groups for Lambda. Integration test also verify that it dose not impact other AWS applications.
What does this PR do?
Motivation
Testing Guidelines
Additional Notes
Types of changes
Check all that apply