[
https://issues.apache.org/jira/browse/SOLR-9735?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15644546#comment-15644546
]
Erick Erickson commented on SOLR-9735:
--------------------------------------
I think this is somewhat related to SOLR-9731. If we're going to be doing
cluster management, we'll also need to be gathering some metrics about how each
node is doing.
9173 is about exposing metrics on a single Solr instance. The logical next step
is to collect them system-wide and expose the system-wide metrics. Whether
that'd be JMX or not is an open question, but it'd sure make operations people
happy.
So while we're working on this particular issue (which I think is a great idea)
perhaps we can do so with an eye towards exposing both the overall single-solr
instance information and the aggregate information to external consumers.
> Umbrella JIRA for Cluster Management framework in SolrCloud
> -----------------------------------------------------------
>
> Key: SOLR-9735
> URL: https://issues.apache.org/jira/browse/SOLR-9735
> Project: Solr
> Issue Type: New Feature
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Anshum Gupta
> Original Estimate: 1,344h
> Remaining Estimate: 1,344h
>
> As SolrCloud is now used at fairly large scale, most users end up writing
> their own cluster management tools. We should have a framework for cluster
> management in Solr.
> In a discussion with [~noble.paul], we outlined the following steps w.r.t.
> the approach to having this implemented:
> * *Basic API* calls for cluster management e.g. utilize added nodes, remove a
> node etc. These calls would need explicit invocation by the users to begin
> with. It would also specify the {{strategy}} to use. For instance I can have
> a strategy called {{optimizeCoreCount}} which would target to have an even
> no:of cores in each node . The strategy could optionally take parameters as
> well
> * *Metrics* and stats tracking e.g. qps, etc. These would be required for any
> advanced cluster management tasks e.g. *maintain a qps of 'x'* by
> *auto-adding a replica* (using a recipe) etc. We would need
> collection/shard/node level views of metrics for this.
> * *Recipes*: combination of multiple sequential/parallel API calls based on
> rules. This would be complicated specially as most of these would be long
> running series of tasks which would either have to be rolled back or resumed
> in case of a failure.
> * *Event based triggers* that would not require explicit cluster management
> calls for end users.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
