Skip to content
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

Merged
merged 7 commits into from
Nov 17, 2023

Conversation

nine5two7
Copy link
Contributor

@nine5two7 nine5two7 commented Nov 14, 2023

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.

Screenshot 2023-11-14 at 10 20 28 PM Screenshot 2023-11-14 at 10 23 08 PM Screenshot 2023-11-14 at 10 25 39 PM

What does this PR do?

Motivation

Testing Guidelines

Additional Notes

Types of changes

  • Bug fix
  • New feature
  • Breaking change
  • Misc (docs, refactoring, dependency upgrade, etc.)

Check all that apply

  • This PR's description is comprehensive
  • This PR contains breaking changes that are documented in the description
  • This PR introduces new APIs or parameters that are documented and unlikely to change in the foreseeable future
  • This PR impacts documentation, and it has been updated (or a ticket has been logged)
  • This PR's changes are covered by the automated tests
  • This PR collects user input/sensitive content into Datadog
  • This PR passes the integration tests (ask a Datadog member to run the tests)
  • This PR passes the unit tests
  • This PR passes the installation tests (ask a Datadog member to run the tests)

@nine5two7 nine5two7 self-assigned this Nov 14, 2023
@github-actions github-actions bot added the aws label Nov 14, 2023
@nine5two7 nine5two7 added this to the triage milestone Nov 15, 2023
@nine5two7 nine5two7 marked this pull request as ready for review November 15, 2023 19:16
@nine5two7 nine5two7 requested a review from a team November 16, 2023 19:44
Copy link
Contributor

@agocs agocs left a 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

aws/logs_monitoring/customized_log_group.py Outdated Show resolved Hide resolved
aws/logs_monitoring/customized_log_group.py Outdated Show resolved Hide resolved
# 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"

Copy link
Contributor

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.

Copy link
Contributor

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...

Copy link
Contributor Author

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)
Copy link
Contributor

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?

Copy link
Contributor Author

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.

@nine5two7 nine5two7 merged commit f7a3a61 into master Nov 17, 2023
11 checks passed
@nine5two7 nine5two7 deleted the chenguang.xu/lambdCustomizedLogGroup branch November 17, 2023 13:37
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants