[
https://issues.apache.org/jira/browse/SOLR-13942?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17051333#comment-17051333
]
Jason Gerlowski commented on SOLR-13942:
----------------------------------------
I'm gonna zoom in to my "Solr vs external tool" objection for now. I've got
other concerns still, but I think focusing in is the best way to get to the
bottom here.
I agree that ZK data is useful for debugging Solr at times. I agree that
making access to this data simple is a Good Thing for Solr admins in the
trenches. I agree that admins need some sort of ops tool to look at this data.
But I think we can also agree, not all ops tools belong in Solr.
e.g. Metrics visualizations are important for admins managing Solr. But it
would be a mistake to start adding Admin UI screens with involved graphs of
Solr's metrics. There's already great tools out there for this job, like
Grafana, with whole teams around them. Those tools are going to see continuous
improvement, attention, etc. that our reinvented-wheel just wouldn't get. Ops
folks have to bite the bullet on an additional container or two, but they get a
much better tool as a result.
I think ZK-proxy APIs fall into a similar category. There are good, solid
ZooKeeper clients out there, with teams whose main job is to support and keep
them up to date. We shouldn't double-down on being a ZK-read-proxy any more
than we should decide to start implementing Grafana-like graphs in our UI.
There's just a better tool for that job, and those tools are going to age much
better than anything we write here, without adding maintenance burden to the
project.
Two arguments against an external client mentioned above were that external
clients required wider ZK-exposure, and a desire to avoid additional
processes/containers/ops-overhead.
In terms of ZK firewall exposure, there are HTTP-based ZK clients that offer
the exact indirection we're getting with these Solr APIs now. Look at
zooNavigator, or zk-web, or browze (written by a Lucene committer btw!). More
recently published and probably the smartest option, Solr admins could look at
putting an nginx proxy in front of ZooKeeper's new AdminServer jetty instance.
In terms of saving a container or two - I mean, I understand that everyone is
fighting cost. But the HTTP-based ZK clients above are (AFAICT) light,
stateless, glorified proxies. Some support ZK's ACL mechanism, so they're
known to work with whatever ZK security clients have setup. Some are
dockerized and ready to deploy. They can be started or stopped at need to save
hardware cost, if that's a concern. Overall it doesn't seem like that
burdensome of an ask for Solr admins who want to do the sort of advanced
monitoring you're describing and can't get what they need from Solr's metrics,
overseerstatus API, etc.
So neither of those "This is why this must be in Solr itself" counterarguments
seem super compelling to me. But I'm open to seeing other sides to this. Can
either of you guys point to something I'm missing here?
> /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
