-
Notifications
You must be signed in to change notification settings - Fork 381
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
adding log group tags #531
Conversation
logger.exception(f"Failed to get log group tags due to {e}") | ||
if response is not None: | ||
formatted_tags = [ | ||
"{key}:{value}".format(key=k, value=v) if v else k |
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 don't really get this ternary operator. Why would we set this to k
if not v
?
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 is to capture how AWS tags work with keys and values. If the value isn't present we don't want to send "KEY:", we want to just send "KEY"
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's confusing indenting, but the list comprehension saying for each item, format if v exists, else just return k
format(k, v) if v else k for k, v in items()
.
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 think I understand whats going on but not why
So in this case, is k
the entire tag? If its a bad format, I'd think we'd exclude it
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.
Yeah, k is the whole tag in this case. It's just like tags in datadog without a ":" - a "just key" tag as opposed to a "key:value" tage
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.
Are the tags cached? There could be a lot of calls to retrieve the log group tags - resulting in a lot of errors - any thought to handling HTTP 429 errors and providing a backoff/retry strategy?
@jvanbrie did datadog update something here and not publish a new forwarder lambda? we are getting an error
See this same error from 2021 |
Forgive me for intruding on your PR here. But it appears your have put the boto3 client connection inside the lambda handler so it will have to reconnect on every invoke, rather than caching a session - and calling a tag lookup on every invoke will surely hit throttling limits and cause issues in an account. The Datadog forwarder uses a LambdaTagsCache in other places to optimize handling of tags already. This seems like a regression and not an ideal solution
|
I'm just reviewing this PR too @rl-michaelbrandeis - note this PR adds the pulling of CloudWatch Log Group tags - not Lambda tags. The abilities added are really nice and well worth it (I do question if it should be optional though). I tend to agree though - creating a I would have thought the CloudWatch log group tags could be cached in the same way the Lambda function tags are cached - by using a JSON object within the nominated S3 bucket for the forwarder itself. |
Yep, we're making a few changes to this pr here. The layer version issue has been fixed and we're looking into some caching options for this in the meantime. This pr isn't in the current released version. For now we've reverted the change. |
Hey everyone, I made a new pr to address some of these concerns: #540
Feel free to take a look - I'll leave the pr up for a few days before looking to release. |
I want to report that with the current logic, the lambda assumes the log group is in the same account. Just like @magnetikonline mentioned, would be better if we can have a switch to allow tag collection or not. |
You can control tag collection through the environment variable DD_FETCH_LAMBDA_TAGS. This being set to false will disable tag collection in the lambda: https://github.com/DataDog/datadog-serverless-functions/pull/540/files#diff-023a52190a3595e5875c43668188d53b819c2c966ac78be21408d516391b5679R188 I do not know how involved supporting a single lambda for multiple accounts is, but that is not a goal of this pr. If you want logs from multiple accounts with tags for log groups you can make a lambda in each account. If you don't want to make a lambda per-account you can disable tag collection for the lambda to avoid errors. |
Ah thanks @jvanbrie - I was hoping only your new CloudWatch log group tag collection could be disabled - basically retaining the existing behaviour before the PR. I'd argue that |
What does this PR do?
This pr adds support for cloudwatch log group tags. These tags will now get attached to the logs sent to datadog.
Motivation
Customer requests
Testing Guidelines
Created new lambda function with this code, created some custom tags on a few log groups, and confirmed those tags get attached to the logs that make their way to Datadog. Unit and integration tests pass as well.
Additional Notes
Types of changes
Check all that apply