-
-
Notifications
You must be signed in to change notification settings - Fork 4.2k
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
feat(anomaly detection): add anomaly chart preview to new alert #78238
base: master
Are you sure you want to change the base?
Conversation
❌ 7 Tests Failed:
View the top 3 failed tests by shortest run time
To view individual test run time comparison to the main branch, go to the Test Analytics Dashboard |
f9b0916
to
87ad8b7
Compare
87ad8b7
to
5c52250
Compare
5c52250
to
5c0ef18
Compare
5c0ef18
to
98df95f
Compare
bdd69de
to
d25ff37
Compare
88f76fd
to
48c5e4d
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
mostly just comments about the prop drilling for anomalies and hoping we can create a context. if that's out of scope and want to take it on with ACI, that's cool too.
const firstPoint = new Date(dataArr[0]?.name).getTime(); | ||
const lastPoint = new Date(dataArr[dataArr.length - 1]?.name).getTime(); | ||
const startDate = new Date(dataArr[0]?.name); | ||
const endDate = new Date(dataArr[dataArr.length - 1]?.name); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
need to do any status checks to ensure that dataArr[dataArr.length - 1]?.name
isn't the same value as dataArr[0]?.name
?
silent: true, // potentially don't make this silent if we want to render the `anomaly detected` in the tooltip | ||
data: anomalyBlocks, | ||
}, | ||
}); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🔴 - nice.
@@ -144,6 +149,8 @@ type State = { | |||
triggerErrors: Map<number, {[fieldName: string]: string}>; | |||
triggers: Trigger[]; | |||
activationCondition?: ActivationConditionType; | |||
chartError?: boolean; | |||
chartErrorMessage?: string; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🤔 should we add a context to maintain more of these props? (it's also cool if we don't, and plan to refactor this stuff when we get to ACI work)
@@ -931,6 +956,7 @@ class RuleFormContainer extends DeprecatedAsyncComponent<Props, State> { | |||
seasonality: AlertRuleSeasonality.AUTO, | |||
}; | |||
break; | |||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: omit the {}
s for consistency with the other switches - we should probably ensure there's a lint rule one way or the other.
includeTimeAggregation: false, | ||
includeTransformedData: false, | ||
limit: 15, | ||
children: noop, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
are the components using these props, using children
as a renderProp? (could we just pass null instead?)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah this is decidedly not clean—I think the ideal end state here (after ACI) is that these declarative *Request
components go away.
They're already deprecated so I don't want to invest too much in cleaning this up.
@@ -447,32 +465,165 @@ class TriggersChart extends PureComponent<Props, State> { | |||
}; | |||
|
|||
if (isOnDemandMetricAlert) { | |||
const {sampleRate} = this.state; | |||
const baseProps: EventsRequestProps = { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
could we change these baseProps to provide to a context? That way we could decompose all of these sub components fairly easily. I'm a bit nervous about the complexity of this component and being able to grok it.
@@ -63,6 +66,7 @@ import ThresholdsChart from './thresholdsChart'; | |||
|
|||
type Props = { | |||
aggregate: MetricRule['aggregate']; | |||
anomalies: Anomaly[]; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i'd kinda expect these to be loaded as something else into the Chart component (rather than anomalies). something more like a generic for data or something along those lines? 🤔
@@ -28,6 +30,7 @@ import type {MetricRule, Trigger} from '../../types'; | |||
import {AlertRuleThresholdType, AlertRuleTriggerType} from '../../types'; | |||
|
|||
type DefaultProps = { | |||
anomalies: Anomaly[]; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
might be nice to create a context just for anomalies so we can avoid prop drilling
@@ -0,0 +1,154 @@ | |||
import type {MarkAreaComponentOption} from 'echarts'; | |||
import moment from 'moment-timezone'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
idk how kosher this is, but it might be nice to use built in Intl / Datetime stuff rather than moment 😅
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah dropping moment
would be great! Going to punt on that until frontend tsc makes some decisions on https://github.com/getsentry/frontend-tsc/issues/69
// Seven days is actually 10080m but Snuba can only return up to 10000 entries, for this | ||
// we approximate to 9998m which prevents rounding errors due to the minutes granularity | ||
// limitations. | ||
SEVEN_DAYS = '9998m', | ||
SEVEN_DAYS = '7d', |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is what's breaking the tests currently. Can try to add more hacks to workaround the limitation, but probably worth asking if this is still needed?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1 about asking, unfortunately I don't have context over it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
JS / reasoning behind implementation sounds good to me - i'd recommend having someone on anomaly detection do a quick pass to make sure the UI / features are working as expected.
Adds anomaly chart visualization to new alert form (
ruleForm.tsx
+<TriggersChart />
).Related PRs:
Closes https://getsentry.atlassian.net/browse/ALRT-289