Do a little more work to get the octopus graph closer to the mocks.
This version gives you a slightly better navigational sense of where
you are in the app, and gives you a clearer
view of the neighbouring stats
Add a basic top graph depicting the current resource's stats
and it's upstreams and downstreams.
Also add upstreams and downstreams tables for this resource
This will be styled more later, but just getting the basic components
and data onto the page.
Add a pod table to the Resource Detail page showing metrics
for pods belonging to a resource.
In the future, I think we'll modify the stat summary endpoint to
take multiple resources as arguments, and have the resource detail page
first query for the pods associated with the resource and then
query for stats for those pods.
See #1467 for discussion.
This PR also modifies the queries to not use the withREST component, in anticipation of the above changes.
Fixes#1493.
When the tap server hydrates metadata for the source or destination peer
of a Tap event from the peer's IP address, it doesn't currently add a
namespace label. However, destinations labeled by the proxy do have such
a label.
This is because the tap server currently gets the hydrated labels from
the `GetPodLabels` function, which is also used by the Destination
service for labeling the individual endpoints in a `WeightedAddrSet`
response. However, the Destination service also adds some labels to all
the endpoints in the set, including the namespace and service, so
`GetPodLabels` doesn't return these labels. However, when the tap server
uses that function, it does not add the service or namespace labels.
This branch fixes this issue by adding those labels to the Tap event
after calling `GetPodLabels`. In addition, it fixes a missing space
between the `src/dst_res` and `src/dst_ns` labels in Tap CLI output
with the `-o wide` flag set. This issue was introduced during the
review of #1437, but was missed at the time because the namespace label
wasn't being set correctly.
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
Closes#1170.
This branch adds a `-o wide` (or `--output wide`) flag to the Tap CLI.
Passing this flag adds `src_res` and `dst_res` elements to the Tap
output, as described in #1170. These use the metadata labels in the tap
event to describe what Kubernetes resource the source and destination
peers belong to, based on what resource type is being tapped, and fall
back to pods if either peer is not a member of the specified resource
type.
In addition, when the resource type is not `namespace`, `src_ns` and
`dst_ns` elements are added, which show what namespaces the the source
and destination peers are in. For peers which are not in the Kubernetes
cluster, none of these labels are displayed.
The source metadata added in #1434 is used to populate the `src_res` and
`src_ns` fields.
Also, this branch includes some refactoring to how tap output is
formatted.
Signed-off-by: Eliza Weisman <eliza@buoyant.io>
* Upgrade to dep 0.5.0, go 1.10.3
* Remove existing dep binary if it's the wrong version
* Add version in filename of dep binary to prevent version conflicts
Signed-off-by: Kevin Lingerfelt <kl@buoyant.io>
This PR started out as a PR to link to our Resource Detail dashboard in
addition to grafana in the resource list pages, but I decided to refactor
the way we deal with our svgs since I was here.
This branch:
- modifies the GrafanaLink component to consist of the grafana icon
that links to grafana adds links to the ResourceDetail page in all our metrics tables
- adds a jsx component we can use to wrap svgs so that we don't get
annoying 404s on images that we have to handle
- remove the relative paths hack for images
- removes unused svg files in /img
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
Kevin Lingerfelt
Risha Mars
Eliza Weisman
Dennis Adjei-Baah
Alex Leong
Alena Varkockova
Adam Christian
Sean McArthur
Ivan Sim