Skip to content
This repository has been archived by the owner on Aug 2, 2022. It is now read-only.

Add other changes related to historical workbench #352

Conversation

ohltyler
Copy link
Contributor

@ohltyler ohltyler commented Dec 22, 2020

Issue #, if available:

Description of changes:

This PR is 4 of 4 related to adding the historical detectors to the plugin. Once all 4 PRs are merged into the development branch, there will be a follow up PR to merge the development branch into master.

This PR adds several changes to existing pages, server-side code, redux store, and data models to accommodate the addition of the historical detector workbench.

Changes include:

  • Filtering out historical detectors on existing real-time pages (dashboard and detector list)
  • Adding side nav hierarchy and the additional historical detector list page
  • Wording changes proposed by the tech writer that affected both real-time and historical portions of the plugin
  • Minor formatting changes proposed by UX reviewers that affected both real-time and historical portions of the plugin
  • Updating and adding some data models
  • Adding an isNotSample prop and historical-detector-related props to various chart components to differentiate between real-time results, sample results, and historical results
  • Adds historical detector list in redux store and various functions to retrieve them
  • Adds some checks in getDetector() server function to retrieve task-related info if the detector is historical
  • Adds a Finished detector state that is only applicable to historical detectors
  • Adds and removes some stats in the anomaly history chart, also removes the confidence line chart entirely for the historical detector case

Screenshot of updated anomaly history chart for the historical case.

  1. Removes confidence and last anomaly occurrence fields,
  2. Removes confidence in line chart,
  3. Adds avg anomaly grade stat

Screen Shot 2020-12-28 at 12 36 19 PM

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

@@ -343,7 +370,7 @@ export const AnomalyHistory = (props: AnomalyHistoryProps) => {
{isLoading || isLoadingAnomalyResults ? (
<EuiFlexGroup
justifyContent="spaceAround"
style={{ height: '200px', paddingTop: '100px' }}
style={{ height: '500px', paddingTop: '100px' }}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why change to 500px here ? Will it impact realtime detector?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This change was to prevent the page to look as jerky when in the loading state, since it would often cause the screen to add & remove the scrollbar. It does affect the realtime detector, but improves that as well since it is just an aesthetic improvement.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Got it, will it impact the realtime detector's AD result chart?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, please see above comment. It's an improvement for both real-time and historical.

if (typeof timestamp === 'string') {
return timestamp;
}
return moment(timestamp).format();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we add date format here ? Like "MM/DD/YYYY hh:mm A"

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 catch, will add the enforced output format.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fixed in latest commit.

@@ -184,7 +197,20 @@ export type AnomalySummary = {
lastAnomalyOccurrence: string;
};

export type HistoricalDetectorAnomalySummary = {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this being used? Looks like AnomalySummary can be reused.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a good catch. And actually, the reason for having a separate data model here is because the lastAnomalyOccurrence field is not applicable for the historical detector case, and is not part of the mockups.

Looks like currently, the HistoricalDetectorAnomalySummary type is not being used properly in the AnomalyHistory component. I will need to add a check to show the appropriate summary based on the detector type.

Copy link
Contributor Author

@ohltyler ohltyler Dec 28, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

After looking more, seems it will be easier to not add a new HistoricalDetectorAnomalySummary here at all like you suggested. I've synced up with UX and for the historical detector case, the last anomaly occurrence and the confidence fields are actually removed, and an average anomaly grade field is added. Will adjust accordingly and remove the unnecessary HistoricalDetectorAnomalySummary type.

Copy link
Contributor Author

@ohltyler ohltyler Dec 28, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Per the mockup, have also removed the confidence showing on the chart entirely for the historical detector case. I've added a screenshot showing the changes.

export type DateRange = {
startDate: number;
endDate: number;
};

export type DetectionDateRange = {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think re-using DateRange should be sufficient.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The reason for adding this DetectionDateRange is because the fields understood by the backend take startTime and endTime fields instead of startDate and endDate fields used by the DateRange. I didn't want to add more converting when parsing existing detectors or creating/updating new detectors. Let me know what you think.

default_operator: 'OR',
query: `*${indices.trim().split(' ').join('* *')}*`,
default_operator: 'AND',
query: `*${indices.trim().split('-').join('* *')}*`,
Copy link
Contributor

@ylwu-amzn ylwu-amzn Dec 28, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will it work just splitting by "-" ? Have you tested with " "?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, this is another part of the bug that needed to be fixed. Note that the search field also splits by - in order to properly search for detectors with a - in them. A similar fix needs to be done for detectors that are using indices with - in them. See here for more details.

@ohltyler
Copy link
Contributor Author

Regarding the changes for the anomaly history chart, please see the added screenshot in the description and the latest commit.

@ohltyler ohltyler merged commit aa20f09 into opendistro-for-elasticsearch:historical-workbench-dev Jan 5, 2021
@ohltyler ohltyler added the feature new feature label Jan 21, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
feature new feature
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants