Skip to content
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

Merged
merged 49 commits into from
Sep 23, 2022

Conversation

benakansara
Copy link
Contributor

@benakansara benakansara commented Sep 8, 2022

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 to x-pack/plugins/observability/public/hooks in order to reuse the existing hook.

  • use_fetch_alert_detail.ts
  • use_fetch_alert_detail.test.ts
  • use_fetch_alert_data.ts
  • use_fetch_alert_data.test.ts
  • use_data_fetcher.ts

The alert details page can be opened from the Alerts table "..." -> View alert details and from alerts flyout Alert details button. The appearance of the menu item/button depends on the feature flag xpack.observability.unsafe.alertDetails.enabled.

Checklist

@benakansara benakansara changed the title Displaying alert data in alert summary in alert details page Querying alert data for alert summary Sep 13, 2022
@benakansara benakansara changed the title Querying alert data for alert summary Querying alert data for alert summary component Sep 13, 2022
@benakansara
Copy link
Contributor Author

@elasticmachine merge upstream

@benakansara
Copy link
Contributor Author

Nice Job! 👏🏻

Tested locally for an active and recovered alert. Is this what we expect to see? (some of the fields are not present)

image

I approve (assuming it is OK that some of the fields are not present) but I've added some minor comments :)

Yes, actual value and expected value fields are empty for some rule types. Basically we are showing same values as shown in alert flyout at the moment. Source is empty currently because this will come from context variables which are not available right now.

Copy link
Contributor

@kdelemme kdelemme left a 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 = {
Copy link
Contributor

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

Suggested change
export const alert: TopAlert | null = {
export const alert: TopAlert = {

Copy link
Contributor Author

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 = {
Copy link
Contributor

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.

Suggested change
export const alertWithTags: TopAlert | null = {
export const alertWithTags: TopAlert = {

Copy link
Contributor Author

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.

@fkanout fkanout self-requested a review September 21, 2022 15:38
alertId && ruleId
? `${ALERT_PAGE_LINK}/rules/${encodeURI(ruleId)}/alerts/${encodeURI(alertId)}`
: ALERT_PAGE_LINK,
alertDetails: (alertId?: string | null) =>
Copy link
Contributor

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.

Copy link
Contributor Author

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.

Copy link
Contributor Author

@benakansara benakansara Sep 21, 2022

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.

Copy link
Contributor

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?

Copy link
Contributor Author

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'] ?? '-'}
Copy link
Contributor

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

Copy link
Contributor Author

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?

Copy link
Contributor Author

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.

Copy link
Contributor

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';
Copy link
Contributor

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

Copy link
Contributor Author

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?

Copy link
Contributor

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

Copy link
Contributor Author

@benakansara benakansara Sep 23, 2022

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.

@fkanout fkanout self-requested a review September 23, 2022 12:54
@@ -1,47 +0,0 @@
/*
Copy link
Contributor

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.

Copy link
Contributor Author

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.

Copy link
Contributor

@fkanout fkanout left a 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

@benakansara
Copy link
Contributor Author

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 - for empty tags, however, it was not aligning properly. So I am going to work on both in separate PR. Thank you for the feedback.

@benakansara benakansara enabled auto-merge (squash) September 23, 2022 14:33
@kibana-ci
Copy link
Collaborator

💚 Build Succeeded

Metrics [docs]

Module Count

Fewer modules leads to a faster build time

id before after diff
observability 477 479 +2

Async chunks

Total size of all lazy-loaded chunks that will be downloaded as the user navigates the app

id before after diff
observability 525.4KB 525.5KB +149.0B

History

To update your PR or re-run it, just comment with:
@elasticmachine merge upstream

@benakansara benakansara merged commit 1b496c5 into elastic:main Sep 23, 2022
@kibanamachine kibanamachine added v8.6.0 backport:skip This commit does not require backporting labels Sep 23, 2022
@benakansara benakansara deleted the feature/alert-summary-data branch November 18, 2022 00:04
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
backport:skip This commit does not require backporting release_note:skip Skip the PR/issue when compiling release notes v8.6.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants