[ https://issues.apache.org/jira/browse/SOLR-13942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17051369#comment-17051369 ]
Ishan Chattopadhyaya edited comment on SOLR-13942 at 3/4/20, 4:24 PM: ---------------------------------------------------------------------- Jason, I think you lack some perspective from the point of view of experts who intend to resolve problems and also operations engineers who run & maintain Solr. Here's my perspective. 1. In past 4+ years of consulting, I've encountered several clients who have brought me on to help resolve a production issue. Often, these calls are over conference calls, so I don't have SSH access to their instances (sometimes I did). I am at their mercy to browse or capture screenshots of the Solr admin UI in order to get a fair idea of the ZK data. Here's a recent example, as [~munendrasn] can testify: recently I had to help out with a situation where overseer wasn't getting elected and OVERSEERSTATUS API wasn't working. I needed a way for the client to be able to dump the entire ZK data quickly and pass it to me for further analysis. (In this case, I made a recommendation without having access to the ZK data, and still saved the day.) Asking such clients, in times of such crisis, to install clients or fight with our ZK client etc. is unreasonable because there maybe policy restrictions on their part which will make this process lengthy. 2. Most often, Solr is just part of a very large distributed system comprising of several components and microservices. Expecting dev-ops to install and maintain additional tools for Solr is unreasonable. Also, since we treat ZK as an implementation detail of Solr, it is unreasonable to expect dev-ops to now start setting up proxies etc. for ZK as a way of monitoring Solr. Solr should be able to let expert users peek into the data that Solr puts into ZK. As you've rightly identified, cost of maintaining additional tools is a factor. Another factor is the complexity of monitoring such additional tools. Imagine, the situation when there's a crisis and an outage and the nginx proxy isn't working (and there was no alerting setup to warn that it has gone down). Having Solr let you peek into Solr's own internal state data reduces moving parts needed to debug Solr problems. Hope this helps. p.s.: [~erickerickson], [~dsmiley], [~markrmil...@gmail.com], some perspective from you would help us understand if this issue solves a real problem (which Noble and I seem to think it does). Your war stories will far outweigh whatever I've seen, I'm sure. was (Author: ichattopadhyaya): Jason, I think you lack some perspective from the point of view of experts who intend to resolve problems and also operations engineers who run & maintain Solr. Here's my perspective. 1. In past 4+ years of consulting, I've encountered several clients who have brought me on to help resolve a production issue. Often, these calls are over conference calls, so I don't have SSH access to their instances (sometimes I did). I am at their mercy to browse or capture screenshots of the Solr admin UI in order to get a fair idea of the ZK data. Here's a recent example, as [~munendrasn] can testify: recently I had to help out with a situation where overseer wasn't getting elected and OVERSEERSTATUS API wasn't working. I needed a way for the client to be able to dump the entire ZK data quickly and pass it to me for further analysis. (In this case, I made a recommendation without having access to the ZK data, and still saved the day.) Asking such clients, in times of such crisis, to install clients or fight with our ZK client etc. is unreasonable because there maybe policy restrictions on their part which will make this process lengthy. 2. Most often, Solr is just part of a very large distributed system comprising of several components and microservices. Expecting dev-ops to install and maintain additional tools for Solr is unreasonable. Also, since we treat ZK as an implementation detail of Solr, it is unreasonable to expect dev-ops to now start setting up proxies etc. for ZK as a way of monitoring Solr. Solr should be able to let expert users peek into the data that Solr puts into ZK. As you've rightly identified, cost of maintaining additional tools is a factor. Another factor is the complexity of monitoring such additional tools. Imagine, the situation when there's a crisis and an outage and the nginx proxy isn't working (and there was no alerting setup to warn that it has gone down). Having Solr let you peek into Solr's own internal state data reduces moving parts needed to debug Solr problems. Hope this helps. > /api/cluster/zk/* to fetch raw ZK data > -------------------------------------- > > Key: SOLR-13942 > URL: https://issues.apache.org/jira/browse/SOLR-13942 > Project: Solr > Issue Type: New Feature > Components: v2 API > Reporter: Noble Paul > Assignee: Noble Paul > Priority: Blocker > Fix For: 8.5 > > Time Spent: 20m > Remaining Estimate: 0h > > example > download the {{state.json}} of > {code} > GET http://localhost:8983/api/cluster/zk/collections/gettingstarted/state.json > {code} > get a list of all children under {{/live_nodes}} > {code} > GET http://localhost:8983/api/cluster/zk/live_nodes > {code} > If the requested path is a node with children show the list of child nodes > and their meta data -- This message was sent by Atlassian Jira (v8.3.4#803005) --------------------------------------------------------------------- To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org For additional commands, e-mail: issues-h...@lucene.apache.org