Added Metrics Home Page and date picker

[sejli]

Signed-off-by: Sean Li lnse@amazon.com

Description

Adds Metrics Home Page to Observability side bar and date picker for metrics

Issues Resolved

opensearch-project/dashboards-observability#60
opensearch-project/dashboards-observability#61

Check List

• New functionality includes testing.
  • All tests pass, including unit test, integration test and doctest
• New functionality has been documented.
  • New functionality has javadoc added
  • New functionality has user manual doc added
• Commits are signed per the DCO using --signoff

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

[codecov-commenter]

Codecov Report

Merging #1125 (a1ff68a) into feature/metrics (8e6c6ce) will increase coverage by 0.40%.
The diff coverage is n/a.

@@                  Coverage Diff                  @@
##             feature/metrics    opensearch-project/observability#1125      +/-   ##
=====================================================
+ Coverage              53.12%   53.53%   +0.40%     
  Complexity               291      291              
=====================================================
  Files                    280      279       -1     
  Lines                   9428     9439      +11     
  Branches                2208     2209       +1     
=====================================================
+ Hits                    5009     5053      +44     
+ Misses                  4249     4216      -33     
  Partials                 170      170              

Flag	Coverage Δ
dashboards-observability	47.58% <ø> (+0.54%)	⬆️
opensearch-observability	71.87% <ø> (ø)

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files	Coverage Δ
...lorer/visualizations/config_panel/config_panel.tsx	67.53% <0.00%> (-1.98%)	⬇️
...anes/config_controls/config_panel_option_gauge.tsx	10.00% <0.00%> (-0.53%)	⬇️
...ashboards-observability/common/constants/shared.ts	100.00% <0.00%> (ø)
...hboards-observability/common/constants/explorer.ts	100.00% <0.00%> (ø)
...blic/components/visualizations/charts/vis_types.ts	100.00% <0.00%> (ø)
...c/components/visualizations/charts/bar/bar_type.ts	100.00% <0.00%> (ø)
...trace_analytics/requests/traces_request_handler.ts	17.82% <0.00%> (ø)
...race_analytics/components/common/plots/box_plt.tsx	67.56% <0.00%> (ø)
...tics/components/common/plots/service_map_scale.tsx	100.00% <0.00%> (ø)
...ules/visualization_flyout/visualization_flyout.tsx	42.55% <0.00%> (ø)
... and 9 more

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

[kavithacm]

minor changes

[pjfitzgibbons]

Ideas for next code-change.

Feel free to reply with questions or discussion.

[pjfitzgibbons]

HI Sean. This is an after-the-fact review, to keep in mind for next time.
A few points are coming to mind for this Fn.

1. The new component (metrics/index) seems to be the singular use for this Fn. I think this might be an exercise in premature optimization. I would rather we avoid separating supporting code from it's use until we have a compelling case for it's re-use. We also want to be careful about separating callback-Fns from their use-case. This is a non-pure Fn. with its use of setRCU, setStart, setEnd, so side-effects are many. This would also be hard to unit-test, because there is little we can do to test the "effect" of setRCU, setStart, setEnd beyond just ensuring they are "called", which is quite a weak test -- and also brittle - a test of this Fn. could not endure any refactoring at all.

Thanks for considering these points in your next code-change.

[pjfitzgibbons]

if onTimeChange were included in this component's code, it's usage would be clear, you would be able to reduce the args of the Fn (setRCU, setStart, setEnd are in-context). This callback (onDatePickerChange) could have been reduced to :

(props) => {
onTimeChange(props);
onRefreshFilters(props);
}

onRefreshFilters would need a simple refactor to destructure the props instead of taking args-list.

[mengweieric]

Do we need these commented out code?