Differences

This shows you the differences between two versions of the page.

--- bloglike:2021-07 [2021/07/20 12:40] – AWS EventBridge, Input Transformation and CW Logs stybla
+++ bloglike:2021-07 [2021/07/21 09:29] (current) – link terraform issue stybla
@@ Line 9: / Line 9: @@
 {{ :bloglike:aws_eventbridge_cw_doc.png?600 |}}
-which, to be honest, doesn't make sense to me. What is ''version-id''? You mean ''version'' from the original event? API version? And where do I put my message? What??? Of course, relation to anything on that page is 0. Nope, don't see it. I'm daft. But it was some progress and in the right direction too. Originally, I thought that some keys are reserved, I'm creating loop or time format is wrong and that's why I get ''FailedInvocations''. Wrong is correct, because it seems that expected JSON is:
+which, to be honest, doesn't make sense to me. What is ''version-id''? You mean ''version'' from the original event? API version? And where do I put my message? What??? Of course, relation to anything on that page is 0. Nope, don't see it. I'm daft! Even [[https://stackoverflow.com/a/66046953|answer at StackOverflow]] was more useful than the official documentation! But it was some progress and in the right direction too. Originally, I thought that some keys are reserved, I'm creating loop or time format is wrong and that's why I get ''FailedInvocations''. Wrong is correct, because it seems that expected JSON is:
 <code>
@@ Line 26: / Line 26: @@
 </code>
-I haven't found another way to do it nor how to deal with nested data(lists and dicts), eg. ''{"resources": ["arn:aws:..."]}'', therefore it seems that you must do without. All other fields I've tried to smuggle in have been stripped away, at least in my case. If you turn ''message'' into dict, then there will be ''{'' in CloudWatch Logs. Also noteworthy, if escaped JSON is invalid, the result will be a failed invocation and data won't make it into CloudWatch Logs. In theory, you can send output into SQS dead-letter queue when it cannot be delivered, but I haven't tested it. I should've tested it, though, because I bet it'd make debugging a lot easier since I couldn't find related logs anywhere!
+Meh! I haven't found another way to do it nor how to deal with nested data(lists and dicts), eg. ''{"resources": ["arn:aws:..."]}'', therefore it seems that you must do without. All other fields I've tried to smuggle in have been stripped away, at least in my case. If you turn ''message'' into dict, then there will be ''{'' in CloudWatch Logs. Note that if escaped JSON is invalid, the result will be a failed invocation and data won't make it into CloudWatch Logs. In theory, you can send output into SQS dead-letter queue when it cannot be delivered, but I haven't tested it. I should've tested it, though, because I bet it'd make debugging a lot easier since I couldn't find related logs anywhere!
 I guess all of this could've been done much faster and less painful with a simple Lambda function, but then you have code to maintain and deploy.
-Hopefully the last thing. Beware of this [[https://github.com/aws-cloudformation/cloudformation-coverage-roadmap/issues/351#issue-552650814|bug]]. Over and out.
+Couple more things. Beware of this [[https://github.com/aws-cloudformation/cloudformation-coverage-roadmap/issues/351#issue-552650814|bug]].
+> Note: CloudWatch Events currently supports a maximum of 10 variables in input path maps. To extract more than 10 variables, pass the entire event to an AWS Lambda function for parsing.
+Well, I able to parse 13 variables. Lucky me, I guess. 8-) Or maybe not, because when I've tried to put this into terraform, then:
+<code>
+Error: expected number of items in input_transformer.0.input_paths to be less than or equal to 10, got 16
+</code>
+To that I say, bollocks! It works no-problem from the console, so why would you ...?! [[https://github.com/hashicorp/terraform-provider-aws/issues/10912|Geee, thanks!]] :-\ As I've said, use Lambda function, if you can. Yeah, anything but CloudWatch Logs.
+You can filter which events get processed like so:
+<code>
+{
+  "source": [
+    "aws.batch"
+  ],
+  "detail-type": [
+    "Batch Job State Change"
+  ],
+  "detail": {
+    "status": [
+      "FAILED",
+      "SUCCEEDED"
+    ]
+  }
+}
+</code>
+This means only ''FAILED'' and ''SUCCEEDED'' Batch Job State changes will be processed and forwarded to rule's target(output).
  --- //[[stybla@turnovfree.net|Zdenek Styblik]] 2021/07/20 17:18//