-
Notifications
You must be signed in to change notification settings - Fork 8.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
[Secutiy Solution] Timeline kpis #89210
[Secutiy Solution] Timeline kpis #89210
Conversation
…ana into siem-timeline-kpis
Pinging @elastic/security-threat-hunting (Team:Threat Hunting) |
export interface TimelineKpiStrategyResponse extends IEsSearchResponse { | ||
destinationIpCount: Maybe<number>; | ||
inspect?: Maybe<Inspect>; | ||
hostCount: Maybe<number>; |
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.
All of these should technically be optional since Maybe<T> = T | 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.
Yes I agree, you do not need the Maybe or the optional since you will have 0 or the value.
For history, the Maybe is coming from the graphql when we had both type at the same time
|
||
beforeEach(() => { | ||
mockUseSourcererScope.mockImplementation(() => defaultMocks); | ||
useKibanaMock().services.application.capabilities = { |
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.
Can you leave a comment explaining what these are and why their needed?
const getStartSelector = useMemo(() => startSelector(), []); | ||
const getEndSelector = useMemo(() => endSelector(), []); | ||
const isActive = useMemo(() => timelineId === TimelineId.active, [timelineId]); | ||
const from = useDeepEqualSelector((state) => { |
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 isn't specific to your PR, but I wonder what the performance improvement we get for the useDeepEqual vs just useSelector. Like are all these deep checks more costly than just re-rendering? Also, maybe just combining all of them into one, so you're only doing one deep check? 🤷🏾♂️
x-pack/plugins/security_solution/public/timelines/components/flyout/header/kpis.tsx
Show resolved
Hide resolved
|
||
useEffect(() => { | ||
if (isBlankTimeline) { | ||
timelineKpiSearch(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.
What's the point of making a request that'll just return null? Can you comment?
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 was an extra line from an earlier way of doing this that after some refactoring amounted to just a noop basically, good catch though removing.
}, [docValueFields, defaultIndex, timerange, filterQuery]); | ||
|
||
useEffect(() => { | ||
if (isBlankTimeline) { |
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 think we can simplify it just by doing that
if (!isBlankTimeline) {
timelineKpiSearch(timelineKpiRequest);
}
@elasticmachine merge upstream |
Only thing I noticed is when you clear the filters so there's nothing in the view the KPI's don't clear out. Also, given that case ^^ Does it make sense to have the KPI's visible in other views like the pinned events view (see image below)? Maybe that's a question for @XavierM |
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.
Thanks, nice work!
@@ -328,7 +328,7 @@ const FlyoutHeaderComponent: React.FC<FlyoutHeaderProps> = ({ timelineId }) => { | |||
</EuiFlexItem> | |||
|
|||
<EuiFlexItem grow={1}> | |||
<TimelineKPIs kpis={kpis} isLoading={loading} /> | |||
{activeTab === 'query' ? <TimelineKPIs kpis={kpis} isLoading={loading} /> : 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.
If you end up having to push any other changes there's an enum TimelineTabs.query
that you can use here. Not necessary though
💚 Build SucceededMetrics [docs]Module Count
Async chunks
History
To update your PR or re-run it, just comment with: |
* Stub kpi component * search strategy scheleton timeline KPI * search strategy scheleton timeline KPI * Add timeline kpis component and search strategy container * Use getEmptyValue in timeline kpis * Prevent request from being made for blank timeline properly * Add kpi search strategy api integration test * Add jest tests for timeline kpis * Clear mocks in afterAll * Decouple some tests from EUI structure * Combine some selector calls, change types to be more appropriate * Simplify hook logic * Set loading and response on blank timeline * Only render kpi component when query is active tab * Use TimelineTabs enum for query tab string Co-authored-by: Xavier Mouligneau <189600+XavierM@users.noreply.github.com> Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com> Co-authored-by: Xavier Mouligneau <189600+XavierM@users.noreply.github.com> Co-authored-by: Kibana Machine <42973632+kibanamachine@users.noreply.github.com>
Summary
Adds a component to timeline that shows kpi statistics. Also adds a search strategy kpi query to power these statistics, along with a container component that uses a series of hooks to fetch data based on existing timeline filters.
Checklist
Delete any items that are not applicable to this PR.
For maintainers