feat(cloudwatch): parse all metrics statistics and support long format

[rigwild]

Description

Previous PR added support for missing statistics #23074
This PR implements a proper parsing of all these statistics.

• Support "short" format ts99
• Support "long" format
  • TS(10%:90%) | TS(10:90)
  • TS(:90) | TS(:90%)
  • TS(10:) | TS(10%:)
• Formats are case insensitive (no breaking changes)
• If "long" format and only upper boundary% TS(:90%), can be translated to "short" format ts90 (stat.asSingleStatStr)

Note

I noticed that the following code expected the parsing to throw if it failed, but it actually will not fail in any case (it just return GenericStatistic if no format matched).
I will not change this behavior here as I'm not willing to spend more effort testing if this breaks stuff elsewhere.

aws-cdk/packages/@aws-cdk/aws-cloudwatch/lib/metric.ts

Lines 295 to 296 in 47943d2

	// Try parsing, this will throw if it's not a valid stat
	this.statistic = normalizeStatistic(props.statistic || 'Average');

Followup work

As is, this PR does not change any customer-facing logic. To make use of it, make the parsing throw if no format is recognized.

At the end of the parser function, just replace

return {
  type: 'generic',
  statistic: stat,
} as GenericStatistic;

with

throw new UnrecognizedStatisticFormatError()

---

You can see all tested inputs here: https://regexr.com/7351s

---

All Submissions:

• Have you followed the guidelines in our Contributing guide?

Adding new Unconventional Dependencies:

• This PR adds new unconventional dependencies following the process described here

New Features

• Have you added the new feature to an integration test?
  • 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

[gitpod-io]

[aws-cdk-automation]

The pull request linter has failed. See the aws-cdk-automation comment below for failure reasons. If you believe this pull request should receive an exemption, please comment and provide a justification.

✅ Updated pull request passes all PRLinter validations. Dissmissing previous PRLinter review.

[rigwild]

This is ready for review

[rix0rrr]

Hi @rigwild!

Heads up, that enum you modified in your previous PR was exposed by accident, and was never supposed to be public! 🫣

I've moved your new enum values to a class with factory functions in this PR here: #23172

Thanks for updating the parsing logic as well, but I'm unclear on whether this changes any output. Is it just for completeness of the internal typing?

[rigwild]

Thanks for updating the parsing logic as well, but I'm unclear on whether this changes any output. Is it just for completeness of the internal typing?

See quote

Followup work
As is, this PR does not change any customer-facing logic. To make use of it, make the parsing throw if no format is recognized.

The current parser was supposed to throw on parsing error, but that's not the case.

This specific PR only does internal stuff, a future change has to be implemented to make it actually throw and be useful

[rigwild]

Your new factories would solve this, but most code is currently passing raw strings, so this may still be useful to detect errors early before deploying stacks

[rix0rrr]

I'm pretty sure we used to do validation, and then the generic case got added because CloudWatch was adding new metrics we didn't recognize yet, and it was added as a catch-all to handle "whatever else" (I would need to do software archeology to confirm that).

So the question is: how valuable is validation, and is it going to get in the way of future additions to CloudWatch? I think we're going to have to resign ourselves to the validation only ever being able to be, at best, a warning: we can't block infra because it might be using some statistic we don't recognize yet. It might be a valid stat we just haven't gotten around to adding quite yet.

I wouldn't be opposed to adding validation like that, but I'm going to have to ask to make that the feature and main focus of the change. Changes the parsing logic may or may not be a part of it, but that does not deliver value by itself.

[rigwild]

That makes sense. That's why I didn't add the error throw! 😁

I can add this warning. I don't know if there is a logging system/lib? How to log it? console.warn?

[aws-cdk-automation]

This PR cannot be merged because it has conflicts. Please resolve them. The PR will be considered stale and closed if it remains in an unmergeable state.

✅ Updated pull request passes all PRLinter validations. Dissmissing previous PRLinter review.

[TheRealAmazonKendra]

Looks like this is not using Annotations.of(construct).addWarning(...):. Please use this kind of warning instead of a console log statement. With this you can also write a test for the warning showing up or not.

Pull request has been modified.

[rigwild]

Oh ok, when rix0rrr@ said:

so maybe it fits in neatly there.

I thought it meant that the console warning was ok 😁

Updated

[TheRealAmazonKendra]

Just one small requested change so that the warning is grammatically correct with or without the label.

Pull request has been modified.

[TheRealAmazonKendra]

@Mergifyio update

[mergify]

update

❌ Base branch update has failed

refusing to allow a GitHub App to create or update workflow .github/workflows/yarn-upgrade-v1main.yml without workflows permission
err-code: 491EB

[TheRealAmazonKendra]

Soooo... do you want to write all of our READMEs? This one is fantastic!

Thank you for your contribution!

[aws-cdk-automation]

AWS CodeBuild CI Report

• CodeBuild project: AutoBuildv2Project1C6BFA3F-wQm2hXv2jqQv
• Commit ID: 2391b6a
• Result: SUCCEEDED
• Build Logs (available for 30 days)

Powered by github-codebuild-logs, available on the AWS Serverless Application Repository

[mergify]

Thank you for contributing! Your pull request will be updated from main and then merged automatically (do not update manually, and be sure to allow changes to be pushed to your fork).