-
Notifications
You must be signed in to change notification settings - Fork 4k
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
(aws_events_targets.CloudWatchLogGroup): unable to add aws_events.RuleTargetInput.from_object #19451
Labels
@aws-cdk/aws-events-targets
bug
This issue is a bug.
effort/small
Small work item – less than a day of effort
p1
Comments
I am seeing this same behavior in C#. |
4 tasks
mergify bot
pushed a commit
that referenced
this issue
Jun 20, 2022
…#20748) The CloudWatch logs log group target requires a very specific input template. It does not support `input` or `inputPath` and if `inputTemplate` is specified it must be in the format of `{"timestamp": <time>, "message": <message>}` where both the values for `timestamp` and `message` are strings. This requirement is not very well documented, the only reference I could find is in a `Note` on this [page](https://docs.aws.amazon.com/eventbridge/latest/APIReference/API_PutTargets.html). This PR adds a new property `logEvent` and deprecates the `event` property to ensure that if the user adds an event input that it uses the correct format. While working on this PR is started by adding some validation if the user provides the `event` property and then went down the route of providing the new `logEvent` property. Since I already did the work of creating the validation for `event` I've kept it, but I'm open to just removing that logic since it is validating a `deprecated` property. I've also added an integration test that asserts that the expected message is written to the log group. fixes #19451 ---- ### All Submissions: * [x] Have you followed the guidelines in our [Contributing guide?](https://github.com/aws/aws-cdk/blob/main/CONTRIBUTING.md) ### Adding new Unconventional Dependencies: * [ ] This PR adds new unconventional dependencies following the process described [here](https://github.com/aws/aws-cdk/blob/main/CONTRIBUTING.md/#adding-new-unconventional-dependencies) ### New Features * [x] Have you added the new feature to an [integration test](https://github.com/aws/aws-cdk/blob/main/INTEGRATION_TESTS.md)? * [x] Did you use `yarn integ` to deploy the infrastructure and generate the snapshot (i.e. `yarn integ` without `--dry-run`)? *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
|
daschaa
pushed a commit
to daschaa/aws-cdk
that referenced
this issue
Jul 9, 2022
…aws#20748) The CloudWatch logs log group target requires a very specific input template. It does not support `input` or `inputPath` and if `inputTemplate` is specified it must be in the format of `{"timestamp": <time>, "message": <message>}` where both the values for `timestamp` and `message` are strings. This requirement is not very well documented, the only reference I could find is in a `Note` on this [page](https://docs.aws.amazon.com/eventbridge/latest/APIReference/API_PutTargets.html). This PR adds a new property `logEvent` and deprecates the `event` property to ensure that if the user adds an event input that it uses the correct format. While working on this PR is started by adding some validation if the user provides the `event` property and then went down the route of providing the new `logEvent` property. Since I already did the work of creating the validation for `event` I've kept it, but I'm open to just removing that logic since it is validating a `deprecated` property. I've also added an integration test that asserts that the expected message is written to the log group. fixes aws#19451 ---- ### All Submissions: * [x] Have you followed the guidelines in our [Contributing guide?](https://github.com/aws/aws-cdk/blob/main/CONTRIBUTING.md) ### Adding new Unconventional Dependencies: * [ ] This PR adds new unconventional dependencies following the process described [here](https://github.com/aws/aws-cdk/blob/main/CONTRIBUTING.md/#adding-new-unconventional-dependencies) ### New Features * [x] Have you added the new feature to an [integration test](https://github.com/aws/aws-cdk/blob/main/INTEGRATION_TESTS.md)? * [x] Did you use `yarn integ` to deploy the infrastructure and generate the snapshot (i.e. `yarn integ` without `--dry-run`)? *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
@aws-cdk/aws-events-targets
bug
This issue is a bug.
effort/small
Small work item – less than a day of effort
p1
What is the problem?
I have an EventBridge rule with an aws.ecs source and detail_type of "ECS Task State Change", which is logged to CloudWatch. This all works fine. I want to transform the event before it's sent to CloudWatch, so our logging platform has some additional attributes. When I set the "event" parameter for the CloudWatchLogGroup target I get a validation error on deploy but not synth . I've used aws_events.RuleTargetInput.from_object() on Lambda targets without issue.
I've omitted the log group creation and its resource policy - as it all works until attempting to utilized "RuleTargetInput.from_object()"
Reproduction Steps
What did you expect to happen?
Successful deploy with transformed event data publishing to CloudWatch
What actually happened?
Input and InputPath are not valid forms of input for target Target0. The only valid form of input is InputTransformer. (Service: AmazonCloudWatchEvents; Status Code: 400; Error Code: ValidationException; Request ID: 7c2c2338-281f-406b-98e9-6a06ea292af7; Proxy: null)
CDK CLI Version
1.149.0 (build 2bb9d2f)
Framework Version
No response
Node.js Version
v14.17.6
OS
Windows
Language
Python
Language Version
Python (3.8.8)
Other information
No response
The text was updated successfully, but these errors were encountered: