Improve the Usability and Performance of the Kiali tool in Large Environments #8230
Comments
|
Hi, @Shiva2199, thanks for your suggestions. We continue to try and provide more scalable ways to visualize large traffic topologies. We'll consider these suggestions and see if we can agree on some concrete steps forward. In particular, I think the general idea of being able to prevent premature graph requests makes sense. Unless I misunderstand the suggestion, it's not really possible to filter Prometheus queries via k8s labels, like a k8s label selector. Note that the graph "Hide" feature does support hiding by k8s label. Currently, the best ways to initially limit your graph generation time are to:
Although it doesn't reduce graph generation time, you can significantly clean up your graph client-side using Graph Hide expressions. This does offer a k8s-label-based hide (although I believe there is a bug at the moment). Also, it is possible to predefine graph hide expressions, in the Kiali CR, that are applied automatically to your graph. |
|
Hi @Shiva2199 , I had a couple of more follow up questions. Do you make much use of the "mini-graphs" on the detail pages? One way to have a more focused look is to navigate to a workload/app/service via the lists, and then inspect the graph centered on just that object. Similarly, you can drill down into a node-specific graph from the main graph, via the context menu. Do you have a lot of namespaces that you want to see together, or typically you only need to graph 1 namespace at a time? When you talk about "operation nodes" above, are you talking explicitly about the Operation Node support in Kiali, related to Istio Request Classification? Or are you using that term more generically, to describe a set of nodes that are associated by a label selector, or something like that? When you talk about label filtering, are you actually talking about filtering by k8s labels or the actual metric labels in prom? I was first thinking you were talking about k8s labels, but re-reading, I'm wondering if you are thinking of something pretty advanced, being exposed to, and able to filter on a prom metric label itself. |
What do you want to improve?
Improve the usability and performance of the Kiali Traffic Graph, especially in environments with a large number of pods and complex topologies
What is the current behavior?
Overwhelming number of nodes and edges: The Traffic Graph cannot start due to the large number of nodes and edges, causing the UI to become unresponsive.
Memory limitations: Increasing memory does not significantly improve performance.
Graph rendering issues: The graph is too large to fit within the canvas, making it difficult to visualize.
What is the new behavior?
Proposed Solution: Implement a lazy loading approach where the Traffic Graph only starts rendering after the user selects specific filters. These filters will be used to query Prometheus for relevant metrics, ensuring that only the filtered results are rendered. Additionally, incorporate the ability to filter based on “operation nodes” using metric labels propagated through the flow.
Detailed Enhancement Proposal
Lazy Loading with Filters:
Initial Filter Selection: Before rendering the Traffic Graph, prompt the user to select filters such as namespace, service, or specific labels.
Prometheus Query: Use the selected filters to query Prometheus for relevant metrics.
Conditional Rendering: Render the Traffic Graph based on the filtered results from Prometheus, rather than attempting to render the entire topology initially.
Operation Node Filtering:
Metric Label Filtering: Allow users to filter the Traffic Graph based on specific metric labels (e.g., operation nodes).
Selective Rendering: Only render nodes, edges, and operation nodes that match the selected label value.
Improved Visualization: This will help the operation team focus on specific operation nodes without being overwhelmed by the entire topology.
Benefits:
Improved Performance: Reduces the load on the UI by only rendering filtered results.
Enhanced Usability: Users can interact with the Traffic Graph without experiencing UI freezes.
Focused Visualization: Helps the operation team to filter and visualize traffic per operation node, improving troubleshooting and monitoring efficiency.
Example Workflow:
User selects filters: Namespace, service, or specific labels.
Query Prometheus: Fetch metrics based on selected filters.
Render Traffic Graph: Display only the filtered nodes, edges, and operation nodes.
Interactive Options: Users can further refine the view using Hide/Find options without UI performance issues.
This enhancement should significantly improve the usability and performance of the Kiali Traffic Graph, especially in environments with a large number of pods and complex topologies.
The text was updated successfully, but these errors were encountered: