Remove old unused graphs from the web code (scatter plot and line graph)
and their associated css
Files removed:
web/app/css/line-graph.css
web/app/css/list.css
web/app/css/scatterplot.css
web/app/css/version.css
web/app/js/components/LineGraph.jsx
web/app/js/components/ScatterPlot.jsx
Currently conduit stat outputs a column that shows the number of meshed pods in the resource being
queried. The web UI does not have this information about meshed pod state.
This commit adds a meshed column for better UI parity with the stat command.
Signed-off-by: Dennis Adjei-Baah <dennis@buoyant.io>
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
This an initial implementation of the `linkerd top` command. This command launches an ncurses style tabular view of current requests (using data from tap). Most of the command line arguments are the same as tap and allow selecting the resource to inspect and filtering which requests to view.
Fixes#1283
Signed-off-by: Alex Leong <alex@buoyant.io>
Tap.jsx is really large and contains a lot of logic that pertains only to the Tap Query Form.
This PR tries to separate the concerns of the form and the query display from the main
Tap querying and rendering logic.
This will also allow us to easily reuse this form/CLI formatting for the Top page.
Changes in this PR:
* moves all the code for the form into its own component (TapQueryForm)
* moves the code that displays the current query into its own component (TapQueryCliCmd)
* formats the current tap query as the equivalent command line format that you
can paste into a terminal
Now that we have source metadata in tap events, we can display
the pod name in the UI instead of the IP. I've also added a popover
that shows deploy and pod info if we have it.
Also adds another table in the expanded row view to show all the
metadata we have. This table probably won't stick around forever,
but I'm just displaying all the data we have right now.
Based on @adleong's suggestion in
https://github.com/linkerd/linkerd2/pull/1434#pullrequestreview-145428857,
this branch adds label hydration from destination IPs to the Tap server.
This works the same as the label hydration for destination IPs added in
#1434. However, it is only applied to the destination fields of events
recorded by proxies in the inbound direction, since outbound
destinations are already labeled with metadata provided by the
Destination service.
This means that when a user taps inbound traffic, the CLI will show k8s
metadata labels for the destination peer (if it's available). This can
be useful especially when tapping several pods at once, as it makes it
easier to distinguish what pod received a request.
This branch also refactors how the label hydration is performed,
primarily to make adding it to the destination field less repetitive.
Also, the `hydrateIPLabels` function now mutates the label map in the
`TapEvent`, rather than returning a new map of labels, so that the case
where no pod was found doesn't require an additional allocation of an
empty map.
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
The `TapEvent` protobuf contains two maps, `DestinationMeta` and
`SourceMeta`. The `DestinationMeta` contains all the metadata provided
by the proxy that originated the event (ultimately originating from the
Destination service), while the `SourceMeta` currently only contains the
source connection's TLS status.
This branch modifies the Tap server to hydrate the same set of metadata
from the source IP address, when the source was within the cluster. It
does this by adding an indexer of pod IPs to pods to its k8s API client,
and looking up IPs against this index. If a pod was found, the extra
metadata is added to the tap event sent to the client.
This branch also changes the client so that if a source pod name was
provided in the metadata, it prints the pod name rather than the IP
address for the `src` field in its output. This mimics what is currently
done for the `dst` field in tap output. Furthermore, the added source
metadata will be necessary for adding src resource types to tap output
(see issue #1170).
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
We have a new format for displaying errors in ErrorBanner.
When a websocket error occurred, we'd pass in text where ErrorBanner
expects and object. This PR puts the websocket errors in an object
Also clean up the display of the error by removing redundant text.
Problem:
We depend on the websocketRequestSent bool (renamed to
tapRequestInProgress in this branch) to determine whether the
start/stop button says start or stop. However, we don't change
this value in setState until we open the websocket connection
(which could take some time). This led to a delay in when you
press the Start button and when it changes colour.
Solution:
Set the state before waiting for the websocket to open, so the
button colour changes immediately and the form feels more responsive
* Changing the statusText to be an object with more fields, then displaying them in the ErrorBanner
Signed-off-by: Adam Christian <adam@buoyant.io>
Refactoring karma tests and propTypes and defaultProps per the code review from @rmars
Signed-off-by: Adam Christian <adam@buoyant.io>
Changing the default message to pass the ServiceMeshTest ErrorBanner assertion
Revert "Changing the default message to pass the ServiceMeshTest ErrorBanner assertion"
This reverts commit 2415b7099b03ad7a8deda9f67218bb531111b3ec.
Fixing the failing karma unit tests because the statusMessage wasn't being properly passed into the component rendering stub context
Signed-off-by: Adam Christian <adam@buoyant.io>
merging master in
Signed-off-by: Adam Christian <adam@buoyant.io>
* Export api error type independently from ApiHelpers
Signed-off-by: Adam Christian <adam@buoyant.io>
Closes#776.
This branch adds the following validation to the `linkerd stat` command:
* The `--to` and `--from` flags are now mutually exclusive
* The `--to-namespace` and `--from-namespace` commands are also mutually
exclusive.
* The `namespace` resource type conflicts with the `--namespace`,
`--to-namespace`, and `--from-namespace` flags.
Examples:
```
$ bin/go-run cli/main.go stat deploy --to deploy/foo --from deploy/bar
Error: --to and --from flags are mutually exclusive
Usage:
linkerd stat [flags] (RESOURCE)
...
```
```
$ bin/go-run cli/main.go stat deploy --to-namespace foo --from-namespace bar
Error: --to-namespace and --from-namespace flags are mutually exclusive
Usage:
linkerd stat [flags] (RESOURCE)
...
```
```
$ bin/go-run cli/main.go stat namespace foo --namespace bar
Error: --namespace flag is incompatible with namespace resource type
Usage:
linkerd stat [flags] (RESOURCE)
...
```
```
$ bin/go-run cli/main.go stat ns --to-namespace bar
Error: --to-namespace flag is incompatible with namespace resource type
Usage:
linkerd stat [flags] (RESOURCE)
...
```
```
$ bin/go-run cli/main.go stat namespace --from-namespace bar
Error: --from-namespace flag is incompatible with namespace resource type
Usage:
linkerd stat [flags] (RESOURCE)
...
```
```
$ bin/go-run cli/main.go stat ns/foo --from-namespace bar
Error: --from-namespace flag is incompatible with namespace resource type
Usage:
linkerd stat [flags] (RESOURCE)
...
```
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
Fixes#1405.
According to the Kubernetes Endpoints API documentation, the `name`
field in the `EndpointPort` response object is "Optional if only one
port is defined". (see
https://v1-9.docs.kubernetes.io/docs/reference/generated/kubernetes-api/v1.9/#endpointport-v1-core)
However, when the Destination service an endpoints response for a
service with a named target port, it expects the ports in the endpoints
response to have the same name as the target port in the service.
When a user creates a `NodePort` service with an unnamed port that
targets a named container port, this behaviour results in Linkerd
failing to route to that service by hostname. Without Linkerd injected,
the hostname is still reachable.
This branch fixes this issue by changing the `endpointsToAddresses`
function in `endpoints_watcher.go` to handle the case when an endpoints
response contains only a single unnamed port.
I've manually verified that this fixes the issue described in #1405.
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
Problem:
Currently the web UI's resource autocomplete also lists authorities.
However you can't tap authorities in this way, you have to use --authority
in addition to whatever resource you're trying to tap.
The web UI is confusing as it presents authorities in that list.
Those authorities should instead be moved to the Authority box in the advanced filter form.
Solution:
* Don't present authorities as options in the Resource dropdowns
* Add authority autocomplete to authority form input
Follow up to @kl in #1391 there is an error when we try to tap an authority
Add client side filtering to the tap table, so that we can narrow down
queries while still tapping a whole resource.
There are two general kinds of filters here:
- filters where the number of possible values is bounded/small and
we know them (e.g. inbound/outbound, grpc status). here, I've tried to
hardcode the list of possible options with explanations (see the GRPC status filters)
- filters where the number of possible values can be very large (e.g. paths)
here, I've generated the list of options as we process the incoming data.
I also periodically delete the oldest filter option so the list of filters
doesn't grow unbounded
Filters added:
- GRPC status code filters
- http status filters
- path filters
- scheme filters
- tls, destination and source filters
* Make use of the Web UI to render tap events in a table
- Return JSON tap events instead of the command line output
- Experiment with a different way of rendering the EventList
- changed the default width back to 100% of the screen because this
table does not look great squished
Currently, when a cluster has over 100 pods injected with the Linkerd2
proxy, Prometheus metrics are not collected correctly. This is because
Prometheus appears to be making more concurrent requests than its'
proxy's outbound router cache can handle See issue #1322 for further
details.
This branch introduces a workaround for this issue, by increasing the
outbound router cache capacity to 10000 routes for the Prometheus pod's
proxy only. The router capacity limit of 100 active routes is primarily
due to the limitation of the number of active Destination service
lookups, so increasing the capacity for the Prometheus pod specifically
is probably okay, as the scrape requests are made to IP addresses
directly and therefore will not cause service discovery lookups.
This change was originally implemented and tested in @siggy's PR #1228.
I've rebased his branch onto the current `master`, and updated the code
to reflect the project name change.
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
Co-authored-by: Andrew Seigner <siggy@buoyant.io>
The `reader.Read` method only reads as many bytes as are currently available from reader. When reading the 4 byte message length header, if not all 4 of those bytes are available, `Read` will only read the available bytes and return. This causes alignment issues when the message body is read and there are still unread header bytes in the reader. These bytes will appear at the beginning of the message body and cause a crash when the message is unmarshalled.
Use `io.ReadFull` to ensure that we read all 4 of the message length header bytes.
Fixes#1287
Signed-off-by: Alex Leong <alex@buoyant.io>
This change is a simplified implementation of the Builder.Path() and
Visitor().ExpandPathsToFileVisitors() functions used by kubectl to parse files
and directories. The filepath.Walk() function is used to recursively traverse
directories. Every .yaml or .json resource file in the directory is read
into its own io.Reader. All the readers are then passed to the YAMLDecoder in the
InjectYAML() function.
Fixes#1376
Signed-off-by: ihcsim <ihcsim@gmail.com>
* Update ant to 3.7.2
* Add autocomplete of namespaces/resources to Tap in web ui
* Add form fields for authority/path/method/rps/scheme
* Add the ability to clear error messages to the error banner
* Add error listener to ws object
* bin/test-cleanup: Delete test namespaces in paralllel.
My kubectl (1.9.4) waits until the `kubectl delete` operation completes,
unlike previous versions which issue the deletion request and then
immediate return. As a result of this change, bin/test-cleanup become
much slower since each deletion was happening serially. Fix this by
issuing all the deletions in parallel with a single `kubectl delete`.
Signed-off-by: Brian Smith <brian@briansmith.org>
Without this change the Linux build fails. Apparently
commit 554ffe6a46 added the use of a
bash-specific feature.
Signed-off-by: Brian Smith <brian@briansmith.org>
Speed up incremental rebuilds by avoiding relinking the controller
and/or web executables when changes are made to unrelated files.
Before this change, any time the git tag changed, the executables
would have to be rebuilt (relinked at least), even if no Go files
changed.
Validated by running the integration tests.
Signed-off-by: Brian Smith <brian@briansmith.org>
* Allow docker-build-proxy to override the proxy version
* Update based on review feedback
* fetch-proxy should return full path to executable
Signed-off-by: Kevin Lingerfelt <kl@buoyant.io>
Adds a tap endpoint in the web api that communicates with the dashboard
via websockets.
I've moved a bunch of code from the cli tap.go into utils so that the code
can be shared between web and CLI. I think we should consider making the
display more suited to web, but in the short term, reusing the CLI's
rendering of tap events works.
Adds a Tap page in the Web UI that you can use to make tap requests.
The form currently only allows you to enter a resource and namespace,
other filters coming in a follow-up branch.
Risha Mars
Dennis Adjei-Baah
Alex Leong
Alena Varkockova
Eliza Weisman
Kevin Lingerfelt
Adam Christian
Sean McArthur
Ivan Sim
Brian Smith