[jira] [Commented] (SOLR-8207) Modernise cloud tab on Admin UI

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

[jira] [Commented] (SOLR-8207) Modernise cloud tab on Admin UI

JIRA jira@apache.org

    [ https://issues.apache.org/jira/browse/SOLR-8207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16448243#comment-16448243 ]

Jan Høydahl commented on SOLR-8207:
-----------------------------------

Ok, I got a bit further, see [GitHub Pull Request #360|https://github.com/apache/lucene-solr/pull/360] for code. The screenshot below is a *live* view of data captured from 6 nodes running on my Mac:
 * Proxying SystemInofHandler call and MetricsHandler call through localhost to all other Solr nodes
 * Pulling various data and metrics from the APIs and plotting in the table
 ** Under node name is server-level data such as OS, version, JVM, physical RAM, CPUs
 ** Uptime is JVM uptime for this Solr node
 ** Load, CPU & heap as reported by system handler (per-process)
 ** Disk is based on {{CONTAINER.fs.totalSpace}} - not per core. Not sure if we get {{solr.data.dir}} space here as well as {{solr.solr.home}} space??
 ** GC is number of major collections (solr.jvm.{{gc.ConcurrentMarkSweep.countper}}) 5min since JVM start and the same for minor collections ({{solr.jvm.gc.ParNew.count}})
 ** Requests is from {{solr.jetty.org.eclipse.jetty.server.handler.DefaultHandler.get-requests}}, i.e. not per core but for jetty overall, and we show requests per minute 1min rate and 95 percentile latency
 ** Collections and cores simply list what runs on the node. Cores link to the Admin of that node.
 * Some mouse-overs (title attr) for more details on many metrics. Plan to also create a CSS popup with the raw JSON for each node

!nodes-tab-real.png|width=1100!

TODO:
 * Limit number of collections/cores displayed, now all are listed
 * Add a refresh button
 * Add possibility to sort by other columns
 * Add some graphical gauges in place of the percentages??
 * Should the collection names link somewhere?
 * Should we show #docs somewhere? Per core or per node? As well as avg size/doc?

Feel free to take it for a spin by cloning the Github fork or checking out [the patch file|https://patch-diff.githubusercontent.com/raw/apache/lucene-solr/pull/360.patch]

> Modernise cloud tab on Admin UI
> -------------------------------
>
>                 Key: SOLR-8207
>                 URL: https://issues.apache.org/jira/browse/SOLR-8207
>             Project: Solr
>          Issue Type: Improvement
>          Components: Admin UI
>    Affects Versions: 5.3
>            Reporter: Upayavira
>            Assignee: Jan Høydahl
>            Priority: Major
>         Attachments: nodes-tab-real.png, nodes-tab.png
>
>          Time Spent: 10m
>  Remaining Estimate: 0h
>
> The various sub-tabs of the "Cloud tab" were designed before anyone was making real use of SolrCloud, and when we didn't really know the use-cases we would need to support. I would argue that, whilst they are pretty (and clever) they aren't really fit for purpose (with the exception of tree view).
> Issues:
> * Radial view doesn't scale beyond a small number of nodes/collections
> * Paging on the graph view is based on collections - so a collection with many replicas won't be subject to pagination
> * The Dump feature is kinda redundant and should be removed
> * There is now a major overlap in functionality with the new Collections tab
> What I'd propose is that we:
>  * promote the tree tab to top level
>  * remove the graph views and the dump tab
>  * add a new Nodes tab
> This nodes tab would complement the collections tab - showing nodes, and their associated replicas/collections. From this view, it would be possible to add/remove replicas and to see the status of nodes. It would also be possible to filter nodes by status: "show me only up nodes", "show me nodes that are in trouble", "show me nodes that have leaders on them", etc.
> Presumably, if we have APIs to support it, we might have a "decommission node" option, that would ensure that no replicas on this node are leaders, and then remove all replicas from the node, ready for it to be removed from the cluster.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]