fix: silence alarms in CODE and handle missing data correctly #404
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What does this change?
This PR makes two improvements to our alarms:
CODE
by default. This prevents us from spamming teams with alerts about theirCODE
environments (in my experience these just generate unactionable noise, asCODE
environments are expected to break sometimes).Does this change require changes to existing projects or CDK CLI?
No. Any user who wants to keep (or temporarily test) alarm actions in their
CODE
environment can still do so if they wish by settingactionsEnabledInCode
totrue
.How to test
I've tried upgrading https://github.com/guardian/tag-janitor/blob/main/cdk/lib/cdk-stack.ts (locally) in order to use this change and confirmed that the changes set looks sensible in AWS. I haven't tested actually deploying the change as there is no
CODE
environment for this stack. I'll finish the upgrade and check the deployment inPROD
after releasing this change.How can we measure success?
OK
in scenarios where the lambda is not being invokedHave we considered potential risks?
There is a small risk that disabling these alarm actions in
CODE
(by default) will prevent us from noticing problems with alarm configuration. I think using theActionsEnabled
property allows us to minimise this risk as much as possible.