scope-app:
* Adds `-app.metrics-graph` cli flag for configuring the base url to
use for graph links; supports :orgID and :query placeholders
* Assigns query URLs to existing metrics and appends empty metrics if missing
scope-ui:
* Extends <CloudFeature /> with option alwaysShow
* Adds <CloudLink /> to simplify routing when in cloud vs not in cloud
* Links metric graphs in the ui's node details view for all k8s
toplogies and containers so far
* Tracks metric graph click in mixpanel `scope.node.metric.click`
* Uses percentages and MB for CPU/Memory urls
* Passes timetravel timestamp to cortex in deeplink
This guarantees that the output won't contain bare nodes containing
just an id and topology, as produced by ipToNode. Previously this was
ensured by calling convention, now it's ensured by construction.
When the scope-app restarts, it no longer has a
reference to the previous node set. Therefore,
the delta update adds *all* nodes but does not
remove legacy ones.
`reset==true` tells the frontend to start fresh.
Fixes#2708
The figure is inaccurate since it counts containers across all
hosts. Getting the count correct is non-trivial, so it's better to not
show the figure at all.
NB: the count still shows up on mouse-over of the link, but that is
defensible and not (very) confusing since the link represents the
image, not the image on a particular host, and it's the same count
that show up as the minor label in the container images view.
Fixes#2681.
The same container image may be in use on multiple hosts. The
latest-map HostNodeID of a node in the ContainerImage topology is
therefore meaningless - it gets set to whatever host reported that
image last in the time window covered by the report. Hence using it as
a basis for mapping to hosts, as we did, a) fails to associate images
with all the right hosts (hence they are missing from the host details
panel), and b) causes that association to change semi-randomly (hence
the list in the details panel is unstable).
By contrast, the host topology parents of container image nodes is the
complete set of all hosts the image is used on. So making that the
basis for mapping fixes the problem.
The same technique - mapping based on host parents rather than
latest-map HostNodeID - also works for the other nodes we are mapping:
processes, containers and pods. So we might as well use it there
too. That's also what Map2Parent does in other topology renderers.
Fixes#2629.
This map function isn't actually needed.
Children are only populated from mapping to parents during rendering,
so there's no pre-existing replicasets to map.
Simply having the Map2Parent function map pods to deployments has it do the right thing.
Use a special kind of selector renderer to elide replica sets from pod nodes
and directly reference deployment parents instead.
Do the inverse (replace replica sets with pods) during the mapping from pod to deployment.
Note we can no longer use renderParents since we're using a non-standard Selector
The change is necessitated by the removal of procspied/ebpf endpoint
filtering in the renderers, as a result of which the odd
conntracked-only, unconnected pseudo node can sneak through.
This new way of doing things also makes renderers more composable and
robust, and more directly reflects the objective:
- in the process topologies, filter out all unconnected nodes
- in all other topologies, filter out unconnected pseudo nodes
The filtering of endpoints causes some connections to get missed for
non-eBPF-tracked connections. Furthermore, the filtering of endpoints
is entirely pointless when the probes run eBPF since the filters just
pass through eBPF-tracked endpoints (for good reason too; because
otherwise some connections would be missed). So in that case it is
just costing CPU and removing it actually improves performance.
Note that removing the filtering does not result in over-counting
connections since that is done by source ip:port pairs.
Fixes#2551.
Fixes#2558.
* Maps metrics if there is a single pod in the controller, as per all other views.
* Also added heavy commenting on the increasingly-complex render chain
Since there are multiple types in the same topology, displaying the type is important.
We do this in multiple places:
* Add node type to minor label
* Add node type as metadata and include in metadata template.
Even though this will always be the same for every node of that topology, this was
the easiest way to add it so it displays in the table view.
Note we can't control ordering of columns in table view, it's always alphabetical.
The existing technique of "reducing" the two rendered graphs for daemonsets and deployments
had a glaring issue that no connections would ever be made between nodes of different types,
since that information would've been discarded earlier in the process.
It also makes it hard to identify "parentless" pods.
This commit extends the Map2Parent function, teaching it:
* To check multiple topologies for parents
* To pass through nodes with no parents found without modification
Since we already had two 'modes' for what to do with nodes without parents,
and it would've been clunky to try to encode the third option into the existing PseudoNodeID
arg in some way, we instead split it into two args, with the first being an enum specifying
either the old pseudo node behaviour, the old drop behaviour, or the new keep behaviour.
We then use the new Map2Parent to map pods to:
* A replica set, if it has one
* A daemonset, if it has one
* Itself, if neither of the above
and then map again from the results to any deployment, leaving as-is any nodes that
don't map to a deployment. Hence we are left with:
* Deployments
* Daemonsets
* Replica sets, but only if they map to no deployment
* Pods, but only if they map to none of the above
and connections between all these will be calculated correctly.
ProcessRenderer was coloring connected nodes because we need that info
for rendering details panels. However, the main process topology view
renderers depending on ProcessRenderer were also doing coloring
themselves. For the 'processes' topology that was literally
duplicating work. For the 'processes-by-name' topology that was
throwing away the process coloring, and then coloring at the name
level.
Solution: remove the coloring from the ProcessRenderer, thus
eliminating the duplicate/thrown-away work, and introduce a
ColorConnectedProcessRenderer which is only used in places that
populate details panels.
