-
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-cloudwatch): Missing ids when creating math expressions #13942
Comments
+1, we are facing the same issue, and it's causing problem in showing 1-minute data for graphs containing MathExpression even we set period of MathExpression and all submetrics to 1 minute. |
Hey @zijuexiansheng, thanks for opening this issue! I am working on repro-ing the issue before triaging it. Can you provide a minimal, example reproduction of the issue? |
Here is a code sample that repro's the issue:
In the resulting cloudwatch dashboard, while each metric has an id, each Math Expression does not have an id in the dashboard body JSON. This results in both math expressions getting the default id 'm1' in the resulting widget. I think the fix for this will need two things:
|
Assigning p2, which means we will not fix this right away but it is in the backlog, and we will get to it when we can. Since this issue does not cause widgets with Math Expressions to render incorrectly, it just makes it impossible to reference a Math Expression within another Math Expression via its id. |
While we are working on a fix, if you want to be able to set the Option 1 const cfnDashboard = dashboard.node.defaultChild as CfnDashboard;
const resolvedDashboardBody = this.resolve(cfnDashboard.dashboardBody);
let dashboardSubstring = resolvedDashboardBody['Fn::Join'][1][2].toString();
// Replace 'myMathExpressionLabel' with the label of the Math Expression whose ID you want to change
// Replace 'myIdOfChoice' with the ID that you want to use
dashboardSubstring = dashboardSubstring.replace('"label":"myMathExpressionLabel"','"label":"myMathExpressionLabel","id":"myIdOfChoice"');
resolvedDashboardBody['Fn::Join'][1][2] = dashboardSubstring;
cfnDashboard.dashboardBody = resolvedDashboardBody; Option 2 const cfnDashboard = dashboard.node.defaultChild as CfnDashboard;
const resolvedDashboardBody = this.resolve(cfnDashboard.dashboardBody);
const dashboardBodyAsJson = JSON.parse(resolvedDashboardBody['Fn::Join'][1][0] + 'Ref: AWS::Region' + resolvedDashboardBody['Fn::Join'][1][2]);
// Change the next two variables to the indeces for the widget and metric in the generated cloudwatch dashboard source that you want to change
const indexOfWidgetToChange = 0;
const indexOfMetricWithinWidgetToChange = 0;
// Assign the ID you want to use
dashboardBodyAsJson['widgets'][indexOfWidgetToChange]['properties']['metrics'][indexOfMetricWithinWidgetToChange][0]['id'] = 'myIdOfChoice';
cfnDashboard.dashboardBody = cdk.Fn.sub(JSON.stringify(dashboardBodyAsJson)); |
+1 we are facing the same issue. Cannot render ANOMALY DETECTION properly because of it (using Java to generate graphs) |
If any1 else is still facing this issue: I managed to hack around it in python, something similar could work in other languages as well: helper class:
Usage: |
Can someone explain their use case to me again? I'm not sure I understand the problem.
Were you planning to write this: const failing = new MathExpression({ expression: '...', label: 'Failing calls' });
const total = new MathExpression({ expression: '...', label: 'Total calls' });
const failPercentage = new MathExpression({
expression: '(m1 / m2) * 100', // Rely on the fact that failing will render as m1 and total will render as m2
});
new cloudWatch.GraphWidget({
left: [failing, total, failPercentage],
}); Because this would work: const failing = new MathExpression({ expression: '...', label: 'Failing calls' });
const total = new MathExpression({ expression: '...', label: 'Total calls' });
const failPercentage = new MathExpression({
expression: '(failing / total) * 100',
usingMetrics: {
failing: failing,
total: total,
},
});
new cloudWatch.GraphWidget({
left: [failing, total, failPercentage], // <-- % should probably be on the right but this is a demo
}); ? |
It is intended that all metric identifiers referenced in a MathExpression are included in the `usingMetrics` map. This allows passing around complex metrics as a single object, because the math expression object carries around its dependencies with it. This is slightly different than what people might be used to from raw CloudWatch, where there is no hierarchy and all metrics are supposed to be listed in the graph widget or alarm with a unique ID, and then referenced by ID. We can't make this contract obvious anymore by adding a hard validation, but we can add warnings to hint people at the right way to reference metrics in math expressions. Fixes #13942, closes #17126.
@rix0rrr The generated dashboard widget for |
It is intended that all metric identifiers referenced in a MathExpression are included in the `usingMetrics` map. This allows passing around complex metrics as a single object, because the math expression object carries around its dependencies with it. This is slightly different than what people might be used to from raw CloudWatch, where there is no hierarchy and all metrics are supposed to be listed in the graph widget or alarm with a unique ID, and then referenced by ID. We can't make this contract obvious anymore by adding a hard validation, but we can add warnings to hint people at the right way to reference metrics in math expressions. Fixes #13942, closes #17126. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
|
It is intended that all metric identifiers referenced in a MathExpression are included in the `usingMetrics` map. This allows passing around complex metrics as a single object, because the math expression object carries around its dependencies with it. This is slightly different than what people might be used to from raw CloudWatch, where there is no hierarchy and all metrics are supposed to be listed in the graph widget or alarm with a unique ID, and then referenced by ID. We can't make this contract obvious anymore by adding a hard validation, but we can add warnings to hint people at the right way to reference metrics in math expressions. Fixes aws#13942, closes aws#17126. ---- *By submitting this pull request, I confirm that my contribution is made under the terms of the Apache-2.0 license*
@madeline-k your workaround seem coherent with the aws docs 🙌https://docs.aws.amazon.com/cdk/v2/guide/cfn_layer.html but I am running into the problem where node is not a |
I see this ticket is closed but Im not sure the underlying issue is resolved? Im looping over some list of resources, creating a math metric, and trying to overlay the metrics within one graph. Looks like thats not possible unless I change the |
There’s no way to assign an ID to a metric in CDK at this point. If you’re creating multiple math expressions within a single dashboard widget, the IDs for the math expressions are missing, and you’ll see that they have the same IDs in the CloudWatch Dashboard, and the metrics in the dashboard widget will be messed up.
Reproduction Steps
The generated CloudFormation file doesn't contain ID for MathExpression (see example below). After deployed, in the CloudWatch, we'll see that all the math expressions are assigned with the same ID, and the dashboard widget shows incorrect metrics
What did you expect to happen?
What actually happened?
The generated Math Expression widget doesn't have an id
Environment
Other
This is 🐛 Bug Report
The text was updated successfully, but these errors were encountered: