-
Notifications
You must be signed in to change notification settings - Fork 8.3k
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
Displaying alert data in alert summary in alert details page #140339
Displaying alert data in alert summary in alert details page #140339
Conversation
…/alert-summary-data
…ansara/kibana into feature/alert-summary-data
…/alert-summary-data
@elasticmachine merge upstream |
Yes, |
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.
just one or two nits but otherwise good job 👏🏻 !
|
||
export const tags: string[] = ['tag1', 'tag2', 'tag3']; | ||
|
||
export const alert: TopAlert | null = { |
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: the type is not null
export const alert: TopAlert | null = { | |
export const alert: TopAlert = { |
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.
done 👍
lastUpdated: 1630588131750, | ||
}; | ||
|
||
export const alertWithTags: TopAlert | null = { |
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: Same as above regarding the type. And also, we could reuse the base alert defined above and only override the 'kibana.alert.rule.tags': tags
to make it clearer what is changing between the two Alerts.
export const alertWithTags: TopAlert | null = { | |
export const alertWithTags: TopAlert = { |
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.
Good idea, I have modified the alert data.
alertId && ruleId | ||
? `${ALERT_PAGE_LINK}/rules/${encodeURI(ruleId)}/alerts/${encodeURI(alertId)}` | ||
: ALERT_PAGE_LINK, | ||
alertDetails: (alertId?: string | null) => |
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.
@benakansara, To create the alert details page, we need the ruleId
. Also, we need to make these arguments NOT optional.
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.
After investigating further, I found that there is an http API and also that it is the recommended approach to get alert data. This API doesn't require ruleId
. I will make alertId
not optional.
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.
@fkanout BTW, I was thinking about the parameters. Actually they are not optional. You would still need to pass arguments while calling the function, but it could accept undefined or null. With optional arguments, you could call the function without passing anything at all.
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.
That's great you found the API that gives us all we need about an alert without ruleId
. 👏🏻
Regarding the function arguments, I don't see a use case where we call this function without the alertId
. For me,
the function signature should be alertDetails: (alertId: string) =>
. Am I missing something here?
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.
No, you are right, I have already changed it to alertDetails: (alertId: string) =>
.
</EuiTitle> | ||
<EuiSpacer size="s" /> | ||
<EuiText size="s" color="subdued"> | ||
{alert?.fields['kibana.alert.evaluation.value'] ?? '-'} |
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.
Instead of writing hardcode the fields' names which could be changed or mistakenly typed. You can use ParsedTechnicalFields
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.
Do you mean to use this file packages/kbn-rule-data-utils/src/technical_field_names.ts
instead of hardcoding field names? If not, can you please elaborate on how to use ParsedTechnicalFields
?
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 have removed hardcoded field names with fields from @kbn/rule-data-utils
.
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.
Awesome 💯 👍🏻 !!
* 2.0. | ||
*/ | ||
|
||
export const DEFAULT_DATE_FORMAT = 'MMM D, YYYY @ HH:mm:ss.SSS'; |
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.
Why do we need to define this? I think the date format is config that is shared across Kibana
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 saw it is defined at many places. When I tried to import from one of the plugins, it was giving error as it was not exposed to use outside of that plugin. I would then have to modify index file of this plugin and export the constant. That's why I created this file. Could you please point me to config which I can use?
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 don't remember where I saw it, maybe as a helper formatter
. But If you don't find it or it will take more time, keep it like this and can refactor it later one
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.
sure, I will keep an eye on it. If I find helper formatter or config in future, I will update it.
.../plugins/observability/public/pages/alerts/components/alerts_flyout/alerts_flyout_footer.tsx
Show resolved
Hide resolved
…ansara/kibana into feature/alert-summary-data
…ansara/kibana into feature/alert-summary-data
…ansara/kibana into feature/alert-summary-data
…-ref HEAD~1..HEAD --fix'
@@ -1,47 +0,0 @@ | |||
/* |
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.
@benakansara, I think this was the right way to organize the code. I mean, putting the main component in the index.tsx
, and then pulling the components that this page is composed of.
I don't think putting the main page/container in the component folder is the correct convention.
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.
@fkanout I refactored the code to be consistent with other refactoring efforts suggested by @maryam-saeidi - #139606 (comment). From my perspective, putting main component in index.tsx
feels right way too, but I also think it is better to be consistent as much as possible.
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.
Tested locally and it works as expected. Awesome job, @benakansara!!
I left you some comments, but they could be handled with a follow up PR
Regarding the empty fields/not provided, we need to align the fields. e.g Rule tags
don't
have -
like the Actual value
I will work on the rule tags in new PR. The design of the tags is different than on rule details page, and I tried to put |
💚 Build Succeeded
Metrics [docs]Module Count
Async chunks
History
To update your PR or re-run it, just comment with: |
Summary
Implements #139269
Querying alert data with http API using existing hook under
x-pack/plugins/observability/public/pages/cases
.I have moved following files from
x-pack/plugins/observability/public/pages/cases
tox-pack/plugins/observability/public/hooks
in order to reuse the existing hook.The alert details page can be opened from the Alerts table
"..." -> View alert details
and from alerts flyoutAlert details
button. The appearance of the menu item/button depends on the feature flagxpack.observability.unsafe.alertDetails.enabled
.Checklist