Conversation
|
@XavierM There's a new requirement to display alerts in the Observability Overview page #124370 (comment). I drafted this PR to quickly bring existing Observability alerts table in overview page and pretty much works apart from an issue in the UI part. From what I can tell there's a hardcoded |
| import { AddToCaseAction } from '../../actions/timeline/cases/add_to_case_action'; | ||
| import { TGridLoading, TGridEmpty, TimelineContext } from '../shared'; | ||
|
|
||
| const FullWidthFlexGroup = styled(EuiFlexGroup)<{ $visible: boolean }>` |
There was a problem hiding this comment.
@XavierM FullWidthFlexGroup has a hardcoded min-height, so I stopped using the one defined in the styles https://github.com/elastic/kibana/blob/main/x-pack/plugins/timelines/public/components/t_grid/styles.tsx#L466 and redefined a new style for FullWidthFlexGroup. Do we actually need this hardcoded min-height? Even integrated tGrid gets rid of the min-height https://github.com/elastic/kibana/blob/main/x-pack/plugins/timelines/public/components/t_grid/integrated/index.tsx#L83
With this change table looks much better (apart from the unnecessary scrollbar which is related to another issue)

There was a problem hiding this comment.
Would it make sense to make the min-height a prop of the pre-existing FullWidthFlexGroup instead of duplicating it?
There was a problem hiding this comment.
@afgomez It looks like min-height is not being used at all in the integrated version of t-grid and with this PR is it also removed from the standalone version of t-grid. Soon Alerts 2.0 is coming, where quite many things will be cleaned up. I suggest we keep it as it is for now if you don't mind.
|
@mgiota thanks a lot for this PR! I'm going to push some changes, if that's ok with you, mainly removing the old alerts table and probably reverting the changes to the new overview page. I need to discuss this with the team, but I'm unsure of the need for the new page. It was a decision taken months ago about how to proceed with the overview page redesign and we thought that having a completely new page behind a feature toggle was the right approach, but now we are making changes to the "old" one and maybe that "new" page doesn't make sense anymore. So, to keep future changes easier I think is better if we only make them to the "old" overview page. If in the future we want to have a "new" page we can add the alerts table there at that point. |
|
@mgiota I pushed 3 commits to this PR:
If you see that everything is fine, I think this PR should be ready for review. |
| </EuiPanel> | ||
| </EuiFlexItem> | ||
| <AlertsTableTGrid | ||
| setRefetch={() => {}} |
There was a problem hiding this comment.
I'm also not sure what's this, but looking at the code for the alerts page maybe we don't need this. Maybe one option is to mark it as optional?
There was a problem hiding this comment.
@estermv This was my initial thought as well, to make setRefetch optional, but then the whole page breaks, because apparently tGrid expects setRefetch to be there. I didn't have a closer look but you can have a look at how it is implemented in alerts_page https://github.com/elastic/kibana/blob/main/x-pack/plugins/observability/public/pages/alerts/containers/alerts_page/alerts_page.tsx#L222 and do something similar.
There was a problem hiding this comment.
I added the setRefetch function. From what I understand setRefetch is used to set a function to update the tGrid from outside it. On the overview page, we need it when the user clicks on the "Refresh" button next to the datepicker.
|
@estermv I agree with the changes you pushed to the PR. Especially removing the state container. I was planning to revert this changes, since you already have the mechanism to get the information you need from routeParams. |
|
@elasticmachine merge upstream |
|
@elasticmachine merge upstream |
|
Pinging @elastic/unified-observability (Team:Unified observability) |
| import { AddToCaseAction } from '../../actions/timeline/cases/add_to_case_action'; | ||
| import { TGridLoading, TGridEmpty, TimelineContext } from '../shared'; | ||
|
|
||
| const FullWidthFlexGroup = styled(EuiFlexGroup)<{ $visible: boolean }>` |
|
@elasticmachine merge upstream |
|
The behavior in the Alerts page, when no alerts occurred, is to show an empty table. Is consistent behavior between the Alerts page and the overview page required from the Alert table perspective?
|
|
|
||
| export function useAlertIndexNames() { | ||
| const { data: indexNames = NO_INDEX_NAMES } = useFetcher(({ signal }) => { | ||
| return callObservabilityApi('GET /api/observability/rules/alerts/dynamic_index_pattern', { |
There was a problem hiding this comment.
Is it ok to hardcode this endpoint URL? Usually, this kind of code is shared centrally.
There was a problem hiding this comment.
Do you mean to pass it as a parameter of the hook? I think in this case the URL is directly tied to the hook because, as far as I understand, this is the endpoint that will return us the index names, so I don't think it will make sense to use the hook with a different URL.
What do you think @mgiota?
There was a problem hiding this comment.
@estermv I think it is fine to keep it here
| query: { | ||
| namespace: 'default', | ||
| registrationContexts: [ | ||
| 'observability.apm', |
There was a problem hiding this comment.
Same here for hardcoded registrationContexts. It seems that these values are technical filed-like?
There was a problem hiding this comment.
I understand your point here, but I would prefer to keep this inside the hook because at this point we want always the same registrationContexts. We can always refactor it in the future if we need to.
There was a problem hiding this comment.
@fkanout I see your point and it would be nice to have constants for the registration contexts. As part of this PR I extracted existing functionality to a new hook https://github.com/elastic/kibana/blob/main/x-pack/plugins/observability/public/pages/alerts/containers/alerts_page/alerts_page.tsx#L148, so we could definitely refactor this in a follow up PR
| @@ -0,0 +1,32 @@ | |||
| /* | |||
| import { AddToCaseAction } from '../../actions/timeline/cases/add_to_case_action'; | ||
| import { TGridLoading, TGridEmpty, TimelineContext } from '../shared'; | ||
|
|
||
| const FullWidthFlexGroup = styled(EuiFlexGroup)<{ $visible: boolean }>` |
There was a problem hiding this comment.
Would it make sense to make the min-height a prop of the pre-existing FullWidthFlexGroup instead of duplicating it?
|
@elasticmachine merge upstream |
💛 Build succeeded, but was flakyTest Failures
Metrics [docs]Async chunks
History
To update your PR or re-run it, just comment with: |
|
Friendly reminder: Looks like this PR hasn’t been backported yet. |
1 similar comment
|
Friendly reminder: Looks like this PR hasn’t been backported yet. |
* render alerts in overview page * pass routeParams * create useAlertIndexNames hook * remove unused file * use alertIndexNames hook in new overview page * remove unused stuff * fix failing tests * remove min-height from FullWidthFlexGroup in standalone t-grid * Remove old alerts section from overview and use same style as other sections * remove alertsStateContainer from overview page * revert changes in new overview page * Add refetch function to alerts table * Fix type * rename file * remove not needed check * fix types Co-authored-by: Ester Marti <ester.martivilaseca@elastic.co> Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>




Part of #124370. There will be some follow-up PR to polish the table for the overview page.
@estermv Here's a quick draft PR that brings the alerts table in Overview page. I did two changes to make this work:
Above two changes were enough to bring existing alerts table in the Overview page.
AlertsTableTGridis expecting asetRefetchprop. I didn't dive deeper into this, so for now I just passed an empty function.As you will see in the screenshots below, there are UI issues, since there is a min-height applied to the alerts table. We would need to see how we could parameterize it in the timelines plugin or playaround with css.
This is an initial draft. I can clean it up a bit and open it for review. Or you can take it from here. Let me know what's best for you.