Imports lodash function individually, eliminate 'import _ from lodash'
This branch replaces imports of all of lodash (import _ from 'lodash' with per
function imports e..g import _isNil from 'lodash/isNil'. This reduces the bundle
size from~520 kb to ~160kb.
I've also taken the opportunity to replace our use of lodash functions with
native js functions where it makes sense (e.g. some maps, concats, sizes).
Try to squish the metrics columns so that the data fits on the page without
having to scroll the table. This was mostly evident in the Tap and Top tables,
where a lot of the table content would be initially out of view.
This branch also includes an unrelated tiny fix for max error length, which had
been changed from 500 to 50 for testing, and had not been changed back
* Re-add sortable column headers to tables in web UI
* Display sort icons on all sortable columns
* Disable src/dst popover in top table
Signed-off-by: Kevin Lingerfelt <kl@buoyant.io>
Switch the dashboard's component library from antd to material-ui.
There are extensive changes to most of the frontend components in the app.
This branch changes all uses of antd components to their closest equivalent in
material. There is still a lot of polish that needs to go into the look of
individual components, but since the major component rewrites are done, I think
get this work in so that further work can be done in smaller branches.
Changes in this branch:
- add Material-UI 3.2.2 to the project
- replace all uses of antd with material-ui components
- remove antd from the project
- slight modifications of eslint rules
- restructuring of app components to be rendered under the Navigation
component
- deleted most of our css (replaced with material's inline styles)
- pinned package versions in package.json (mostly removing ^)
There are two variables we use to control the volume of Top output,
maxRowsToDisplay, which controls how many rows are in the table, and
maxRowsToStore, which controls the size of the event index we keep in memory for
aggregating results.
Previously, we were only keeping in index maxRowsToDisplay rows, which for the
Resource Detail page was 10 (which is really small for high traffic rest-y
resource traffic - it causes rows to be deleted from the index too soon, and
then causes the data in the table to change a lot). Change this to store
maxRowsToStore rows, and also bump this to 50. This allows us to store results
for longer, and also ensures more consistent data over time.
Another fix for the appearance of the Top columns is to add fixed widths to the
metrics. This will prevent the table from wobbling from side to side.
A bunch of web UI tweaks:
- Add a small success rate chart to the metrics tables
- Improve latency formatting for seconds latencies
- Rename upstream/downstream to inbound/outbound
- Make Top table look consistent with rest of tables on page
- Fix widths of metrics column columns so that tables align
Consolidate the source and destination columns into one column,
and add a direction column (To/From) so the user knows if the
displayed resource is src/dst.
* Use Tap data on Resource Detail page to display unmeshed resources
that send traffic to the specified resource.
* Don't update neighbors on every websocket recv; this causes too much rendering.
Instead, store in internal variable and update with the api results.
This branch uses the src data from tap to discern which unmeshed resources are
sending traffic to the specified resource. We then show this resource in the
octopus graph.
Note that tap is sampled data, so it's possible for an unmeshed resource to not
show up. Also, because we won't know about the resource until it appears in the
Tap results, results could pop into the chart at any time.
Add a Top page to the linkerd web UI. This is the web equivalent of #1435.
I've used the same fields as in the current implementation.
This branch also includes some slight refactors to the Tap code to enable code reuse.
The request processing logic is pretty similar to that in Tap.jsx, except that we can
immediately discard the result once we receive the response end and aggregate
that result into the top results. So the index of tap results will tend to be smaller
(unless they're long running requests like streaming). But we also add a similar
index of aggregated Top results, and discard oldest results if top has been
running for a long time.
* Add a Top page to the web UI
* Refactor Tap event parsing into common util code
* Small refactors to the TapQueryForm and the CliCmd display to accomodate Top
* Collate tap events based on the ID (src, dst, stream)
* Also refactor keying of req/rsp/end into requestInit/responseInit/responseEnd for clarity
* Use pod labels when present in top
* Fix bug where src/dst were switched in the Tap display table
Risha Mars
Kevin Lingerfelt